🥇Konfiguration af Linux-kernen til GlusterFS

Oversættelsen af artiklen blev udarbejdet på tærsklen til kursets start "Linux-administrator. Professionel".

Nu og da opstår der spørgsmål om Glusters anbefalinger vedrørende kernejustering og om det er nødvendigt.

Et sådant behov opstår sjældent. Under de fleste belastninger præsterer kernen rigtig godt. Der er dog en ulempe. Historisk set har Linux-kernen med glæde brugt en masse hukommelse, hvis den har fået muligheden, herunder til caching som en primær måde at forbedre ydeevnen på.

I de fleste tilfælde fungerer det fint, men under tung belastning kan det give problemer.

Vi har omfattende erfaring med hukommelsestunge systemer som CAD, EDA og lignende, der ville begynde at blive langsommere under høj belastning. Og nogle gange stødte vi på problemer i Gluster. Efter omhyggeligt at have overvåget hukommelsesforbruget og diskens ventetid i mere end én dag, fik vi dem overbelastede, enorm iowait, kernel ups, frysninger osv.

Denne artikel er resultatet af mange parameterjusteringseksperimenter udført i forskellige situationer. Takket være disse parametre er ikke kun den samlede responsivitet forbedret, men klyngedriften er også blevet betydeligt stabiliseret.

Når det kommer til at konfigurere hukommelse, er det første, man skal se på, det virtuelle hukommelses- (VM) undersystem, som har et stort antal muligheder, der kan være forvirrende.

vm.bytte

Parameter vm.swappiness bestemmer, hvor meget kernen bruger swap sammenlignet med RAM. I kildekoden er det også defineret som "tendens til at stjæle mapped memory". En høj swappiness-værdi betyder, at kernen vil være mere tilbøjelig til at udskifte mappede sider. En lav swappiness-værdi betyder det modsatte: kernen vil udskifte færre sider fra hukommelsen. Med andre ord, jo højere værdien er vm.swappiness, jo mere vil systemet bruge swap.

Stor brug af swaps er uønsket, fordi store datablokke indlæses og aflæses i RAM. Mange argumenterer for, at swapiness bør sættes højt, men efter min erfaring resulterer det i bedre ydeevne at sætte den til 0.

Du kan læse mere her - lwn.net/Artikler/100978

Men igen, disse indstillinger bør bruges med forsigtighed og kun efter test af den specifikke applikation. For streamingapplikationer med høj belastning skal denne parameter indstilles til "0". Ændring til "0" forbedrer systemets responstid.

vm.vfs_cache_pressure

Denne parameter styrer den hukommelse, der forbruges af kernen til cachelagring af mappeobjekter og inoder.

Med standardværdien 100 vil kernen forsøge at frigøre dentry- og inode-cacher "rimeligvis" i forhold til pagecache og swapcache. Reduktion af vfs_cache_pressure får kernen til at bevare dentry- og inode-caches. Når værdien er "0", vil kernen aldrig tømme dentry- og inode-cachen på grund af hukommelsestryk, og dette kan nemt føre til en fejl med manglende hukommelse. Hvis vfs_cache_pressure øges til over 100, prioriteres aflæsning af dentries og inodes af kernen.

Når man bruger GlusterFS, kan mange brugere med store mængder data og mange små filer nemt forbruge en betydelig mængde RAM på serveren på grund af inode/dentry caching, hvilket kan føre til forringelse af ydeevnen, da kernen skal behandle datastrukturer på et system med 40 GB hukommelse. At indstille denne parameter til mere end 100 har hjulpet mange brugere med at opnå en mere retfærdig caching og forbedret kernelresponsivitet.

vm.dirty_background_ratio og vm.dirty_ratio

Første parameter (vm.dirty_background_ratio) definerer procentdelen af hukommelse med snavsede sider, hvorefter det er nødvendigt at starte baggrundsrydning af snavsede sider til disken. Indtil denne procentdel er nået, flyttes siderne ikke til disken. Og når nulstillingen begynder, udføres den i baggrunden uden at afbryde kørende processer.

