🥇Kjerneoppsett Linux for GlusterFS

Oversettelsen av artikkelen ble utarbeidet like før kursstart Administrator LinuxProfesjonell».

Fra tid til annen dukker det opp spørsmål her og der om Glusters anbefalinger angående kjernetilpasning og om det er nødvendig.

Dette behovet oppstår sjelden. Kjernen yter svært bra under de fleste arbeidsbelastninger. Det er imidlertid en ulempe. Historisk sett har kjernen Linux bruker villig mye minne hvis de får muligheten, inkludert for mellomlagring som den viktigste måten å forbedre ytelsen på.

I de fleste tilfeller fungerer dette utmerket, men under stor belastning kan det skape problemer.

Vi har lang erfaring med å jobbe med systemer som bruker mye minne, som CAD, EDA og lignende, som begynte å avta under høy belastning. Og noen ganger møtte vi problemer i Gluster. Etter nøye overvåking av minnet brukt og diskens ventetid i mer enn én dag, fikk vi diskoverbelastning, enorm iowait, kjernefeil (kernel oops), fryser osv.

Denne artikkelen er resultatet av mange parameterinnstillingseksperimenter utført i forskjellige situasjoner. Takket være disse parameterne ble ikke bare responsen generelt forbedret, men også driften av klyngen ble betydelig stabilisert.

Når det kommer til å konfigurere minne, er det første stedet å se på det virtuelle minnesubsystemet (VM), som har et stort antall alternativer som kan forvirre deg.

vm.bytte

Parameter vm.swappiness bestemmer hvor mye kjernen bruker swap sammenlignet med RAM. Det er også definert i kildekoden som "tendens til å stjele kartlagt minne." En høy bytteverdi betyr at kjernen vil være mer utsatt for å bytte kartlagte sider. En lav bytteverdi betyr det motsatte: Kjernen vil bytte sider ut av minnet mindre. Med andre ord, jo høyere verdi vm.swappiness, jo mer vil systemet bruke swap.

Utstrakt bruk av swapping er uønsket, siden enorme blokker med data lastes og losses i RAM. Mange hevder at bytteverdien bør være høy, men min erfaring gir bedre ytelse å sette den til "0".

Du kan lese mer her - lwn.net/Articles/100978

Men igjen, disse innstillingene bør brukes med forsiktighet og bare etter å ha testet den spesifikke applikasjonen. For høyt belastede strømmeapplikasjoner bør denne parameteren settes til "0". Når endret til "0", forbedres systemets reaksjonsevne.

vm.vfs_cache_pressure

Denne innstillingen kontrollerer minnet som forbrukes av kjernen for caching av katalogobjekter og inoder (dentry og inode).

Med standardverdien på 100 vil kjernen forsøke å frigjøre dentry- og inodebufferen på en rettferdig måte til sidecachen og swapcachen. Redusering av vfs_cache_pressure fører til at kjernen bevarer dentry og inode cacher. Når verdien er "0", vil kjernen aldri tømme dentry- og inodebufferen på grunn av minnetrykk, og dette kan lett føre til en minnefeil. Økning av vfs_cache_pressure over 100 fører til at kjernen prioriterer dentry og inode pageouts.

Ved bruk av GlusterFS kan mange brukere med store datamengder og mange små filer enkelt bruke en betydelig mengde RAM på serveren på grunn av inode/dentry caching, noe som kan føre til dårlig ytelse da kjernen må håndtere datastrukturer på et system med 40 GB minne. Å sette denne parameteren til mer enn 100 har hjulpet mange brukere med å oppnå mer rettferdig hurtigbufring og forbedret kjernerespons.

vm.dirty_background_ratio og vm.dirty_ratio

Første parameter (vm.dirty_background_ratio) bestemmer prosentandelen av minnet med skitne sider, når det er nådd, er det nødvendig å starte bakgrunnsspyling av skitne sider til disk. Inntil denne prosentandelen er nådd, blir ikke sider tømt til disk. Og når tilbakestillingen starter, kjører den i bakgrunnen uten å avbryte løpende prosesser.

