A cikk fordítása a tanfolyam kezdetének előestéjén készült .
Időnként itt-ott felmerülnek kérdések a Gluster kernelhangolással kapcsolatos ajánlásaival kapcsolatban, és hogy szükség van-e erre.
Ilyen igény ritkán adódik. A legtöbb munkaterhelésnél a kernel nagyon jól teljesít. Bár van egy árnyoldala is. Korábban a Linux kernel hajlandó volt sok memóriát fogyasztani, ha lehetőséget kapott, beleértve a gyorsítótárazást, mint a teljesítmény javításának fő módját.
A legtöbb esetben ez jól működik, de nagy terhelés esetén problémákhoz vezethet.
Sok tapasztalatunk van az olyan memóriaigényes rendszerekkel kapcsolatban, mint a CAD, EDA és hasonlók, amelyek nagy terhelés hatására lassulni kezdtek. És néha problémákba ütköztünk Glusterben. A memóriahasználatot és a lemez késleltetését hosszú napokig tartó gondos megfigyelés után megkaptuk a túlterhelésüket, hatalmas iowait-jukat, kernelhibákat (kernel hoppá), lefagyásokat stb.
Ez a cikk számos különböző helyzetekben végzett hangolási kísérlet eredménye. Ezeknek a paramétereknek köszönhetően nemcsak az általános válaszkészség javult, hanem a klaszter is jelentősen stabilizálódott.
Ha a memória hangolásáról van szó, először a virtuális memória alrendszerre (VM, virtuális memória) kell figyelni, amely számos olyan opcióval rendelkezik, amelyek megzavarhatják.
vm.cserelehetőség
Paraméter vm.swappiness meghatározza, hogy a kernel mennyi cserét (swap, lapozás) használ a RAM-hoz képest. A forráskódban úgy is definiálják, mint "hajlam a leképezett memória ellopására". A magas swappiness azt jelenti, hogy a kernel hajlamosabb lesz a leképezett oldalak cseréjére. Az alacsony csereérték az ellenkezőjét jelenti: a kernel kevesebbet lapoz a memóriából. Más szóval, minél magasabb az érték vm.swappiness, annál többet fog használni a rendszer a swap-ot.
Nem kívánatos a nagymértékű cserehasználat, mivel hatalmas adattömböket töltenek be és töltenek ki a RAM-ba. Sokan azzal érvelnek, hogy a swapness értéknek nagynak kell lennie, de tapasztalataim szerint, ha "0"-ra állítja, jobb teljesítményt eredményez.
Bővebben itt olvashatsz -
De ismételten, ezeket a beállításokat óvatosan és csak egy adott alkalmazás tesztelése után kell alkalmazni. Erősen terhelt streaming alkalmazások esetén ezt a paramétert "0"-ra kell állítani. Ha „0”-ra változtatja, a rendszer válaszkészsége javul.
vm.vfs_cache_pressure
Ez a beállítás szabályozza a kernel által a könyvtár- és inode-objektumok (dentry és inode) gyorsítótárazásához felhasznált memóriát.
Az alapértelmezett 100-as érték mellett a kernel megpróbálja "tisztességes" alapon felszabadítani a dentry és inode gyorsítótárakat a pagecache és a swapcache számára. A vfs_cache_pressure csökkentése miatt a kernel megtartja a dentry és inode gyorsítótárakat. Ha az érték "0", a kernel soha nem fogja kiüríteni a dentry és az inode gyorsítótárat a memória nyomása miatt, és ez könnyen memóriahiba-hibához vezethet. A vfs_cache_pressure 100 fölé növelése azt eredményezi, hogy a kernel prioritást ad a dentry és az inode flushing számára.
A GlusterFS használatakor sok nagy adatmennyiséggel és sok kis fájllal rendelkező felhasználó könnyen jelentős mennyiségű RAM-ot használhat fel a szerveren az inode/dentry gyorsítótárazás miatt, ami teljesítményromláshoz vezethet, mivel a kernelnek fel kell dolgoznia a rendszer adatstruktúráit. 40 GB memóriával. Ennek az értéknek a 100 fölé állítása sok felhasználó számára segített igazságosabb gyorsítótárazásban és jobb kernel válaszkészségben.
vm.dirty_background_ratio és vm.dirty_ratio
Az első paraméter (vm.dirty_background_ratio) meghatározza a piszkos oldalakkal rendelkező memória százalékos arányát, amelynek elérése után el kell kezdeni a háttérben lévő piszkos oldalak lemezre öblítését. Amíg ezt a százalékot el nem éri, egyetlen oldal sem kerül a lemezre. És amikor az alaphelyzetbe állítás elindul, a háttérben fut a futó folyamatok megszakítása nélkül.
A második paraméter (vm.dirty_ratio) határozza meg, hogy a memória hány százalékát foglalhatják el a piszkos oldalak a kényszerített villanás megkezdése előtt. Amint elérte ezt a küszöböt, minden folyamat szinkronizálódik (blokkol), és nem folytatható, amíg a kért I/O ténylegesen be nem fejeződik és az adatok a lemezen vannak. Erős I/O esetén ez problémát okoz, mert nincs adatgyorsítótár, és az I/O-t végző összes folyamat blokkolva van, és az I/O-ra vár. Ez nagyszámú leakasztott folyamathoz, nagy terheléshez, rendszerinstabilitáshoz és gyenge teljesítményhez vezet.
Ha csökkenti ezeket a beállításokat, az adatok gyakrabban kerülnek a lemezre, és nem kerülnek tárolásra a RAM-ban. Ez segíthet a nagy memóriaigényű rendszerekben, ahol normális, hogy a 45-90 GB-os oldalgyorsítótárat lemezre ürítik, ami hatalmas késést eredményez a front-end alkalmazások számára, csökkentve az általános válaszkészséget és az interaktivitást.
"1" > /proc/sys/vm/pagecache
Az oldalgyorsítótár egy olyan gyorsítótár, amely fájlok és végrehajtható programok adatait tárolja, vagyis ezek olyan oldalak, amelyek a fájlok vagy blokkeszközök tényleges tartalmát tartalmazzák. Ez a gyorsítótár a lemezolvasások számának csökkentésére szolgál. Az "1" érték azt jelenti, hogy a RAM 1%-át használják a gyorsítótárhoz, és több lesz az olvasás a lemezről, mint a RAM-ból. Ezt a beállítást nem szükséges módosítani, de ha paranoiás az oldal gyorsítótárának szabályozása, használhatja.
"határidő" > /sys/block/sdc/queue/scheduler
Az I/O ütemező egy Linux kernel összetevő, amely olvasási és írási sorokat kezel. Elméletileg érdemesebb a "noop"-ot használni egy intelligens RAID-vezérlőhöz, mert a Linux semmit sem tud a lemez fizikai geometriájáról, így hatékonyabb, ha hagyjuk, hogy a lemezgeometriát jól ismerő vezérlő olyan gyorsan feldolgozza a kérést, mint lehetséges. De úgy tűnik, hogy a "határidő" javítja a teljesítményt. Az ütemezőkről bővebben a Linux kernel forráskód dokumentációjában olvashat: linux/Documentation/block/*osched.txt. És azt is tapasztaltam, hogy a vegyes műveletek során (sok írás) megnőtt az olvasási sebesség.
"256" > /sys/block/sdc/queue/nr_requests
A pufferben lévő I/O kérések száma az ütemezőnek való átadásuk előtt. Egyes vezérlők belső sormérete (queue_depth) nagyobb, mint az I/O ütemező nr_request mérete, így az I/O ütemezőnek kevés esélye van a kérések megfelelő priorizálására és egyesítésére. A határidő és a CFQ ütemezők számára jobb, ha az nr_requests kétszerese a vezérlő belső sorának. A kérelmek egyesítése és átrendezése segít az ütemezőnek, hogy nagyobb terhelés esetén is reagáljon.
echo "16" > /proc/sys/vm/page-cluster
Az oldalfürt paraméter szabályozza, hogy hány oldal kerül egyszerre a swapba. A fenti példában az érték „16”-ra van állítva a 64 KB-os RAID-csík méretének megfelelően. Ennek nincs értelme, ha a swappiness = 0, de ha a felcserélést 10-re vagy 20-ra állítja, akkor ennek az értéknek a használata akkor segít, ha a RAID csík mérete 64K.
blockdev --setra 4096 /dev/<devname> (-sdb, hdc vagy dev_mapper)
Számos RAID-vezérlő alapértelmezett blokkolóeszköz-beállításai gyakran szörnyű teljesítményt eredményeznek. A fenti opció hozzáadásával beállítja az előreolvasást a 4096 * 512 bájtos szektorokhoz. A streamelési műveletek sebességét legalábbis növeli, ha a chipen lévő lemez gyorsítótárát előreolvasással töltik fel a kernel által az I/O előkészítésére használt időtartam alatt. A gyorsítótár olyan adatokat tartalmazhat, amelyeket a következő olvasáskor kérünk. A túl sok előzetes letöltés megölheti a véletlenszerű I/O-t nagy fájlok esetén, ha potenciálisan hasznos lemezidőt használ fel, vagy a gyorsítótáron kívül tölt be adatokat.
Az alábbiakban néhány további javaslat található a fájlrendszer szintjén. De még nem tesztelték őket. Győződjön meg arról, hogy a fájlrendszer ismeri a csík méretét és a tömbben lévő lemezek számát. Például, hogy ez egy 5K stripe raid64 tömb hat lemezből (valójában ötből, mert egy lemezt használnak paritásra). Ezek az ajánlások elméleti feltételezéseken alapulnak, és RAID-szakértők különféle blogokból/cikkekből állították össze.
-> ext4 fs, 5 disks, 64K stripe, units in 4K blocks
mkfs -text4 -E stride=$((64/4))
-> xfs, 5 disks, 64K stripe, units in 512-byte sectors
mkfs -txfs -d sunit=$((64*2)) -d swidth=$((5*64*2))Nagy fájlok esetén fontolja meg a fent felsorolt csíkméretek növelését.
FIGYELEM A fent leírtak mindegyike erősen szubjektív bizonyos típusú alkalmazások esetében. Ez a cikk nem garantálja a fejlesztéseket a kapcsolódó alkalmazások előzetes felhasználói tesztelése nélkül. Csak akkor használható, ha a rendszer általános válaszkészségének javítására van szükség, vagy ha az aktuális problémákat megoldja.
További anyagok:
Olvass tovább
Forrás: will.com