🥇Kernelconfiguratie Linux voor GlusterFS

De vertaling van het artikel is gemaakt aan de vooravond van de start van de cursus Beheerder LinuxProfessioneel».

Er ontstaan zo nu en dan vragen over de aanbevelingen van Gluster met betrekking tot het afstemmen van de kernel en of dit noodzakelijk is.

Deze behoefte doet zich zelden voor. Onder de meeste werkbelastingen presteert de kern zeer goed. Er is echter een keerzijde. Historisch gezien heeft de kern Linux Het programma verbruikt, indien mogelijk, veel geheugen, onder andere voor caching als belangrijkste manier om de prestaties te verbeteren.

In de meeste gevallen werkt dit prima, maar bij zware belasting kan het problemen opleveren.

Wij hebben ruime ervaring met geheugenintensieve systemen zoals CAD, EDA en vergelijkbare systemen die bij hoge belasting trager worden. En soms liepen we tegen problemen aan in Gluster. Nadat we het geheugengebruik en de wachttijden op de schijf gedurende meer dan een dag nauwlettend in de gaten hadden gehouden, kwamen we tot de conclusie dat ze overbelast waren, enorme iowait-fouten opleverden, kernel-oops, vastlopers, enzovoort.

Dit artikel is het resultaat van een groot aantal parameterafstemmingsexperimenten die in verschillende situaties zijn uitgevoerd. Dankzij deze parameters is niet alleen de algemene responsiviteit verbeterd, maar is ook de werking van het cluster aanzienlijk gestabiliseerd.

Wanneer u het geheugen configureert, moet u eerst naar het virtuele geheugen (VM)-subsysteem kijken. Dit heeft een groot aantal opties die verwarrend kunnen zijn.

vm.swappiness

Parameter vm.swappiness bepaalt hoeveel swap de kernel gebruikt in vergelijking met RAM. In de broncode wordt dit ook gedefinieerd als "neiging tot diefstal van toegewezen geheugen". Een hoge swappiness-waarde betekent dat de kernel meer geneigd is om toegewezen pagina's te verwisselen. Een lage swappiness-waarde betekent het tegenovergestelde: de kernel zal minder pagina's uit het geheugen swappen. Met andere woorden: hoe hoger de waarde vm.swappinesshoe meer het systeem swap zal gebruiken.

Het is ongewenst om veel swap-bestanden te gebruiken, omdat er dan grote hoeveelheden data in het RAM-geheugen worden geladen en gelost. Veel mensen beweren dat de swapiness-waarde hoog moet zijn, maar in mijn ervaring levert een waarde van 0 betere prestaties op.

U kunt hier meer lezen - lwn.net/Artikelen/100978

Maar nogmaals, deze instellingen moeten met de nodige voorzichtigheid worden gebruikt en moeten alleen worden gebruikt nadat u de specifieke toepassing hebt getest. Voor streamingtoepassingen met een hoge belasting moet deze parameter op "0" worden ingesteld. Door de waarde op "0" te zetten, verbetert u de responsiviteit van het systeem.

vm.vfs_cache_druk

Met deze parameter wordt bepaald hoeveel geheugen de kernel gebruikt voor het cachen van directoryobjecten en inodes.

Met de standaardwaarde van 100 zal de kernel proberen de dentry- en inode-caches "eerlijk" vrij te maken ten opzichte van de pagecache en swapcache. Door vfs_cache_pressure te verlagen, behoudt de kernel dentry- en inode-caches. Als de waarde "0" is, zal de kernel de dentry- en inode-cache nooit leegmaken vanwege de geheugendruk. Dit kan gemakkelijk leiden tot een geheugenfout. Als u vfs_cache_pressure boven de 100 verhoogt, geeft de kernel prioriteit aan het uitladen van dentries en inodes.

Bij gebruik van GlusterFS kunnen veel gebruikers met grote hoeveelheden data en veel kleine bestanden al snel een aanzienlijke hoeveelheid RAM op de server verbruiken vanwege inode/dentry-caching. Dit kan leiden tot prestatieverslechtering, omdat de kernel datastructuren moet verwerken op een systeem met 40 GB geheugen. Door deze parameter op meer dan 100 in te stellen, hebben veel gebruikers een eerlijkere caching bereikt en is de reactiesnelheid van de kernel verbeterd.

vm.dirty_background_ratio en vm.dirty_ratio

Eerste parameter (vm.dirty_background_ratio) definieert het percentage geheugen met vuile pagina's. Bij het bereiken hiervan is het nodig om de vuile pagina's op de achtergrond naar schijf te wissen. Zolang dit percentage niet bereikt is, worden de pagina's niet naar schijf gekopieerd. En als het resetten begint, gebeurt dit op de achtergrond, zonder dat de lopende processen worden onderbroken.

De tweede parameter (vm.dirty_ratio) bepaalt het percentage geheugen dat kan worden ingenomen door vuile pagina's voordat een geforceerde flash plaatsvindt. Zodra deze drempelwaarde is bereikt, worden alle processen synchroon (geblokkeerd) en mogen ze niet meer worden uitgevoerd totdat de door hen aangevraagde I/O-bewerking daadwerkelijk is voltooid en de gegevens op de schijf staan. Bij een zware I/O-belasting veroorzaakt dit een probleem, omdat er geen gegevenscache is en alle processen die I/O uitvoeren, worden geblokkeerd in afwachting van I/O. Het gevolg is dat er veel processen vastlopen, de belasting hoog is, het systeem onstabiel functioneert en de prestaties slecht zijn.

