🥇Configuring the Linux Kernel for GlusterFS

Artikkelen er oversatt i forkant av oppstarten av kurset «Administrator Linux. Professionell».

Det oppstår fra tid til annen spørsmål om Gluster sine anbefalinger for kjerneinnstillinger og om det er nødvendig.

Slik nødvendighet oppstår sjelden. I de fleste belastninger fungerer kjernen veldig bra. Men det er også en annen side. Historisk har Linux-kjernen vært kjent for å konsumere mye minne hvis den får muligheten, inkludert for caching som den primære metoden for å øke ytelsen.

I de fleste tilfeller fungerer dette utmerket, men ved høy belastning kan det føre til problemer.

Vi har stor erfaring med systemer som bruker mye minne, som CAD, EDA og lignende, som begynte å henge seg opp ved høy belastning. Og av og til har vi opplevd problemer med Gluster. Etter å ha overvåket bruken av minne og ventetid på disker i flere dager, fikk vi dem til å overbelaste, med enorme iowait, kjernfeil (kernel oops), henginger, osv.

Denne artikkelen er et resultat av mange eksperimenter med justering av parametere utført i ulike situasjoner. Takket være disse parameterne har ikke bare responsiviteten forbedret seg generelt, men også stabiliteten i klyngen har økt betydelig.

Når det kommer til minneinnstillinger, er det første man må se på underrutinen for virtuell hukommelse (VM, virtual memory), som har et stort antall alternativer som kan forvirre deg.

vm.swappiness

Parameter vm.swappiness Angir hvor mye kjernen bruker swapping (swap, sidekopiering) i forhold til RAM. I kildekoden er det også definert som «tendency to steal mapped memory» (tendens til å stjele kartlagt minne). Høyt swappiness-verdi betyr at kjernen er mer tilbøyelig til å laste ut kartlagte sider. Lavt swappiness-verdi betyr det motsatte: kjernen vil laste ut færre sider fra minnet. Med andre ord, jo høyere verdi vm.swappiness, jo mer vil systemet bruke swap.

Omfattende bruk av swapping er uønsket, ettersom enorme datablokker lastes inn og ut av RAM. Mange hevder at swapiness-verdien bør være høy, men etter min erfaring fører innstilling til «0» til bedre ytelse.

Du kan lese mer om dette her — lwn.net/Articles/100978

Men, igjen, disse innstillingene må anvendes med forsiktighet og kun etter testing av det spesifikke programmet. For høybelastede strømmende applikasjoner bør dette parameteret settes til "0". Ved endring til "0" forbedres systemresponsen.

vm.vfs_cache_pressure

Dette parameteret kontrollerer minnet som brukes av kjernen for å cache katalogobjekter og indeksdeskriptorer (dentry og inode).

Når standard verdien er 100, vil kjernen prøve å frigjøre dentry- og inode-cache "rettferdig" i forhold til pagecache og swapcache. Reduksjon av vfs_cache_pressure fører til at kjernen beholder dentry- og inode-cache. Når verdien er "0", vil ikke kjernen rydde dentry- og inode-cache på grunn av minnepress, noe som lett kan føre til en out-of-memory-feil. Økning av vfs_cache_pressure utover 100 fører til at kjernen prioriterer å tømme dentry- og inode-cache.

Ved bruk av GlusterFS kan mange brukere med store datamengder og mange små filer enkelt bruke betydelig mengde RAM på serveren på grunn av inode/dentry caching, noe som kan føre til redusert ytelse, ettersom kjernen må håndtere datastrukturer i et system med 40 GB minne. Å sette dette parameteret over 100 har hjulpet mange brukere oppnå en mer rettferdig caching og forbedret kernel-respons.

vm.dirty_background_ratio og vm.dirty_ratio

Den første parameteren (vm.dirty_background_ratio) definerer prosentandelen av minnet med skitne sider, hvorpå det må begynne en bakgrunnsutløsning av skitne sider til disk. Så lenge denne prosentandelen ikke er nådd, blir sidene ikke utløst til disk. Når utløsningen begynner, skjer det i bakgrunnen og forstyrrer ikke de kjørende prosessene.

Den andre parameteren (vm.dirty_ratio) definerer prosentandelen av minne som kan være opptatt av skitne sider før tvungen dumping (forced flash) begynner. Når denne grensen nås, blir alle prosessene synkrone (blokkert), og de får ikke lov til å fortsette før den forespurte I/O-operasjonen faktisk er fullført og dataene er lagret på disken. Ved høy belastning av I/O skaper dette problemer, ettersom datacaching er fraværende, og alle prosessene som utfører I/O blir blokkert og venter på I/O. Dette fører til mange hengende prosesser, høy belastning, ustabil drift av systemet og dårlig ytelse.

