🥇A Linux kernel konfigurálása GlusterFS-hez

A cikk fordítása a kurzus megkezdése előtt készült «Linux Rendszeradminisztrátor. Professzionális».

Időnként felmerülnek kérdések a Gluster kernelbeállításaival kapcsolatban, és hogy szükség van-e erre.

Ilyen szükséglet ritkán fordul elő. A legtöbb terhelés mellett a kernel nagyon jól működik. Azonban van ennek egy másik oldala is. A Linux kernel történelmileg hajlamos sok memóriát felhasználni, ha lehetőséget adunk neki, beleértve a gyorsítótárazást is mint a teljesítmény növelésének fő módszerét.

A legtöbb esetben ez nagyszerűen működik, de nagy terhelés esetén problémákhoz vezethet.

Széleskörű tapasztalatunk van a memóriát nagymértékben használó rendszerekkel, mint például CAD, EDA és hasonlók, amelyek lelassultak nagy terhelés alatt. Néha problémákkal találkoztunk a Glusterrel is. Több napon át figyelve a használt memória és a disk wait időt, túlterhelést, hatalmas iowait-et, kernel hibákat (kernel oops), fagyásokat stb. tapasztaltunk.

Ez a cikk sok kísérlet eredménye a paraméterek beállítására, amelyeket különböző helyzetekben végeztek. Ezek a paraméterek nemcsak az általános reakcióidőt javították, hanem jelentősen stabilizálták a klaszter működését is.

Amikor a memória beállításáról van szó, először a virtuális memória (VM, virtual memory) alrendszerére kell figyelni, amelynek rengeteg lehetősége van, ami zűrzavart okozhat.

vm.swappiness

A parameter vm.swappiness meghatározza, hogy a kernel mennyire használja a swapot a RAM-hoz képest. Az alapértelmezett kódban ezt úgy definiálják, mint a «tendency to steal mapped memory» (a leképzett memória ellopásának hajlama). A magas swappiness érték azt jelenti, hogy a kernel hajlamosabb a leképzett oldalak kiürítésére. Az alacsony swappiness érték ezzel ellentétes: a kernel kevesebb oldalt fog kiüríteni a memóriából. Más szavakkal, minél magasabb az érték, vm.swappiness, annál inkább fogja a rendszer használni a swap-ot.

A nagy mértékű swap használata nem kívánatos, mivel hatalmas adatblokkok kerülnek betöltésre és kiürítésre a RAM-ban. Sokan azt állítják, hogy a swapiness értékének magasnak kell lennie, de tapasztalataim szerint a teljesítmény növeléséhez a «0» beállítás vezet.

Bővebben itt olvashat — lwn.net/Articles/100978

Azonban ezeket a beállításokat óvatosan kell alkalmazni, és csak a konkrét alkalmazás tesztelése után. Nagy terhelésű streamelő alkalmazásoknál ezt a paramétert '0'-ra kell állítani. A '0'-ra állítással javul a rendszer válaszkészsége.

vm.vfs_cache_pressure

Ez a paraméter szabályozza azt a memóriát, amelyet a kernel használ a könyvtár- és indexelő objektumok (dentry és inode) gyorsítótárazására.

Alapértelmezett értékkel, amely 100, a kernel próbálja a dentry és inode gyorsítótárat az 'igazságosság' szempontjából felszabadítani a pagecache és swapcache-hez képest. A vfs_cache_pressure csökkentése azt eredményezi, hogy a kernel megőrzi a dentry és inode gyorsítótárakat. Ha az érték '0', a kernel soha nem fogja tisztítani a dentry és inode gyorsítótárat memória hiánya miatt, és ez könnyen memóriagyarapodás-hibához vezethet. A vfs_cache_pressure 100-nál nagyobb mértékű növelése azt eredményezi, hogy a kernel előnyben részesíti a dentry és inode kiürítését.

GlusterFS használatakor sok felhasználó, akik nagy adatmennyiséggel és sok kis fájllal dolgoznak, könnyen jelentős mennyiségű RAM-ot használhatnak a szerveren az inode/dentry gyorsítótárazás miatt, ami teljesítménycsökkenéshez vezethet, mivel a kernelnek adatstruktúrákat kell kezelnie egy 40 GB-os memóriával rendelkező rendszerben. E paraméter 100-on túli beállítása sok felhasználónak segített igazságosabb gyorsítótározást elérni és javítani a kernel válaszkészségét.

vm.dirty_background_ratio és vm.dirty_ratio

Az első paraméter (vm.dirty_background_ratio) meghatározza a memóriának azt a százalékát, amely szennyezett oldalakkal rendelkezik, amely elérve meg kell kezdeni a szennyezett oldalak háttérben történő leírását a lemezre. Amíg ez a százalék nem érhető el, az oldalak nem kerülnek leírásra a lemezre. Amikor a leírás elkezdődik, az háttérben történik, anélkül, hogy megszakítaná a futó folyamatokat.

A második paraméter (vm.dirty_ratio) meghatározza azt a memória százalékot, amelyet a piszkos oldalak foglalhatnak el a kényszerített törlés (forced flash) megkezdése előtt. Amint ezt a küszöböt elérik, az összes folyamat szinkronizálttá válik (blokkolódik), és nem folytathatják a munkát addig, amíg a kérdéses bemeneti-kimeneti (I/O) művelet ténylegesen be nem fejeződik, és az adatok el nem kerülnek a lemezre. Nagy terhelésű I/O esetén ez problémát okozhat, mivel az adatok gyorsítótárazása hiányzik, és az összes I/O műveletet végző folyamat blokkolódik, várva a bemeneti-kimeneti műveletet. Ez sok felfüggesztett folyamatot, magas terhelést, instabil rendszer működést és gyenge teljesítményt eredményez.

