De vertaling van het artikel is gemaakt aan de vooravond van de start van de cursus .
Periodiek rijzen hier en daar vragen over de aanbevelingen van Gluster met betrekking tot kerneltuning en of daar wel behoefte aan is.
Zo'n behoefte doet zich zelden voor. Op de meeste workloads presteert de kernel erg goed. Hoewel er een keerzijde is. Historisch gezien was de Linux-kernel bereid om veel geheugen te verbruiken als hij de kans kreeg, ook voor caching als de belangrijkste manier om de prestaties te verbeteren.
In de meeste gevallen werkt dit prima, maar onder zware belasting kan dit tot problemen leiden.
We hebben veel ervaring met geheugenintensieve systemen zoals CAD, EDA en dergelijke, die onder zware belasting langzamer gingen werken. En soms kwamen we problemen tegen in Gluster. Na vele dagen zorgvuldig het geheugengebruik en de latentie van de schijf te hebben geobserveerd, kregen we hun overbelasting, enorme iowait, kernelfouten (kernel oops), bevriezingen, enz.
Dit artikel is het resultaat van vele afstemmingsexperimenten die in verschillende situaties zijn uitgevoerd. Dankzij deze parameters is niet alleen de algemene responsiviteit verbeterd, maar is het cluster ook aanzienlijk gestabiliseerd.
Als het gaat om geheugenafstemming, is het eerste waar u naar moet kijken het virtuele geheugensubsysteem (VM, virtueel geheugen), dat een groot aantal opties heeft die u in verwarring kunnen brengen.
vm.swappiness
Parameter vm.swappiness bepaalt hoeveel de kernel swap (swap, paging) gebruikt in vergelijking met RAM. Het wordt ook in de broncode gedefinieerd als "neiging om toegewezen geheugen te stelen". Een hoge swappiness betekent dat de kernel meer geneigd zal zijn om toegewezen pagina's om te wisselen. Een lage swappiness-waarde betekent het tegenovergestelde: de kernel zal minder uit het geheugen bladeren. Met andere woorden, hoe hoger de waarde vm.swappiness, hoe meer het systeem swap zal gebruiken.
Een groot gebruik van swapping is onwenselijk, aangezien enorme datablokken in RAM worden geladen en gelost. Veel mensen beweren dat de swapiness-waarde groot zou moeten zijn, maar in mijn ervaring leidt het instellen op "0" tot betere prestaties.
U kunt hier meer lezen -
Maar nogmaals, deze instellingen moeten met zorg worden toegepast en alleen na het testen van een bepaalde toepassing. Voor sterk belaste streaming-applicaties moet deze parameter op "0" worden gezet. Wanneer gewijzigd in "0", verbetert de reactietijd van het systeem.
vm.vfs_cache_druk
Deze instelling regelt het geheugen dat door de kernel wordt gebruikt voor het cachen van directory- en inode-objecten (dentry en inode).
Met een standaardwaarde van 100 zal de kernel proberen de dentry- en inode-caches op een "eerlijke" basis vrij te maken voor pagecache en swapcache. Het verlagen van vfs_cache_pressure zorgt ervoor dat de kernel dentry- en inode-caches behoudt. Als de waarde "0" is, zal de kernel nooit de dentry- en inode-cache leegmaken vanwege geheugendruk, en dit kan gemakkelijk leiden tot een geheugenfout. Het verhogen van vfs_cache_pressure boven de 100 zorgt ervoor dat de kernel voorrang geeft aan dentry en inode flushing.
Bij het gebruik van GlusterFS kunnen veel gebruikers met grote hoeveelheden gegevens en veel kleine bestanden gemakkelijk een aanzienlijke hoeveelheid RAM op de server gebruiken vanwege inode/dentry caching, wat kan leiden tot verslechtering van de prestaties omdat de kernel gegevensstructuren op een systeem moet verwerken met 40 GB geheugen. Het instellen van deze waarde boven de 100 heeft veel gebruikers geholpen om eerlijkere caching en verbeterde kernelresponsiviteit te bereiken.
vm.dirty_background_ratio en vm.dirty_ratio
Eerste parameter (vm.dirty_background_ratio) bepaalt het percentage van het geheugen met vuile pagina's, waarna het nodig is om vuile pagina's op de achtergrond naar schijf te spoelen. Totdat dit percentage is bereikt, worden er geen pagina's naar schijf gewist. En wanneer een reset begint, wordt deze op de achtergrond uitgevoerd zonder lopende processen te onderbreken.
De tweede parameter (vm.dirty_ratio) definieert het percentage van het geheugen dat kan worden ingenomen door vuile pagina's voordat geforceerd flitsen begint. Zodra deze drempel is bereikt, worden alle processen synchroon (geblokkeerd) en mogen ze niet doorgaan totdat de gevraagde I/O daadwerkelijk is voltooid en de gegevens op schijf staan. Bij zware I/O veroorzaakt dit een probleem omdat er geen gegevenscaching is en alle processen die I/O uitvoeren, worden geblokkeerd in afwachting van I/O. Dit leidt tot een groot aantal vastgelopen processen, hoge belasting, systeeminstabiliteit en slechte prestaties.
Als u deze instellingen verlaagt, worden gegevens vaker naar de schijf gespoeld en niet in het RAM-geheugen opgeslagen. Dit kan geheugenzware systemen helpen die het goed vinden om paginacaches van 45-90 GB naar schijf te spoelen, wat resulteert in enorme latentie voor front-end-applicaties, waardoor de algehele responsiviteit en interactiviteit afnemen.
"1" > /proc/sys/vm/pagecache
Een paginacache is een cache die de gegevens van bestanden en uitvoerbare programma's opslaat, dat wil zeggen, dit zijn pagina's met de daadwerkelijke inhoud van bestanden of blokkeerapparaten. Deze cache wordt gebruikt om het aantal schijfleesbewerkingen te verminderen. Een waarde van "1" betekent dat 1% van het RAM wordt gebruikt voor de cache en dat er meer wordt gelezen van de schijf dan van het RAM. Het is niet nodig om deze instelling te wijzigen, maar als u paranoïde bent over het besturen van de paginacache, kunt u deze gebruiken.
"deadline" > /sys/block/sdc/queue/scheduler
De I/O-planner is een Linux-kernelcomponent die lees- en schrijfwachtrijen afhandelt. In theorie is het beter om "noop" te gebruiken voor een slimme RAID-controller, omdat Linux niets weet over de fysieke geometrie van de schijf, dus is het efficiënter om de controller, die de schijfgeometrie goed kent, het verzoek zo snel mogelijk te laten verwerken. mogelijk. Maar het lijkt erop dat "deadline" de prestaties verbetert. U kunt meer lezen over planners in de broncodedocumentatie van de Linux-kernel: linux/Documentation/block/*osched.txt. En ik heb ook een toename van de leesdoorvoer gezien tijdens gemengde bewerkingen (veel schrijfbewerkingen).
"256" > /sys/block/sdc/queue/nr_requests
Het aantal I/O-verzoeken in de buffer voordat ze worden doorgegeven aan de planner. De interne wachtrijgrootte van sommige controllers (queue_depth) is groter dan de nr_requests van de I/O-planner, dus de I/O-planner heeft weinig kans om de juiste prioriteiten te stellen en verzoeken samen te voegen. Voor deadline- en CFQ-planners is het beter wanneer nr_requests 2 keer de interne wachtrij van de controller is. Door verzoeken samen te voegen en opnieuw te ordenen, kan de planner beter reageren onder zware belasting.
echo "16" > /proc/sys/vm/page-cluster
De paginaclusterparameter bepaalt het aantal pagina's dat tegelijk naar de swap wordt geschreven. In het bovenstaande voorbeeld is de waarde ingesteld op "16" volgens de RAID-stripegrootte van 64 KB. Het heeft geen zin met swappiness = 0, maar als je swappiness instelt op 10 of 20, zal het gebruik van deze waarde je helpen wanneer de RAID-stripe-grootte 64K is.
blockdev --setra 4096 /dev/<devnaam> (-sdb, hdc of dev_mapper)
De standaard blokapparaatinstellingen voor veel RAID-controllers resulteren vaak in vreselijke prestaties. Door de bovenstaande optie toe te voegen, wordt read-ahead ingesteld voor sectoren van 4096 * 512 bytes. Voor streamingbewerkingen wordt de snelheid op zijn minst verhoogd door de schijfcache op de chip te vullen met vooruitlezen gedurende de periode die door de kernel wordt gebruikt om I/O voor te bereiden. De cache kan gegevens bevatten die bij de volgende lezing worden opgevraagd. Te veel prefetch kan willekeurige I/O voor grote bestanden vernietigen als het mogelijk nuttige schijftijd verbruikt of gegevens buiten de cache laadt.
Hieronder staan nog enkele aanbevelingen op bestandssysteemniveau. Maar ze zijn nog niet getest. Zorg ervoor dat uw bestandssysteem de grootte van de streep en het aantal schijven in de array kent. Bijvoorbeeld dat dit een 5K stripe raid64-array is van zes schijven (eigenlijk vijf, omdat één schijf wordt gebruikt voor pariteit). Deze aanbevelingen zijn gebaseerd op theoretische aannames en samengesteld uit verschillende blogs/artikelen door RAID-experts.
-> 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))Overweeg voor grote bestanden de hierboven vermelde stripe-afmetingen te vergroten.
LET Alles wat hierboven is beschreven, is zeer subjectief voor sommige soorten toepassingen. Dit artikel garandeert geen verbeteringen zonder voorafgaande gebruikerstests van gerelateerde applicaties. Het mag alleen worden gebruikt als het nodig is om de algehele responsiviteit van het systeem te verbeteren, of als het huidige problemen oplost.
Aanvullende materialen:
Lees verder
Bron: www.habr.com