ZFS ARC-beállítás: felső határok, korlátok és mérendő értékek

Az ZFS alapértelmezés szerint csendben lefoglalja a rendszer RAM-jának körülbelül felét olvasási gyorsítótárának, és nem megfelelő típusú szerveren ez swap-tevékenységet, OOM-leállásokat vagy azt jelenti, hogy az adatbázis a fájlrendszerrel verseng a memóriáért. Az ZFS ARC-beállítás lényege annak eldöntése, hogy az ARC valójában mennyi RAM-ot tarthat meg, és mit kell feladni a korlát beállításához. Ez a bejegyzés bemutatja, hogyan használja az ARC a memóriát, mit kell mérni, mielőtt bármit is módosítanál, azokat a néhány beállítást, amelyeket érdemes megváltoztatni, valamint ésszerű kiindulási pontokat fájlszerverek, hipervizorok, adatbázisok és biztonsági mentési célok esetében. A ZFS pillanatképekkel kapcsolatos részleteiről olvass el a ZFS pillanatképekről szóló útmutatónkat.

Mérje meg az ARC-értéket, mielőtt bármit is beállítana

Ne változtasson meg egyetlen beállítást sem, amíg nincs rendelkezésre álló alapérték a normál forgalmas időszakból. A csendes időszakban készített pillanatfelvételek rossz irányba terelhetik. Az éjszakai biztonsági mentések, a heti jelentések és a kötegelt feladatok során általában érdekesebbé válik az ARC viselkedése, ezért több napon keresztül rögzítsen adatokat.

Három eszköz fedezi a szükséges funkciók nagy részét:

• arcstat 1 Élő, görgethető nézetet nyújt a találati és elhibázott számlálókról, a kereslet és az előzetes letöltés aktivitásáról, valamint az aktuális ARC-méretről. Használja terheléses tesztek és biztonsági mentési ablakok során.
• arc_summary Egyetlen pillanatfelvételt nyomtat ki: az ARC méretét és célértékét, az MFU/MRU megoszlást, a metaadatok arányait és az aktív beállítható paramétereket. Futtassa a arc_summary -s arc parancsot kizárólag az ARC szakaszra.
• A nyers számlálók a /proc/spl/kstat/zfs/arcstats Linuxon, valamint a kstat.zfs.misc és vfs.zfs sysctl fákban. Ezeket inkább a felügyeleti rendszerből gyűjtsük össze, a formázott kimenet elemzése helyett.

A változtatások előtt érdemes rögzíteni a következő számlálókat:

Két dologban gyakran tévednek az emberek. A rendelkezésre álló memóriát kell figyelni, nem a szabad memóriát; a Linux gond nélkül jelenti az alacsony szabad RAM-ot stabil állapotként, és ez önmagában nem jelent problémát. Az a jel, amire figyelni kell, az a nullához közeli rendelkezésre álló memória, tartós swap-tevékenységgel párosulva (a Linux memóriakezelési bevezetője elmagyarázza, miért). A találati arányt pedig trendként kezelje, ne célként. Egy swap-oló gépen elért 99%-os találati arány a hangolás kudarca, nem pedig sikere.

A négy fontos ARC-beállítás

A termelési hangolás nagy része négy beállításra vezethető vissza. A beállítást igazítsa az alapvonalban ténylegesen mért nyomáshoz. A csereaktivitás a következőre utal zfs_arc_max. A forró gyorsítótárat folyamatosan törlő churn visszanyerése a zfs_arc_min. A lassú könyvtárbejárások a metaadat-korlátra utalnak.

Kezdje a legkisebb változtatással, amely megoldja a látható terhelést. zfs_arc_maxA megfelelő felső határ a terheléstől függ (ezt a következő szakasz tárgyalja). zfs_arc_minesetben a zfs_arc_max és az ésszerű kiindulási pont, ha egyáltalán szükség van ilyenre. A metaadatok esetében a legújabb OpenZFS alapértelmezések máris a metaadatoknak az ARC 75%-át biztosítják a zfs_arc_meta_limit_percent, ami a legtöbb terhelés esetén bőséges; ezt csak akkor módosítsd, ha a metaadatok hiányai egyértelműen láthatók a arcstat.

Változások alkalmazása Linuxon és FreeBSD-n

Linuxon a sysfs paraméterfájlba való írással tesztelhetjük a módosítást futásidőben. Újraindításra nincs szükség:

echo 17179869184 > /sys/module/zfs/parameters/zfs_arc_max