Wanneer u de waarden van deze parameters verlaagt, worden gegevens vaker naar schijf geschreven en niet in het RAM-geheugen opgeslagen. Dit kan nuttig zijn voor systemen die veel geheugen gebruiken en die normaal gesproken 45-90 GB aan paginacache naar schijf kopiëren, wat resulteert in een enorme latentie voor front-endtoepassingen, waardoor de algehele responsiviteit en interactiviteit afnemen.

"1" > /proc/sys/vm/pagecache

Een pagina-cache is een cache waarin gegevens van bestanden en uitvoerbare programma's worden opgeslagen, dat wil zeggen pagina's met de daadwerkelijke inhoud van bestanden of blok-apparaten. Deze cache wordt gebruikt om het aantal schijfleesbewerkingen te verminderen. De waarde "1" betekent dat 1% van het RAM-geheugen wordt gebruikt voor cache en dat er meer leesbewerkingen vanaf de schijf dan vanaf het RAM-geheugen plaatsvinden. U hoeft deze instelling niet te wijzigen, maar als u bang bent dat u de pagina-cache niet goed kunt beheren, kunt u deze instelling gebruiken.

"deadline" > /sys/block/sdc/queue/scheduler

De I/O-scheduler is een kernelcomponent. Linux, die de lees- en schrijfwachtrijen afhandelt. Theoretisch gezien is het voor een slimme RAID-controller beter om "noop" te gebruiken, omdat Linux De scheduler weet niets over de fysieke geometrie van de schijf, dus het is efficiënter om de controller, die wel goed op de hoogte is van de schijfgeometrie, het verzoek zo snel mogelijk te laten verwerken. De "deadline" lijkt de prestaties echter te verbeteren. Meer informatie over schedulers is te vinden in de kernelbroncode. Linux: linux/Documentation/block/*osched.txt. En ik zag ook een toename in de leessnelheid tijdens gemengde bewerkingen (veel schrijfbewerkingen).

"256" > /sys/blok/sdc/wachtrij/nr_verzoeken

Het aantal I/O-verzoeken in de buffer voordat ze aan de scheduler worden doorgegeven. De interne wachtrijgrootte (queue_depth) van sommige controllers is groter dan de nr_requests van de I/O-scheduler. Hierdoor heeft de I/O-scheduler weinig kans om verzoeken correct te prioriteren en samen te voegen. Voor deadline- en CFQ-schedulers is het beter wanneer nr_requests 2 keer zo groot is als de interne wachtrij van de controller. Door query's te combineren en opnieuw te ordenen, kan de planner beter reageren bij een zware belasting.

echo "16" > /proc/sys/vm/page-cluster

Met de parameter page-cluster bepaalt u het aantal pagina's dat tegelijk moet worden verwisseld. In het bovenstaande voorbeeld is de waarde ingesteld op '16', zodat deze overeenkomt met de RAID-stripegrootte van 64 KB. Dit is niet logisch met swappiness=0, maar als u swappiness instelt op 10 of 20, dan zal deze waarde u helpen als de RAID-stripegrootte 64 KB is.

blockdev --setra 4096 /dev/`<`devnaam`>` (-sdb, hdc of dev_mapper)

De standaardinstellingen voor blokapparaten voor veel RAID-controllers resulteren vaak in verschrikkelijke prestaties. Als u de bovenstaande optie toevoegt, wordt read-ahead geconfigureerd voor sectoren van 4096*512 bytes. Bij streamingbewerkingen wordt de snelheid in ieder geval verhoogd door de cache op de schijf te vullen met read-ahead gedurende de periode die de kernel gebruikt om I/O voor te bereiden. In de cache kunnen gegevens worden opgeslagen die worden opgevraagd wanneer de cache de volgende keer wordt gelezen. Te veel read-ahead kan willekeurige I/O bij grote bestanden verhinderen als dit potentieel nuttige schijftijd in beslag neemt of gegevens buiten de cache laadt.

Hieronder vindt u nog meer aanbevelingen op bestandssysteemniveau. Maar ze zijn nog niet getest. Zorg ervoor dat uw bestandssysteem de stripegrootte en het aantal schijven in de array kent. Het gaat bijvoorbeeld om een raid5-array met een stripegrootte van 64K en zes schijven (eigenlijk vijf, omdat één schijf wordt gebruikt voor pariteit). Deze aanbevelingen zijn gebaseerd op theoretische aannames en verzameld uit verschillende blogs/artikelen van 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))

Voor grotere bestanden kunt u overwegen de stripgroottes die hierboven zijn aangegeven te vergroten.

LET Alles wat hierboven is beschreven, is voor sommige toepassingen extreem subjectief. Dit artikel garandeert geen enkele verbetering zonder voorafgaande tests van de betreffende applicaties door de gebruiker. Het mag alleen worden gebruikt als er behoefte is om de algemene responsiviteit van het systeem te verbeteren of als het huidige problemen oplost.