Prevod članka pripremljen je uoči početka kursa .
Občas se objevují dotazy na doporučení Gluster ohledně konfigurace jádra a zda je to nezbytné.
Taková potřeba se objevuje zřídka. Většina zátěží pracuje s jádrem velmi dobře. Existuje však i druhá stránka. Historicky je jádro Linuxu ochotné spotřebovávat velké množství paměti, pokud mu to dovolíte, včetně cachingu jako hlavního způsobu zvyšování výkonu.
Ve většině případů to funguje skvěle, ale při vysokém zatížení to může vést k problémům.
Máme bohaté zkušenosti se systémy s vysokou spotřebou paměti, jako jsou CAD, EDA a podobné, které začaly zpomalovat při vysokém zatížení. A občas jsme se setkali s problémy v Glusteru. Pečlivým pozorováním využití paměti a čekacími časy disků jsme zaznamenali jejich přetížení, obrovské iowait, chyby jádra (kernel oops), zavěšení systému atd.
Tento článek je výsledkem mnoha experimentů s nastavením parametrů provedených v různých situacích. Díky těmto parametrům se nejen zlepšila celková odezva, ale také výrazně stabilizoval chod klastru.
Pokud jde o nastavení paměti, je nejprve důležité se podívat na subsystém virtuální paměti (VM, virtual memory), který má širokou škálu možností, které mohou být matoucí.
vm.swappiness
Parametri vm.swappiness určuje, jak moc jádro používá swapování ve srovnání s operační pamětí. V zdrojovém kódu je také definován jako „tendence krást mapovanou paměť“. Vyšší hodnota swappiness znamená, že jádro bude více ochotné vykládat mapované stránky. Nižší hodnota swappiness znamená opak: jádro bude méně vykládat stránky z paměti. Jinými slovy, čím vyšší hodnota vm.swappiness, tím více systém využije swap.
Velké využívání swapování je nežádoucí, protože se do operační paměti a z ní načítají velké bloky dat. Mnozí tvrdí, že hodnota swapiness by měla být vysoká, ale podle mé zkušenosti vede k zvýšení výkonu nastavení na „0“.
Více informací lze najít zde —
Vendar pa je treba te nastavitve uporabljati previdno in le po preizkusu konkretne aplikacije. Za visoko obremenjene tokovne aplikacije je treba ta parameter nastaviti na "0". Z nastavitvijo na "0" se izboljša odzivnost sistema.
vm.vfs_cache_pressure
Ta parameter upravlja pomnilnik, ki ga jedro porabi za predpomnjenje objektov map in indeksnih descriptorjev (dentry in inode).
Pri privzeti vrednosti 100 jedro poskuša sprostiti predpomnilnik dentry in inode po "pravičnosti" glede na pagecache in swapcache. Zmanjšanje vfs_cache_pressure povzroči, da jedro obdrži predpomnilnike dentry in inode. Ko je vrednost "0", jedro nikoli ne bo čistilo predpomnilnika dentry in inode zaradi pomanjkanja pomnilnika (memory pressure), kar lahko zlahka privede do napake out-of-memory. Povečanje vfs_cache_pressure nad 100 povzroči, da jedro da prednost praznjenju dentry in inode.
Pri uporabi GlusterFS veliko uporabnikov z obsežnimi podatki in številnimi majhnimi datotekami lahko na strežniku zlahka porabi znatno količino RAM-a zaradi predpomnjenja inode/dentry, kar lahko povzroči zmanjšanje zmogljivosti, saj se jedro mora ukvarjati s podatkovnimi strukturami v sistemu z 40 GB pomnilnika. Nastavitev tega parametra nad 100 je mnogim uporabnikom pomagala doseči bolj pošteno predpomnjenje in izboljšati odzivnost jedra.
vm.dirty_background_ratio in vm.dirty_ratio
Prvi parameter (vm.dirty_background_ratio) določa odstotek pomnilnika z umazanimi stranmi, ki ga je treba doseči, preden se začne ozadnje čiščenje umazanih strani na disk. Dokler ta odstotek ni dosežen, se strani ne izvržejo na disk. Ko se čiščenje začne, poteka v ozadju in ne prekine delujočih procesov.
Drugi parameter (vm.dirty_ratio) določa odstotek pomnilnika, ki ga lahko zasedejo umazane strani, preden se začne prisilno praznjenje (forced flash). Ko ta prag doseže, postanejo vsi procesi sinhroni (blokirani) in jim ni dovoljeno nadaljevati dela, dokler operacija vnosa-izvoda, ki jo zahtevajo, ni dejansko končana in podatki niso shranjeni na disku. Pri močno obremenjenem vnosu-izvodu to povzroča težave, saj ni predpomnjenja podatkov in se vsi procesi, ki izvajajo vnose-izvode, blokirajo v pričakovanju vnosa-izvoda. To vodi do velikega števila blokiranih procesov, visoke obremenitve, nestabilnega delovanja sistema in slabe zmogljivosti.
Zmanjšanje vrednosti teh parametrov pomeni, da se podatki pogosteje zapisujejo na disk in se ne shranjujejo v RAM-u. To lahko pomaga sistemom z veliko pomnilnika, ki jim je normalno zapisovati na disk predpomnilnik strani velikosti 45–90 GB, kar povzroča ogromna čakalna obdobja za sprednje aplikacije ter zmanjšuje splošno odzivnost in interaktivnost.
«1» > /proc/sys/vm/pagecache
Predpomnilnik strani (page cache) je predpomnilnik, v katerem so shranjeni podatki datotek in izvršljivih programov, kar pomeni, da so to strani z dejansko vsebino datotek ali blokovnih naprav. Ta predpomnilnik se uporablja za zmanjšanje števila branj z diska. Vrednost «1» pomeni, da se za predpomnilnik uporablja 1% RAM-a in bo več branja z diska kot iz RAM-a. Ni nujno spreminjati te nastavitve, vendar jo lahko uporabite, če ste paranoidni glede nadzora nad predpomnilnikom strani.
«deadline» > /sys/block/sdc/queue/scheduler
Planer vnosa-izvoda (I/O scheduler) je komponenta jedra Linux, ki upravlja z vrstami branja in pisanja. Teoretično je za pametni RAID-nadzornik najbolje uporabljati «noop», ker Linux ne ve nič o fizični geometriji diska, zato je učinkoviteje pustiti nadzorniku, ki dobro pozna geometrijo diska, da čim hitreje obdeluje zahtevke. Vendar se zdi, da «deadline» povečuje zmogljivost. Več o planerjih lahko preberete v dokumentaciji izvorne kode jedra Linux: linux/Documentation/block/*osched.txt. In tudi opazil sem povečanje propustnosti branja med mešanimi operacijami (mnoge operacije pisanja).
«256» > /sys/block/sdc/queue/nr_requests
Število vhodno-izhodnih poizvedb v predpomnilniku, preden jih prenese načrtovalec. Velikost notranje vrste nekaterih krmilnikov (queue_depth) je večja od števila poizvedb (nr_requests) načrtovalca vhodno-izhodnih operacij, kar pomeni, da ima načrtovalec malo možnosti, da pravilno prioritizira in združi poizvedbe. Za načrtovalnike deadline in CFQ je bolje, da je nr_requests dvakratnik notranje vrste krmilnika. Zajemanje in preurejanje poizvedb pomaga načrtovalcu, da je bolj odziven pri visokih obremenitvah.
echo "16" > /proc/sys/vm/page-cluster
Parameter page-cluster ureja število strani, ki se hkrati zapišejo v swap. V zgornjem primeru je vrednost nastavljena na "16" v skladu z velikostjo trakovanja (stripe size) RAID-a v 64 KB. To nima smisla pri swappiness = 0, vendar če ste nastavili swappiness na 10 ali 20, vam bo uporaba te vrednosti pomagala, ko je velikost trakovanja RAID 64 KB.
blockdev --setra 4096 /dev/<devname> (-sdb, hdc ali dev_mapper)
Privzete nastavitve blokovnih naprav za številne RAID krmilnike pogosto povzročajo slabo zmogljivost. Dodajanje zgoraj navedene možnosti nastavi predhodno branje za 4096 * 512-bajtne sektors. Vsaj za zaporedne operacije se poveča hitrost, ko se napolni vgrajen predpomnilnik diska s predhodnim branjem v obdobju, ki ga jedro uporablja za pripravo vhodno-izhodnih operacij. V predpomnilnik lahko pridejo podatki, ki jih bodo zahtevali pri naslednjem branju. Preveliko predhodno branje lahko uniči naključno vhodno-izhodno za velike datoteke, če koristi potencialno uporabni čas diska ali naloži podatke izven predpomnilnika.
Spodaj so še nekateri priporočila na ravni datotečnega sistema. Vendar še niso bila testirana. Prepričajte se, da vaš datotečni sistem ve o velikosti trakovanja in številu diskov v nizu. Na primer, da je to niz raid5 z velikostjo trakovanja 64K iz šestih diskov (v resnici petih, ker se en disk uporablja za pariteto). Ta priporočila temeljijo na teoretičnih predpostavkah in so zbrana iz različnih blogov/prištevkov strokovnjakov za RAID.
-> ext4 fs, 5 diskov, 64K trak, enote v 4K blokih
mkfs -text4 -E stride=$((64/4))
-> xfs, 5 diskov, 64K trak, enote v 512-bajtnih sektorjih
mkfs -txfs -d sunit=$((64*2)) -d swidth=$((5*64*2))Za velike datoteke lahko razmislite o povečanju zgoraj navedenih velikosti trakov.
POZOR! Vse, kar je opisano zgoraj, je izjemno subjektivno za nekatere vrste aplikacij. Ta članek ne zagotavlja nobenih izboljšav brez predhodnega testiranja ustreznih aplikacij s strani uporabnika. Uporabiti ga je treba le, kadar je potrebno izboljšati splošno odzivnost sistema ali če rešuje trenutne težave.
Dodatni materiali:
Preberite več
Izvor: habr.com
