Oversættelsen af artiklen er udarbejdet forud for begyndelsen af kurset .
Der opstår ind im mellem spørgsmål om Glusters anbefalinger til kerneindstillinger, og om der er behov for dem.
Sådanne behov opstår sjældent. I de fleste belastninger fungerer kernen rigtig godt. Der er dog en bagside. Historisk set har Linux-kernen en tendens til at forbruge meget hukommelse, hvis den får mulighed for det, herunder til caching som den primære metode til at øge ydeevnen.
I de fleste tilfælde fungerer det fremragende, men ved stor belastning kan det føre til problemer.
Vi har stor erfaring med systemer, der forbruger meget hukommelse, såsom CAD, EDA og lignende, som begyndte at bremse under høj belastning. Og nogle gange har vi stødt på problemer i Gluster. Ved nøje at overvåge hukommelsesforbruget og disktoppen i flere dage fik vi overbelastning, enorme iowait, kernel fejl (kernel oops), hængninger osv.
Denne artikel er resultatet af mange eksperimenter med konfigurationer udført i forskellige situationer. Takket være disse parametre er ikke kun responsiviteten generelt blevet forbedret, men stabiliteten i klyngen er også markant steget.
Når det kommer til hukommelsesindstillinger, skal man først se på den virtuelle hukommelsessubsystem (VM, virtual memory), som har et stort antal indstillinger, der kan forvirre dig.
vm.swappiness
Parameter vm.swappiness bestemmer, hvor meget kernen bruger swap sammenlignet med RAM. I kildekoden er det også defineret som "tendency to steal mapped memory". Høj værdi af swappiness betyder, at kernen vil være mere tilbøjelig til at udlade mappede sider. Lav værdi af swappiness betyder det modsatte: kernen vil udlade færre sider fra hukommelsen. Med andre ord, jo højere værdi, vm.swappiness, jo mere vil systemet bruge swap.
Høj brug af swapping er uønsket, da enorme datablokke indlæses og udlæses i hukommelsen. Mange hævder, at værdien for swappiness skal være høj, men efter min erfaring fører en indstilling på "0" til bedre ydeevne.
Du kan læse mere her —
Men igen, disse indstillinger bør anvendes med forsigtighed og kun efter test af den specifikke applikation. For højtydende streaming-applikationer bør denne parameter indstilles til "0". Når værdien ændres til "0", forbedres systemets reaktionshastighed.
vm.vfs_cache_pressure
Denne parameter styrer den hukommelse, som kernen bruger til at cache katalogobjekter og indeksdekskriptorer (dentry og inode).
Med en standardværdi på 100 vil kernen forsøge at frigive dentry- og inode-cachen "retfærdigt" i forhold til pagecache og swapcache. At reducere vfs_cache_pressure får kernen til at gemme dentry- og inode-cachene. Når værdien er "0", vil kernen aldrig rense dentry- og inode-cachen på grund af hukommelsespres, hvilket let kan føre til en out-of-memory-fejl. At øge vfs_cache_pressure til over 100 giver kernen prioritet for at tømme dentry og inode.
Når man bruger GlusterFS, kan mange brugere med store datamængder og mange små filer nemt bruge betydelige mængder RAM på serveren på grund af caching af inode/dentry, hvilket kan føre til nedsat ydeevne, da kernen skal håndtere datostrukturer i et system med 40 GB hukommelse. At sætte denne parameter til over 100 har hjulpet mange brugere med at opnå mere retfærdig caching og forbedre kernen's reaktionshastighed.
vm.dirty_background_ratio og vm.dirty_ratio
Den første parameter (vm.dirty_background_ratio) bestemmer procentdelen af hukommelse med beskidte sider, ved hvilken man skal begynde den baggrundsbaserede rensning af beskidte sider til disken. Så længe denne procentsats ikke er nået, renses siderne ikke til disken. Og når rensningen begynder, sker det i baggrunden uden at forstyrre de kørende processer.
Den anden parameter (vm.dirty_ratio) definerer den procentdel af hukommelsen, der kan optages af beskidte sider, før der påbegyndes et tvunget flash-reset. Når denne grænse nås, bliver alle processer synkrone (blokeres), og de får ikke lov til at fortsætte, indtil den anmodede I/O-operation rent faktisk er afsluttet, og dataene er på disken. Ved høj-belastet I/O medfører dette problemer, da datacaching mangler, og alle processer, der udfører I/O, blokeres i forventning om I/O. Dette fører til mange hængende processer, høj belastning, ustabil systemdrift og dårlig ydeevne.
At reducere værdierne for disse parametre medfører, at data oftere bliver skrevet til disken og ikke gemmes i RAM. Dette kan være nyttigt for systemer med meget hukommelse, hvor det er normalt at skrive en cache af sider på 45–90 GB til disken, hvilket fører til enorme ventetider for frontend-applikationer, der mindsker den samlede respons og interaktivitet.
«1» > /proc/sys/vm/pagecache
Sidedatabase (page cache) er en cache, hvor data fra filer og eksekverbare programmer opbevares, dvs. sider med det faktiske indhold af filer eller blokkerede enheder. Denne cache bruges til at reducere antallet af læsninger fra disken. Værdien «1» betyder, at 1% af RAM bruges til cachen, og der vil være flere læseoperationer fra disken end fra RAM. Det er ikke nødvendigt at ændre denne parameter, men hvis du er paranoid omkring kontrol af sidescachen, kan du bruge den.
«deadline» > /sys/block/sdc/queue/scheduler
I/O-planlæggeren (I/O scheduler) er en komponent i Linux-kernen, der håndterer køer af læse- og skriveanmodninger. Teoretisk set er det bedre at bruge «noop» for en intelligent RAID-controller, fordi Linux ikke ved noget om den fysiske geometri af disken; derfor er det mere effektivt at lade controlleren, der kender diskens geometri, håndtere anmodningen så hurtigt som muligt. Men det ser ud til, at «deadline» forbedrer ydeevnen. Du kan læse mere om planlæggere i dokumentationen til Linux-kildekoden: linux/Documentation/block/*osched.txt. Og jeg har også observeret en stigning i læsehastigheden under blandede operationer (mange skriveoperationer).
«256» > /sys/block/sdc/queue/nr_requests
Antallet af input-output anmodninger i bufferen, før de sendes til planlæggeren. Størrelsen på den interne kø for nogle controllere (queue_depth) er større end nr_requests for input-output planlæggeren, hvilket betyder, at planlæggeren har lidt chance for korrekt at prioritere og udføre sammenlægning af anmodninger. For deadline- og CFQ-planlæggere er det bedst, når nr_requests er dobbelt så stort som den interne kø for controlleren. Sammenlægning og omorganisering af anmodninger hjælper planlæggeren med at være mere responsiv under høj belastning.
echo «16» > /proc/sys/vm/page-cluster
Parameteren page-cluster styrer antallet af sider, der skrives til swap ad gangen. I eksemplet ovenfor er værdien indstillet til «16» i henhold til stripe-størrelsen (stripe size) i RAID på 64 KB. Dette giver ikke mening ved swappiness = 0, men hvis du har indstillet swappiness til 10 eller 20, vil brugen af denne værdi være til hjælp, når stripe-størrelsen i RAID er 64 KB.
blockdev —setra 4096 /dev/<devname> (-sdb, hdc eller dev_mapper)
Standardindstillingerne for blok-enheder for mange RAID-controllere resulterer ofte i forfærdelig ydeevne. Ved at tilføje ovenstående mulighed indstilles forudsigende læsning til 4096 * 512-byte sektioner. Mindst for stream operationer øges hastigheden ved at fylde den indbyggede diskcache med forudsigende læsning i den periode, der bruges af kernen til at forberede input-output. Data, der vil blive anmodet om ved næste læsning, kan gemmes i cachen. Forudsigende læsning, der er for stor, kan dræbe tilfældig input-output for store filer, hvis den bruger potentielt nyttig disktid eller indlæser data uden for cachen.
Her er nogle yderligere anbefalinger på filsystemniveau. Men de er endnu ikke testet. Sørg for, at dit filsystem kender stripe-størrelsen og antallet af diske i arrayet. For eksempel, at det er et raid5 array med stripe-størrelse på 64K bestående af seks diske (faktisk fem, fordi en disk bruges til paritet). Disse anbefalinger er baseret på teoretiske antagelser og er indsamlet fra forskellige blogs/artikler fra RAID-eksperter.
-> ext4 fs, 5 diske, 64K stripe, enheder i 4K blokke
mkfs -text4 -E stride=$((64/4))
-> xfs, 5 diske, 64K stripe, enheder i 512-byte sektioner
mkfs -txfs -d sunit=$((64*2)) -d swidth=$((5*64*2))For large files, consider increasing the specified strip sizes above.
ADVISORY! Everything described above is highly subjective for some types of applications. This article does not guarantee any improvements without prior testing of the relevant applications by the user. It should only be applied when necessary to improve overall system responsiveness or if it addresses current issues.
Additional materials:
Læs mere
Kilde: habr.com