Andre parameter (vm.dirty_ratio) bestemmer prosentandelen av minnet som kan okkuperes av skitne sider før en tvungen blits begynner. Når denne terskelen er nådd, blir alle prosesser synkrone (blokkert) og får ikke fortsette å kjøre før I/O-operasjonen de ba om, faktisk er fullført og dataene er på disken. Med høy I/O-belastning forårsaker dette et problem fordi det ikke er databufring og alle prosesser som utfører I/O er blokkert og venter på I/O. Dette resulterer i et stort antall hengte prosesser, høy belastning, systemustabilitet og dårlig ytelse.

Redusering av verdiene til disse parameterne fører til at data skylles til disken oftere og ikke lagres i RAM. Dette kan hjelpe minnetunge systemer der det er normalt å skylle 45-90 GB sidebuffer til disken, noe som resulterer i enorm ventetid for front-end-applikasjoner, noe som reduserer den generelle responsen og interaktiviteten.

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

Sidebuffer er en hurtigbuffer som lagrer data fra filer og kjørbare programmer, det vil si at dette er sider med det faktiske innholdet i filer eller blokker enheter. Denne cachen brukes til å redusere antall diskavlesninger. En verdi på "1" betyr at cachen bruker 1% av RAM og det vil være flere lesninger fra disk enn fra RAM. Det er ikke nødvendig å endre denne innstillingen, men hvis du er paranoid med å kontrollere sidebufferen, kan du bruke den.

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

I/O-planleggeren er en kjernekomponent. Linux, som håndterer lese- og skrivekøer. Teoretisk sett er det bedre å bruke «noop» for en smart RAID-kontroller fordi Linux Planleggeren vet ingenting om diskens fysiske geometri, så det er mer effektivt å la kontrolleren, som har god kunnskap om diskens geometri, behandle forespørselen så raskt som mulig. Imidlertid ser det ut til at "fristen" forbedrer ytelsen. Mer informasjon om planleggere finnes i kjernens kildedokumentasjon. Linux: linux/Documentation/block/*osched.txt. Og jeg observerte også en økning i lesegjennomstrømning under blandede operasjoner (mange skrivinger).

"256" > /sys/block/sdc/queue/nr_requests

Antallet I/O-forespørsler i bufferen før de sendes til planleggeren. Noen kontrolleres interne køstørrelse (queue_depth) er større enn I/O-planleggerens nr_requests, så I/O-planleggeren har liten sjanse til å riktig prioritere og slå sammen forespørsler. For tidsfrister og CFQ-planleggere er det bedre når nr_requests er 2 ganger større enn kontrollerens interne kø. Sammenslåing og omorganisering av spørringer hjelper planleggeren til å være mer responsiv under stor belastning.

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

Sideklynge-parameteren kontrollerer antall sider som skrives til byttet på en gang. I eksemplet ovenfor er verdien satt til "16" for å matche RAID-stripestørrelsen på 64 KB. Dette gir ikke mening når swappiness = 0, men hvis du setter swappiness til 10 eller 20, vil bruk av denne verdien hjelpe deg når RAID-stripestørrelsen er 64 KB.

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

Standard blokkeringsenhetsinnstillinger for mange RAID-kontrollere resulterer ofte i forferdelig ytelse. Ved å legge til alternativet ovenfor konfigurerer du forhåndslesing for 4096*512 bytesektorer. I det minste for strømmeoperasjoner økes hastigheten ved å fylle diskbufferen på brikken via read-ahead i perioden kjernen bruker til å forberede I/O. Cachen kan inneholde data som vil bli forespurt ved neste lesing. For mye lesing fremover kan drepe tilfeldig I/O for store filer hvis den bruker opp potensielt nyttig disktid eller laster data utenfor hurtigbufferen.

Nedenfor er noen flere anbefalinger på filsystemnivå. Men de er ikke testet enda. Sørg for at filsystemet ditt kjenner stripestørrelsen og antall disker i matrisen. For eksempel at dette er en raid5-array med en stripestørrelse på 64K på seks disker (faktisk fem, fordi en disk brukes for paritet). Disse anbefalingene er basert på teoretiske forutsetninger og samlet fra ulike blogger/artikler av RAID-eksperter.

-> 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))

For større filer kan du vurdere å øke stripestørrelsene ovenfor.

FORSIKTIG Alt beskrevet ovenfor er ekstremt subjektivt for noen typer applikasjoner. Denne artikkelen garanterer ingen forbedringer uten først å teste de respektive applikasjonene av brukeren. Den skal bare brukes hvis det er behov for å forbedre systemets generelle reaksjonsevne eller hvis den løser aktuelle problemer.