Å redusere verdiene av disse parameterne gjør at data oftere dumpes til disken og ikke oppbevares i RAM. Dette kan hjelpe systemer med mye minne, der det er normalt å dumpe 45–90 GB med kjernepages til disken, noe som fører til massive ventetider for frontend-applikasjoner, og reduserer den totale responsiviteten og interaktiviteten.

«1» > /proc/sys/vm/pagecache

Sidelageret (page cache) er et cache der data fra filer og utførbare programmer lagres, det vil si sider med faktisk innhold fra filer eller blokker. Denne cachen brukes for å redusere antall lesinger fra disken. Verdien «1» betyr at 1% av RAM brukes for cachen, og antallet leseoperasjoner fra disken vil være høyere enn fra RAM. Det er ikke nødvendig å endre denne parameteren, men hvis du er paranoid når det gjelder kontroll over sidelageret, kan du bruke den.

«deadline» > /sys/block/sdc/queue/scheduler

I/O-planleggeren (I/O scheduler) er et kjernekomponent i Linux som håndterer køer for lesing og skriving. Teoretisk sett er det bedre å bruke «noop» for en smart RAID-kontroller, fordi Linux ikke vet noe om den fysiske geometrien til disken, så det er mer effektivt å la kontrolleren, som godt kjenner disks geometriske oppsett, behandle forespørselen så raskt som mulig. Men det ser ut til at «deadline» forbedrer ytelsen. Mer om planleggerne kan leses i dokumentasjonen til kildekoden til Linux-kjernen: linux/Documentation/block/*osched.txt. Jeg har også observert en økning i lesehastighet under blandede operasjoner (mange skriveoperasjoner).

«256» > /sys/block/sdc/queue/nr_requests

Antall I/O-forespørsel i bufferen før de sendes til planleggeren. Størrelsen på den interne køen for noen kontroller (queue_depth) er større enn nr_requests for I/O-planleggeren, noe som gir lite rom for at I/O-planleggeren kan prioritere og utføre forespørselssammenslåing korrekt. For deadline- og CFQ-planleggere er det best når nr_requests er dobbelt så stort som den interne køen til kontrolleren. Sammenslåing og omorganisering av forespørslene hjelper planleggeren med å være mer responsiv under høy belastning.

echo «16» > /proc/sys/vm/page-cluster

Parameteren page-cluster styrer antallet sider som skrives til swap om gangen. I eksempelet ovenfor settes verdien til «16» i samsvar med stripe-størrelsen (stripe size) av RAID til 64 KB. Dette gir ikke mening med swappiness = 0, men hvis du har satt swappiness til 10 eller 20, vil dette hjelpe deg når stripe-størrelsen for RAID er 64 KB.

blockdev —setra 4096 /dev/`<`devname`>` (-sdb, hdc eller dev_mapper)

Standardinnstillingene for blokkenheter for mange RAID-kontrollere fører ofte til forferdelig ytelse. Å legge til alternativet ovenfor konfigurerer forhåndslesing for 4096 * 512-byte sektorer. I det minste for strømmende operasjoner øker dette hastigheten ved å fylle den innebygde diskbufferen via forhåndslesing i løpet av den tiden kjernen bruker til å forberede I/O. Data kan buffres som vil bli forespurt ved neste lesing. For mye forhåndslesing kan ødelegge tilfeldig I/O for store filer hvis den bruker potensielt nyttig disk-tid eller henter data utenfor cachen.

Her er noen flere anbefalinger på filsystemnivå. Men de har ikke blitt testet ennå. Sørg for at filsystemet ditt kjenner stripe-størrelsen og antallet disker i oppsettet. For eksempel at dette er et raid5-oppsett med en stripe-størrelse på 64K fra seks disker (faktisk fem, ettersom en disk brukes til paritet). Disse anbefalingene er basert på teoretiske antagelser og samlet fra forskjellige blogger/artikler av RAID-eksperter.

-> ext4 fs, 5 disker, 64K stripe, enheter i 4K blokker
mkfs -text4 -E stride=$((64/4))
-> xfs, 5 disker, 64K stripe, enheter i 512-byte sektorer
mkfs -txfs -d sunit=$((64*2)) -d swidth=$((5*64*2))

For large files, you might consider increasing the previously mentioned stripe sizes.

WARNING! Everything described above is highly subjective for certain types of applications. This article does not guarantee any improvements without prior testing of the corresponding applications by the user. It should only be applied if it improves overall system responsiveness or if it addresses current issues.