Překlad článku byl připraven v předvečer zahájení kurzu .
Občas se tu a tam objevují otázky ohledně doporučení Glusteru ohledně ladění jádra a zda je to potřeba.
Taková potřeba se vyskytuje jen zřídka. Ve většině úloh si jádro vede velmi dobře. I když je tu nevýhoda. Historicky bylo linuxové jádro ochotno spotřebovat hodně paměti, pokud dostalo příležitost, včetně ukládání do mezipaměti jako hlavního způsobu zlepšení výkonu.
Ve většině případů to funguje dobře, ale při velkém zatížení to může vést k problémům.
Máme bohaté zkušenosti s paměťově náročnými systémy jako CAD, EDA a podobně, které se při velkém zatížení začaly zpomalovat. A někdy jsme narazili na problémy v Glusteru. Po pečlivém sledování využití paměti a latence disku po mnoho dní jsme dostali jejich přetížení, obrovské iowait, chyby jádra (jejda jádra), zamrznutí atd.
Tento článek je výsledkem mnoha experimentů s laděním prováděných v různých situacích. Díky těmto parametrům se zlepšila nejen celková odezva, ale také se cluster výrazně stabilizoval.
Pokud jde o ladění paměti, jako první je třeba se podívat na subsystém virtuální paměti (VM, virtuální paměť), který má velké množství možností, které vás mohou zmást.
vm.swappiness
Parametr vm.swappiness určuje, jak moc jádro využívá swap (swap, stránkování) ve srovnání s RAM. Ve zdrojovém kódu je také definována jako „tendence krást mapovanou paměť“. Vysoká swappiness znamená, že jádro bude více nakloněno swapování mapovaných stránek. Nízká hodnota swappiness znamená opak: jádro bude méně stránkovat z paměti. Jinými slovy, čím vyšší je hodnota vm.swappiness, tím více bude systém používat swap.
Velké používání swapování je nežádoucí, protože velké bloky dat se načítají a uvolňují do paměti RAM. Mnoho lidí tvrdí, že hodnota swapiness by měla být velká, ale podle mých zkušeností nastavení na „0“ vede k lepšímu výkonu.
Více si můžete přečíst zde -
Ale opět, tato nastavení by měla být aplikována opatrně a pouze po otestování konkrétní aplikace. U vysoce zatížených streamovacích aplikací by měl být tento parametr nastaven na "0". Při změně na „0“ se zlepší odezva systému.
vm.vfs_cache_pressure
Toto nastavení řídí paměť spotřebovanou jádrem pro ukládání adresářů a objektů inode (dentry a inode).
S výchozí hodnotou 100 se jádro pokusí uvolnit mezipaměť dentry a inode na "spravedlivém" základě pro pagecache a swapcache. Snížení vfs_cache_pressure způsobí, že jádro ponechá mezipaměti dentry a inodů. Když je hodnota "0", jádro nikdy nevyprázdní mezipaměť dentry a inode kvůli tlaku paměti a to může snadno vést k chybě nedostatku paměti. Zvýšení vfs_cache_pressure nad 100 způsobí, že jádro upřednostní dentry a vyplachování inodů.
Při použití GlusterFS může mnoho uživatelů s velkým množstvím dat a mnoha malými soubory snadno používat značné množství paměti RAM na serveru kvůli mezipaměti inode/dentry, což může vést ke snížení výkonu, protože jádro musí zpracovávat datové struktury v systému. se 40 GB paměti. Nastavení této hodnoty nad 100 pomohlo mnoha uživatelům dosáhnout spravedlivějšího ukládání do mezipaměti a lepší odezvy jádra.
vm.dirty_background_ratio a vm.dirty_ratio
První parametr (vm.dirty_background_ratio) určuje procento paměti se špinavými stránkami, po jehož dosažení je nutné začít splachovat špinavé stránky na pozadí na disk. Dokud není tohoto procenta dosaženo, nejsou na disk vyprázdněny žádné stránky. A když se restart spustí, běží na pozadí bez přerušení běžících procesů.
Druhý parametr (vm.dirty_ratio) definuje procento paměti, které mohou být obsazeny špinavými stránkami před zahájením nuceného flashování. Jakmile je dosaženo této prahové hodnoty, všechny procesy se stanou synchronními (zablokovány) a není jim dovoleno pokračovat, dokud nebude požadovaný I/O skutečně dokončen a data nebudou na disku. U těžkých I/O to způsobuje problém, protože nedochází k ukládání dat do mezipaměti a všechny procesy provádějící I/O jsou blokovány a čekají na I/O. To vede k velkému počtu zavěšených procesů, vysoké zátěži, nestabilitě systému a nízkému výkonu.
Snížení těchto nastavení způsobí, že data budou na disk vyprázdněna častěji a nebudou uložena v paměti RAM. To může pomoci systémům zatíženým pamětí, kde je normální vyprázdnit 45–90 GB mezipaměti stránek na disk, což má za následek obrovskou latenci frontendových aplikací, snížení celkové odezvy a interaktivity.
"1" > /proc/sys/vm/pagecache
Mezipaměť stránek je mezipaměť, která ukládá data souborů a spustitelných programů, to znamená, že se jedná o stránky se skutečným obsahem souborů nebo blokových zařízení. Tato mezipaměť se používá ke snížení počtu čtení disku. Hodnota „1“ znamená, že 1 % RAM je použito pro mezipaměť a z disku bude více čtení než z RAM. Toto nastavení není nutné měnit, ale pokud jste paranoidní ohledně ovládání mezipaměti stránek, můžete jej použít.
"deadline" > /sys/block/sdc/queue/scheduler
Plánovač I/O je komponenta linuxového jádra, která zpracovává fronty čtení a zápisu. Teoreticky je lepší použít "noop" pro chytrý RAID řadič, protože Linux neví nic o fyzické geometrii disku, takže je efektivnější nechat řadič, který geometrii disku dobře zná, zpracovat požadavek co nejrychleji. možný. Ale vypadá to, že „termín“ zlepšuje výkon. Více o plánovačích si můžete přečíst v dokumentaci zdrojového kódu jádra Linuxu: linux/Documentation/block/*osched.txt. A také jsem viděl zvýšení propustnosti čtení během smíšených operací (mnoho zápisů).
"256" > /sys/block/sdc/queue/nr_requests
Počet I/O požadavků ve vyrovnávací paměti, než jsou předány plánovači. Velikost vnitřní fronty některých řadičů (queue_depth) je větší než nr_requests plánovače I/O, takže plánovač I/O má malou šanci správně stanovit prioritu a sloučit požadavky. U plánovačů termínů a CFQ je lepší, když nr_requests je dvojnásobek vnitřní fronty řadiče. Sloučení a změna pořadí požadavků pomáhá plánovači lépe reagovat při velkém zatížení.
echo "16" > /proc/sys/vm/page-cluster
Parametr page-cluster řídí počet stránek, které jsou zapsány do swapu najednou. Ve výše uvedeném příkladu je hodnota nastavena na „16“ podle velikosti pruhu RAID 64 KB. S swappiness = 0 to nedává smysl, ale pokud nastavíte swappiness na 10 nebo 20, pak použití této hodnoty vám pomůže, když je velikost pruhu RAID 64 kB.
blockdev --setra 4096 /dev/<devname> (-sdb, hdc nebo dev_mapper)
Výchozí nastavení blokového zařízení pro mnoho řadičů RAID často vede k hroznému výkonu. Přidání výše uvedené možnosti nastaví předčítání pro sektory 4096 * 512 bajtů. Přinejmenším u streamovacích operací se rychlost zvyšuje naplněním diskové mezipaměti na čipu čtením napřed během období, které jádro používá k přípravě I/O. Mezipaměť může obsahovat data, která budou požadována při příštím čtení. Příliš mnoho předběžného načítání může u velkých souborů zabít náhodné I/O, pokud spotřebovává potenciálně užitečný čas na disku nebo načítá data mimo mezipaměť.
Níže je uvedeno několik dalších doporučení na úrovni souborového systému. Ale ještě nebyly vyzkoušeny. Ujistěte se, že váš souborový systém zná velikost proužku a počet disků v poli. Například, že se jedná o 5K stripe raid64 pole šesti disků (ve skutečnosti pěti, protože jeden disk se používá pro paritu). Tato doporučení vycházejí z teoretických předpokladů a sestavují je z různých blogů/článků odborníci na RAID.
-> 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))U velkých souborů zvažte zvětšení výše uvedených velikostí pruhů.
VAROVÁNÍ! Vše popsané výše je u některých typů aplikací vysoce subjektivní. Tento článek nezaručuje žádná vylepšení bez předchozího uživatelského testování souvisejících aplikací. Měl by být používán pouze v případě, že je nutné zlepšit celkovou odezvu systému, nebo pokud řeší aktuální problémy.
Další materiály:
Přečtěte si více
Zdroj: www.habr.com