Oversættelsen af artiklen blev udarbejdet på tærsklen til kursets start .
Fra tid til anden opstår der her og der spørgsmål om Glusters anbefalinger vedrørende kernetilpasning og om det er nødvendigt.
Dette behov opstår sjældent. Kernen klarer sig meget godt under de fleste arbejdsbelastninger. Selvom der er en ulempe. Historisk set bruger Linux-kernen let meget hukommelse, hvis den får muligheden, inklusive caching som et primært middel til at forbedre ydeevnen.
I de fleste tilfælde fungerer dette glimrende, men under hård belastning kan det give problemer.
Vi har stor erfaring med at arbejde med systemer, der bruger meget hukommelse, såsom CAD, EDA og lignende, som begyndte at bremse under høj belastning. Og nogle gange stødte vi på problemer i Gluster. Efter omhyggeligt at have overvåget den brugte hukommelse og diskens ventetid i mere end én dag, fik vi diskoverbelastning, enorm iowait, kernefejl (kernel ups), fryser osv.
Denne artikel er resultatet af mange parameterjusteringseksperimenter udført i forskellige situationer. Takket være disse parametre blev ikke kun reaktionsevnen generelt forbedret, men også driften af klyngen blev betydeligt stabiliseret.
Når det kommer til konfiguration af hukommelse, er det første sted at kigge efter det virtuelle hukommelses-subsystem (VM), som har et stort antal muligheder, der kan forvirre dig.
vm.bytte
Parameter vm.swappiness bestemmer, hvor meget kernen bruger swap sammenlignet med RAM. Det er også defineret i kildekoden som "tendens til at stjæle kortlagt hukommelse." En høj swappiness-værdi betyder, at kernen vil være mere tilbøjelig til at bytte tilknyttede sider. En lav swappiness-værdi betyder det modsatte: kernen vil bytte sider ud af hukommelsen mindre. Med andre ord, jo højere værdi vm.swappiness, jo mere vil systemet bruge swap.
Omfattende brug af swapping er uønsket, da store datablokke indlæses og aflæses i RAM. Mange mennesker argumenterer for, at swapiness-værdien bør være høj, men efter min erfaring giver det bedre ydeevne at sætte den til "0".
Du kan læse mere her -
Men igen, disse indstillinger skal bruges med forsigtighed og kun efter test af den specifikke applikation. For højt indlæste streamingapplikationer skal denne parameter indstilles til "0". Når den ændres til "0", forbedres systemets reaktionsevne.
vm.vfs_cache_pressure
Denne indstilling styrer den hukommelse, der forbruges af kernen til cachelagring af mappeobjekter og inoder (dentry og inode).
Med standardværdien på 100 vil kernen forsøge at frigøre dentry- og inode-cachene på en rimelig måde til pagecachen og swapcachen. Formindskelse af vfs_cache_pressure får kernen til at bevare dentry og inode caches. Når værdien er "0", vil kernen aldrig skylle dentry og inode-cachen på grund af hukommelsestryk, og dette kan nemt føre til en hukommelsesfejl. Forøgelse af vfs_cache_pressure over 100 får kernen til at prioritere dentry og inode pageouts.
Ved brug af GlusterFS kan mange brugere med store mængder data og mange små filer nemt bruge en betydelig mængde RAM på serveren på grund af inode/dentry caching, hvilket kan føre til dårlig ydeevne, da kernen skal håndtere datastrukturer på et system med 40 GB hukommelse. Indstilling af denne parameter til mere end 100 har hjulpet mange brugere med at opnå mere retfærdig cachelagring og forbedret kernerespons.
vm.dirty_background_ratio og vm.dirty_ratio
Første parameter (vm.dirty_background_ratio) bestemmer procentdelen af hukommelsen med beskidte sider, når det er nået, er det nødvendigt at starte baggrundsskylning af beskidte sider til disk. Indtil denne procentdel er nået, tømmes siderne ikke til disken. Og når nulstillingen starter, kører den i baggrunden uden at afbryde kørende processer.
Anden parameter (vm.dirty_ratio) bestemmer den procentdel af hukommelsen, der kan optages af beskidte sider, før en tvungen flash begynder. Når denne tærskel er nået, bliver alle processer synkrone (blokerede) og får ikke lov til at fortsætte med at køre, før den I/O-operation, de anmodede om, faktisk er fuldført, og dataene er på disken. Med høj I/O-belastning forårsager dette et problem, fordi der ikke er nogen datacache, og alle processer, der udfører I/O, er blokeret og venter på I/O. Dette resulterer i et stort antal ophængte processer, høj belastning, systemustabilitet og dårlig ydeevne.
Reduktion af værdierne af disse parametre får data til at blive skyllet til disken oftere og ikke gemt i RAM. Dette kan hjælpe hukommelsestunge systemer, hvor det er normalt at skylle 45-90 GB sidecache til disken, hvilket resulterer i enorm latens for front-end-applikationer, hvilket reducerer den samlede reaktionsevne og interaktivitet.
"1"> /proc/sys/vm/pagecache
Sidecache er en cache, der gemmer data fra filer og eksekverbare programmer, det vil sige, at disse er 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 cachen bruger 1% af RAM, og der vil være flere læsninger fra disk end fra RAM. Det er ikke nødvendigt at ændre denne indstilling, men hvis du er paranoid med at kontrollere sidecachen, kan du bruge den.
"deadline" > /sys/block/sdc/queue/scheduler
I/O-planlæggeren er en komponent i Linux-kernen, der håndterer læse- og skrivekøer. I teorien er det bedre at bruge "noop" til en smart RAID-controller, fordi Linux ikke ved noget om diskens fysiske geometri, så det er mere effektivt at lade controlleren, som kender diskens geometri godt, behandle anmodningen som hurtigst muligt. Men det ser ud til, at "deadline" forbedrer ydeevnen. Mere information om planlæggere kan findes i dokumentationen til Linux-kernens kildekode: linux/Documentation/block/*osched.txt. Og jeg observerede også en stigning i læsegennemstrømning under blandede operationer (masser af skrivninger).
"256"> /sys/block/sdc/queue/nr_requests
Antallet af I/O-anmodninger i bufferen, før de sendes til planlæggeren. Nogle controlleres interne køstørrelse (queue_depth) er større end I/O-planlæggerens nr_requests, så I/O-planlæggeren 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 større end controllerens interne kø. Sammenfletning og omarrangering af forespørgsler hjælper skemalæggeren med at være mere lydhør under hård belastning.
echo "16"> /proc/sys/vm/page-cluster
Side-klynge-parameteren styrer antallet af sider, der skrives til skiftet på én gang. I eksemplet ovenfor er værdien sat til "16" for at matche RAID-stribestørrelsen på 64 KB. Dette giver ikke mening, når swappiness = 0, men hvis du indstiller swappiness til 10 eller 20, vil brugen af denne værdi hjælpe dig, når RAID-stribestørrelsen er 64 KB.
blockdev --setra 4096 /dev/<devnavn> (-sdb, hdc eller dev_mapper)
Standard blokenhedsindstillingerne for mange RAID-controllere resulterer ofte i forfærdelig ydeevne. Tilføjelse af ovenstående indstilling konfigurerer fremadlæsning for 4096*512 bytesektorer. I det mindste for streaming-operationer øges hastigheden ved at fylde diskcachen på chip via read-ahead i den periode, kernen bruger til at forberede I/O. Cachen kan indeholde data, der vil blive anmodet om ved næste læsning. For meget read-ahead kan dræbe tilfældig I/O for store filer, hvis det bruger potentielt nyttig disktid eller indlæser data uden for cachen.
Nedenfor er et par flere anbefalinger på filsystemniveau. Men de er ikke testet endnu. Sørg for, at dit filsystem kender stribestørrelsen og antallet af diske i arrayet. For eksempel, at dette er et raid5-array med en stribestørrelse på 64K af seks diske (faktisk fem, fordi en 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 ovenstående stribestørrelser.
ADVARSEL! Alt beskrevet ovenfor er ekstremt subjektivt for nogle typer applikationer. Denne artikel garanterer ingen forbedringer uden først at have testet de respektive applikationer af brugeren. Det bør kun bruges, hvis der er behov for at forbedre systemets overordnede reaktionsevne, eller hvis det løser aktuelle problemer.
Yderligere materialer:
Læs mere
Kilde: www.habr.com