Oversettelsen av artikkelen ble utarbeidet like før kursstart .
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 veldig bra under de fleste arbeidsbelastninger. Selv om det er en ulempe. Historisk sett bruker Linux-kjernen lett mye minne hvis den får muligheten, inkludert for caching som et primært middel for å forbedre ytelsen.
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 -
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 komponent av Linux-kjernen som håndterer lese- og skrivekøer. I teorien 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 kjenner diskens geometri godt, behandle forespørselen som raskt som mulig. Men det ser ut til at «deadline» forbedrer ytelsen. Mer informasjon om planleggere finner du i dokumentasjonen for Linux-kjernens kildekode: 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.
Tilleggsmateriell:
Les mer
Kilde: www.habr.com