{"id":95783,"date":"2020-10-03T13:42:02","date_gmt":"2020-10-03T11:42:02","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/nastrojka-yadra-linux-dlya-glusterfs"},"modified":"2020-10-03T13:42:02","modified_gmt":"2020-10-03T11:42:02","slug":"nastrojka-yadra-linux-dlya-glusterfs","status":"publish","type":"post","link":"https:\/\/prohoster.info\/nl\/blog\/administrirovanie\/nastrojka-yadra-linux-dlya-glusterfs","title":{"rendered":"Configuratie van de Linux-kernel voor GlusterFS","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

De vertaling van het artikel is voorbereid ter voorbereiding op de start van de cursus \u00abLinux Administrator. Professional\u00bb<\/a><\/noindex>.<\/i><\/b><\/p>\n

\"Configuratie<\/p>\n

Er zijn af en toe vragen over Gluster's aanbevelingen met betrekking tot kerninstellingen en of deze noodzakelijk zijn.<\/p>\n

Zo'n noodzaak komt zelden voor. Bij de meeste belasting werkt de kernel zeer goed. Aan de andere kant is er een historisch probleem. De Linux-kernel verbruikt graag veel geheugen als je hem de kans geeft, ook voor caching als de belangrijkste manier om de prestaties te verhogen.<\/a><\/noindex><\/p>\n

In de meeste gevallen werkt dit uitstekend, maar bij hoge belasting kan dit tot problemen leiden. <\/p>\n

We hebben veel ervaring met systemen die veel geheugen gebruiken, zoals CAD, EDA en soortgelijke toepassingen, die begonnen te vertragen onder hoge belasting. Soms hebben we problemen met Gluster ervaren. Door gedurende meerdere dagen de gebruikte geheugen en de schijfwachttijden zorgvuldig te observeren, hebben we overbelasting, enorme iowait, kernel fouten (kernel oops), vastlopers, enzovoort, vastgesteld. <\/p>\n

Dit artikel is het resultaat van vele experimenten met het afstemmen van parameters in verschillende situaties. Dankzij deze parameters is niet alleen de responstijd in het algemeen verbeterd, maar is ook de stabiliteit van het cluster aanzienlijk verbeterd.<\/p>\n

Als het gaat om het afstemmen van geheugen, moet je eerst kijken naar de virtuele geheugensubsystemen (VM, virtual memory), die een groot aantal opties hebben die verwarrend kunnen zijn.<\/p>\n

vm.swappiness<\/h4>\n

\nParameter vm.swappiness<\/code> bepaalt in hoeverre de kernel gebruikmaakt van swap in vergelijking met het RAM-geheugen. In de broncode is het ook gedefinieerd als \u201ctendency to steal mapped memory\u201d (neiging om weergegeven geheugen te stelen). Een hoge swappiness waarde betekent dat de kernel eerder geneigd is om weergegeven pagina's uit te wisselen. Een lage swappiness waarde betekent het tegenovergestelde: de kernel wisselt minder pagina's uit het geheugen. Met andere woorden, hoe hoger de waarde, vm.swappiness<\/code>, des te meer het systeem swap zal gebruiken.<\/p>\n

Groot gebruik van swapping is ongewenst, omdat er enorme datablocks in en uit het RAM-geheugen worden geladen. Veel mensen beweren dat de swapiness waarde hoog moet zijn, maar uit mijn ervaring leidt een instelling op '0' tot betere prestaties.<\/p>\n

Meer details zijn hier te lezen \u2014 lwn.net\/Articles\/100978<\/a><\/noindex> <\/p>\n

Maar nogmaals, deze instellingen moeten voorzichtig worden toegepast en alleen na het testen van de specifieke applicatie. Voor applicaties met hoge belasting moet deze parameter op '0' worden ingesteld. Bij een wijziging naar '0' verbetert de responsiviteit van het systeem.<\/p>\n

vm.vfs_cache_pressure<\/h4>\n

\nDeze parameter controleert het geheugen dat door de kernel wordt gebruikt voor het cachen van directoryobjecten en indexdescriptoren (dentry en inode).<\/p>\n

Bij de standaardwaarde van 100 zal de kernel proberen de dentry- en inode-cache 'eerlijk' vrij te geven ten opzichte van de pagecache en swapcache. Het verlagen van de vfs_cache_pressure zorgt ervoor dat de kernel de dentry- en inode-caches behoudt. Wanneer de waarde '0' is, zal de kernel de dentry- en inode-cache nooit wissen vanwege geheugendruk, wat gemakkelijk tot een out-of-memory-fout kan leiden. Het verhogen van de vfs_cache_pressure boven de 100 zorgt ervoor dat de kernel prioriteit geeft aan het afvoeren van dentry en inode.<\/p>\n

Bij gebruik van GlusterFS kunnen veel gebruikers met grote hoeveelheden gegevens en veel kleine bestanden gemakkelijk aanzienlijke hoeveelheden RAM gebruiken op de server vanwege het cachen van inode\/dentry, wat de prestaties kan verminderen, omdat de kernel dat structuren in een systeem met 40 GB geheugen moet verwerken. Het instellen van deze parameter op meer dan 100 heeft veel gebruikers geholpen om een eerlijker cachen te bereiken en de responsiviteit van de kernel te verbeteren.<\/p>\n

vm.dirty_background_ratio en vm.dirty_ratio<\/h4>\n

\nDe eerste parameter (vm.dirty_background_ratio<\/code>) bepaalt het percentage geheugen met vuile pagina's, dat bereikt moet worden om de achtergrondreset van vuile pagina's naar de schijf te starten. Totdat dit percentage is bereikt, worden de pagina's niet naar de schijf geschreven. En wanneer de reset begint, gebeurt dit op de achtergrond, zonder de actieve processen te onderbreken. <\/p>\n

De tweede parameter (vm.dirty_ratio<\/code>) bepaalt het percentage geheugen dat kan worden bezet door vuile pagina's voordat een geforceerde flush begint. Zodra deze drempel is bereikt, worden alle processen synchroon (gebloqueerd) en is het hen niet toegestaan om door te gaan totdat de invoer-output operatie die zij hebben aangevraagd, daadwerkelijk is voltooid en de gegevens op de schijf staan. Bij hoge invoer-output belasting ontstaat een probleem, aangezien caching van gegevens ontbreekt en alle processen die invoer-output uitvoeren, geblokkeerd worden in afwachting van invoer-output. Dit leidt tot een grote hoeveelheid vastgelopen processen, hoge belasting, instabiliteit van het systeem en slechte prestaties.<\/p>\n

Het verlagen van de waarden van deze parameters zorgt ervoor dat gegevens vaker op de schijf worden weggeschreven en niet in het RAM blijven. Dit kan helpen bij systemen met veel geheugen, waarvoor het normaal is om de pagina-cache van 45\u201390 GB op de schijf weg te schrijven, wat leidt tot enorme wachttijden voor frontend-applicaties, waardoor de algehele responsiviteit en interactie vermindert.<\/p>\n

\u00ab1\u00bb > \/proc\/sys\/vm\/pagecache<\/h4>\n

\nDe pagina-cache (page cache) is een cache waarin gegevens van bestanden en uitvoerbare programma's worden opgeslagen, dat wil zeggen pagina's met de werkelijke inhoud van bestanden of blokapparaten. Deze cache wordt gebruikt om het aantal schijfleesbewerkingen te verminderen. Een waarde van \u00ab1\u00bb betekent dat 1% van het RAM voor de cache wordt gebruikt en er meer leesbewerkingen van de schijf zullen zijn dan vanuit het RAM. Het is niet noodzakelijk om deze parameter te wijzigen, maar als je parano\u00efde bent over het beheer van de pagina-cache, kun je dit gebruiken.<\/p>\n

\u00abdeadline\u00bb > \/sys\/block\/sdc\/queue\/scheduler<\/h4>\n

\nDe invoer-output scheduler (I\/O scheduler) is een onderdeel van de Linux-kernel dat de wachtrijen voor lezen en schrijven beheert. In theorie is het beter om \u00abnoop\u00bb te gebruiken voor een slimme RAID-controller, omdat Linux niets weet over de fysieke geometrie van de schijf, dus het is effici\u00ebnter om de controller, die de geometrie van de schijf goed kent, de verzoeken zo snel mogelijk te laten afhandelen. Maar het lijkt erop dat \u00abdeadline\u00bb de prestaties verhoogt. Meer over schedulers kun je lezen in de documentatie van de Linux-kernelbronnen: linux\/Documentation\/block\/*osched.txt<\/code>. En bovendien heb ik een toename van de leessnelheid waargenomen tijdens gemengde bewerkingen (veel schrijfbewerkingen).<\/p>\n

\u00ab256\u00bb > \/sys\/block\/sdc\/queue\/nr_requests<\/h4>\n

\nHet aantal invoer-uitvoer verzoeken in de buffer voordat ze aan de planner worden doorgegeven. De interne wachtrijgrootte van sommige controllers (queue_depth) is groter dan nr_requests van de invoer-uitvoer planner, waardoor de planner weinig kans heeft om verzoeken correct te prioriteren en samen te voegen. Voor deadline- en CFQ-planners is het beter als nr_requests tweemaal zo groot is als de interne wachtrij van de controller. Het samenvoegen en opnieuw ordenen van verzoeken helpt de planner responsiever te zijn onder zware belasting.<\/p>\n

echo \"16\" > \/proc\/sys\/vm\/page-cluster<\/h4>\n

\nDe parameter page-cluster beheert het aantal pagina's dat in \u00e9\u00e9n keer naar de swap wordt geschreven. In het bovenstaande voorbeeld wordt de waarde ingesteld op \"16\" in overeenstemming met de stripe-grootte van RAID met 64 KB. Dit heeft geen zin bij swappiness = 0, maar als je swappiness op 10 of 20 hebt ingesteld, zal het gebruik van deze waarde je helpen wanneer de RAID stripe-grootte 64 KB bedraagt.<\/p>\n

blockdev \u2014setra 4096 \/dev\/<<\/code>devname><\/code> (-sdb, hdc of dev_mapper)<\/h4>\n

\nDe standaardinstellingen voor blokapparaten bij veel RAID-controllers leiden vaak tot verschrikkelijke prestaties. Het toevoegen van de bovenstaande optie configureert voorspellend lezen voor 4096 * 512-byte sectoren. Tenminste voor gestreamde bewerkingen verhoogt het de snelheid door de ingebouwde schijfcache gevuld te krijgen door voorspellend lezen tijdens de periode die het besturingssysteem gebruikt voor invoer-uitvoer voorbereiding. Gegevens die bij de volgende lezing zullen worden opgevraagd, kunnen in de cache worden geplaatst. Te veel voorspellend lezen kan willekeurige invoer-uitvoer voor grote bestanden vernietigen als het potentieel nuttige tijd van de schijf gebruikt of gegevens buiten de cache laadt.<\/p>\n

Hier zijn nog enkele aanbevelingen op het niveau van het bestandssysteem. Maar deze zijn nog niet getest. Zorg ervoor dat je bestandssysteem de stripe-grootte en het aantal schijven in de array kent. Bijvoorbeeld, dat dit een RAID5 array is met een stripe-grootte van 64K uit zes schijven (feitelijk vijf, omdat \u00e9\u00e9n schijf voor pariteit wordt gebruikt). Deze aanbevelingen zijn gebaseerd op theoretische veronderstellingen en verzameld uit verschillende blogs\/artikelen van RAID-experts.<\/p>\n

-> ext4 fs, 5 schijven, 64K stripe, eenheden in 4K blokken\nmkfs -text4 -E stride=$((64\/4))\n-> xfs, 5 schijven, 64K stripe, eenheden in 512-byte sectoren\nmkfs -txfs -d sunit=$((64*2)) -d swidth=$((5*64*2))<\/code><\/pre>\n
\nVoor grote bestanden kan overwogen worden om de eerder genoemde stripgrootte te verhogen.<\/p>\n
LET OP!<\/b> Alles wat hierboven is beschreven is uiterst subjectief voor bepaalde soorten applicaties. Dit artikel garandeert geen verbeteringen zonder voorafgaand testen van de relevante applicaties door de gebruiker. Het moet alleen worden toegepast indien nodig om de algemene responsiviteit van het systeem te verbeteren of als het huidige problemen oplost.<\/p>\n
Extra materialen:<\/h4>\n
<\/p>\n