E paraméterek értékeinek csökkentése azt eredményezi, hogy az adatok gyakrabban kerülnek lemezre, és nem tárolódnak a RAM-ban. Ez hasznos lehet olyan rendszerek számára, amelyek nagy mennyiségű memóriával rendelkeznek, ahol normális a 45–90 GB-os oldal gyorsítótárazása a lemezre, ami óriási várakozási időt eredményez a frontend alkalmazások számára, csökkentve ezzel az általános reakcióidőt és interaktivitást.

«1» > /proc/sys/vm/pagecache

Az oldal gyorsítótár (page cache) az a gyorsítótár, ahol a fájlok és programok tényleges tartalma található, vagyis ezek a fájlok vagy blokkeszközök tényleges tartalmú oldala. Ez a gyorsítótár a lemezről történt olvasások számának csökkentésére szolgál. Az «1» érték azt jelenti, hogy a gyorsítótár 1% RAM-ot használ, és a diszk olvasásokból több fog történni, mint a RAM-ba. Ezt a paramétert nem szükséges módosítani, de ha paranoid módon szeretnéd ellenőrizni az oldal gyorsítótárat, akkor ezt használhatod.

«deadline» > /sys/block/sdc/queue/scheduler

A bemeneti-kimeneti ütemező (I/O scheduler) a Linux kernel egy összetevője, amely kezeli az írási és olvasási sorokat. Elméletileg okos RAID-vezérlő esetén a «noop» használata a legjobb, mivel a Linux nem ismeri a lemez fizikai geometriáját, ezért hatékonyabb, ha a vezérlő, amely jól ismeri a lemez geometriáját, a lehető leggyorsabban feldolgozza a kéréseket. De úgy tűnik, hogy a «deadline» javítja a teljesítményt. A tervezőkről többet olvashatsz a Linux kernel forráskódjának dokumentációjában: linux/Documentation/block/*osched.txt. És azt is észleltem, hogy a vegyes műveletek (sok írási művelet) során nőtt az olvasási sebesség.

«256» > /sys/block/sdc/queue/nr_requests

A bemeneti- és kimeneti lekérdezések száma a pufferen, mielőtt a tervezőhöz kerülnének. Néhány vezérlő belső sorának (queue_depth) mérete nagyobb, mint az I/O tervező nr_requests-e, ezért az I/O tervezőnek kevés lehetősége van arra, hogy helyesen priorizálja és végrehajtsa a lekérdezések egyesítését. Deadline és CFQ tervezők esetén előnyösebb, ha a nr_requests kétszer akkora, mint a vezérlő belső sora. A lekérdezések egyesítése és átrendezése segít a tervezőnek, hogy nagy terhelés mellett is reagálóképesebb legyen.

echo «16» > /proc/sys/vm/page-cluster

A page-cluster paraméter határozza meg a lapok számát, amelyeket egyszerre írunk ki a cserehelyre. A fenti példa szerint az érték «16»-ra van állítva, amely a RAID 64 KB-os csík méretének megfelelően van beállítva. Ez nem logikus, ha a swappiness = 0, de ha a swappiness értékét 10-re vagy 20-ra állította be, akkor ez a beállítás segíthet, amikor a RAID csík mérete 64 KB.

blockdev --setra 4096 /dev/`<`devname`>` (-sdb, hdc vagy dev_mapper)

A legtöbb RAID-vezérlő alapértelmezett blokk eszközbeállítása gyakran borzalmas teljesítményt eredményez. A fent említett opció hozzáadása 4096 * 512 bájt szektorok előzetes olvasási beállításait alakítja. Legalábbis a folyamatos műveletek során növeli a sebességet, feltöltve a lemez beépített gyorsítótárát az előzetes olvasás során, ameddig a kernel az I/O előkészítésével foglalkozik. Olyan adatok kerülhetnek a gyorsítótárba, amelyeket a következő olvasás során kérnek le. Túl sok előzetes olvasás megölheti a véletlenszerű I/O-t nagy fájlok esetében, ha potenciálisan hasznos lemezidőt használ, vagy az adatokat a gyorsítótáron kívül betölti.

Az alábbiakban néhány további javaslatot talál, amelyeket a fájlrendszer szintjén érdemes figyelembe venni. Ezeket azonban még nem tesztelték. Győződjön meg róla, hogy a fájlrendszere ismeri a csík méretét és a tömbben található lemezek számát. Például, hogy ez egy raid5 tömb 64K csíkmérettel, hat lemezből (valójában öt, mivel egy lemez a paritásra van fenntartva). Ezek a javaslatok elméleti feltételezéseken alapulnak, és különböző RAID szakértők blogjaiból és cikkeiből gyűjtötték őket.

-> ext4 fs, 5 lemez, 64K csík, egységek 4K blokkokban
mkfs -t ext4 -E stride=$((64/4))
-> xfs, 5 lemez, 64K csík, egységek 512 bájtos szektorokban
mkfs -t xfs -d sunit=$((64*2)) -d swidth=$((5*64*2))

Nagy fájlok esetén érdemes megfontolni a fent megadott csíkok méretének növelését.

FIGYELEM! A fent leírtak rendkívül szubjektívek egyes alkalmazástípusok esetében. Ez a cikk nem garantál javulásokat anélkül, hogy a felhasználó előzetesen tesztelné a megfelelő alkalmazásokat. Csak akkor ajánlott alkalmazni, ha szükséges a rendszer általános válaszkészségének javítása vagy ha a meglévő problémákat megoldja.