Den anden parameter (vm.dirty_ratio) bestemmer den procentdel af hukommelsen, der kan være optaget af snavsede sider, før en tvungen flash forekommer. Når denne tærskel er nået, bliver alle processer synkrone (blokerede) og må ikke fortsætte med at køre, før den I/O-handling, de anmodede om, faktisk er fuldført, og dataene er på disken. Under tung I/O-belastning forårsager dette et problem, fordi der ikke er nogen data-caching, og alle processer, der udfører I/O, er blokeret, mens de venter på I/O. Dette resulterer i et stort antal frosne processer, høj belastning, ustabil systemdrift og dårlig ydeevne.

Hvis værdierne af disse parametre reduceres, overføres data oftere til disken og ikke gemmes i RAM. Dette kan hjælpe hukommelsesintensive systemer, der normalt gemmer 45-90 GB sidecache på disken, hvilket resulterer i enorm latenstid for frontend-applikationer, hvilket reducerer den samlede responstid og interaktivitet.

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

En sidecache er en cache, der lagrer data fra filer og eksekverbare programmer, det vil sige sider med det faktiske indhold af filer eller blokenheder. Denne cache bruges til at reducere antallet af disklæsninger. En værdi på "1" betyder, at 1% af RAM'en bruges til cache, og at der vil være flere læseoperationer fra disken end fra RAM. Det er ikke nødvendigt at ændre denne indstilling, men hvis du er paranoid omkring at kontrollere sidens cache, kan du bruge den.

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

I/O-scheduleren er en komponent i Linux-kernen, der håndterer læse- og skrivekøer. I teorien er det bedre for en smart RAID-controller at bruge "noop", fordi Linux ikke kender noget til diskens fysiske geometri, så det er mere effektivt at lade controlleren, som kender diskens geometri godt, behandle anmodningen så hurtigt som muligt. Men det ser ud til, at "deadline" forbedrer præstationen. Du kan finde flere oplysninger om planlæggere i dokumentationen til Linux-kernens kildekode: linux/Documentation/block/*osched.txt. Og jeg så også en stigning i læsehastigheden under blandede operationer (mange skrivninger).

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

Antallet af I/O-anmodninger i bufferen, før de sendes til scheduleren. Nogle controlleres interne køstørrelse (queue_depth) er større end I/O-schedulerens nr_requests, så I/O-scheduleren har ringe chance for at prioritere og flette anmodninger korrekt. For deadline- og CFQ-planlæggere er det bedre, når nr_requests er 2 gange controllerens interne kø. Kombinering og omarrangering af forespørgsler hjælper planlæggeren med at være mere responsiv under tung belastning.

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

Parameteren page-cluster styrer antallet af sider, der skrives til udskiftning på én gang. I eksemplet ovenfor er værdien indstillet til "16" for at matche RAID-stripestørrelsen på 64 KB. Dette giver ikke mening med swappiness=0, men hvis du sætter swappiness til 10 eller 20, vil det hjælpe dig at bruge denne værdi, når RAID-stripestørrelsen er 64KB.

blokdev --setra 4096 /dev/`<`udviklernavn`>` (-sdb, hdc eller dev_mapper)

Standardindstillingerne for blokeringsenheder for mange RAID-controllere resulterer ofte i forfærdelig ydeevne. Tilføjelse af ovenstående indstilling konfigurerer read-ahead for sektorer på 4096*512 byte. I det mindste for streamingoperationer øges hastigheden ved at fylde den on-disk cache med read-ahead i den periode, kernen bruger til at forberede I/O. Cachen kan gemme data, der vil blive anmodet om næste gang den læses. For meget read-ahead kan ødelægge tilfældig I/O på store filer, hvis det bruger potentielt nyttig disktid eller indlæser data uden for cachen.

Nedenfor er nogle flere anbefalinger på filsystemniveau. Men de er ikke blevet testet endnu. Sørg for, at dit filsystem kender stripe-størrelsen og antallet af diske i arrayet. For eksempel er det et RAID5-array med en 64K stripe-størrelse på seks diske (faktisk fem, fordi én disk bruges til paritet). Disse anbefalinger er baseret på teoretiske antagelser og indsamlet fra forskellige blogs/artikler af 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 overveje at øge stribestørrelserne ovenfor.

ADVARSEL! Alt beskrevet ovenfor er ekstremt subjektivt for nogle typer applikationer. Denne artikel garanterer ikke nogen forbedringer uden forudgående test af de respektive applikationer af brugeren. Det bør kun anvendes, hvis der er behov for at forbedre systemets samlede responsivitet, eller hvis det løser aktuelle problemer.