Ezzel zfs_arc_max azonnal 16 GiB-ra állítja. Ahhoz, hogy a módosítás újraindítás után is megmaradjon, vegye fel a /etc/modprobe.d/zfs.conf:

options zfs zfs_arc_max=17179869184

FreeBSD-n a futásidejű módosításokhoz a sysctl:

sysctl vfs.zfs.arc_max=17179869184

Az érték megőrzéséhez a /boot/loader.conf:

vfs.zfs.arc_max="17179869184"

Egyszerre csak egy beállítást módosítson, a teljes RAM-méret körülbelül 10%-át kitevő kis lépésekben. Figyelje a problémamegjelenítő ablakot. Csak akkor tartsa meg a módosítást, ha a swap értéke nulla marad, és a késleltetés stabil. Csak a futásidejű teszt sikeres teljesítése után állítsa be véglegesen.

Az ARC munkaterhelés szerinti beállítása

A teljes RAM-kapacitás nem megfelelő kiindulási pont. Az ARC méretezését a rendszer terhelési összetételének kell követnie.

A virtuális gép-gazdagépnek meg kell osztania a memóriát a vendégekkel, ezért a 30–40%-os korlát biztonságos alapértelmezés, a 50% pedig a legtöbb konfigurációban már túl magas. Az olyan adatbázisok, mint a PostgreSQL és a MySQL, saját puffer-gyorsítótáraikat kezelik, ezért először a motor számára kell memóriát lefoglalni, majd a maradékot az ARC rendelkezésére kell bocsátani. A biztonsági mentési célok előnyös helyzetben vannak primarycache=metadata , mivel az olvasott adatokra ritkán van szükség újra, és nem szeretnénk, ha az éjszakai biztonsági mentés végigfutna az egész poolon, és közben kiürítené a cache többi részét. Minden terhelés esetében, ha az ARC-t zfs_arc_max , a felső határ túl magas; ez a szabály nem változik.

A problémák diagnosztizálása és annak felismerése, mikor kell leállni

A túl kicsi ARC magas olvasási IOPS-értékekkel, alacsony keresési találati arányokkal és lassú könyvtárböngészéssel jár, miközben a rendszernek még van szabad RAM-ja. A túl nagy ARC kevésbé nyilvánvaló. A találati arány rendben tűnik, de a rendszer elkezdi a swapolást, a terhelési átlagok emelkednek, a folyamatok D állapotba kerülnek, miközben a kernel igény szerint visszanyeri az ARC-oldalakat, és a legrosszabb esetben az OOM-killer elkezd áldozatokat kiválasztani. A gyorsítótár látszólag rendben van, de a szerver szörnyen működik.

A metaadat-terhelés akkor jelentkezik, amikor demand_metadata_bytes sokkal magasabb, mint demand_data_bytes -nál arc_summary. Ekkor a metaadatok versengenek a helyért az adatokkal, és érdemes megemelni a metaadatok százalékos korlátját.

Hasonlítsa össze a látottakat az első beállítással, amelyet ellenőriznie kell:

Az L2ARC nem ingyenes. Az L2ARC-bejegyzések indexe az elsődleges ARC-ben található, és ha ez a terhelés meghaladja az ARC teljes kapacitásának körülbelül egyharmadát, a másodlagos gyorsítótár több kárt okoz, mint hasznot. Csak akkor érje el az L2ARC-ot, ha a munkakészlet nagyobb, mint a RAM, de még mindig elfér egy gyors NVMe-eszközön, és csak akkor, ha az elsődleges ARC találati aránya már megfelelő.

A hangolás befejezésének megfelelő időpontja az, amikor a késleltetés stabil marad, a swap nulla szinten marad ugyanazon a forgalmas időszakban, amely az eredeti problémát okozta, és a további változtatások már nem javítanak semmin. A magas találati arány semmit sem jelent, ha a szerver swapol. Ezen a ponton túl ne módosítsa tovább a beállításokat, és csak akkor vizsgálja felül őket, ha ugyanaz a probléma ugyanazon a terhelés mellett újra felmerül.

Ha olyan szerverre van szüksége, amelynek elegendő RAM-tartaléka van a ZFS megfelelő futtatásához anélkül, hogy a virtuális gépekkel vagy adatbázisokkal kellene versengenie a memóriáért (érdemes először elolvasni, hogy valójában mennyi RAM-ra van szüksége), akkor nézze meg az FDC dedikált szervereit.