Översättningen av artikeln förbereddes strax före kursstart .
Med jämna mellanrum, här och där, dyker det upp frågor om Glusters rekommendationer angående kernel tuning och om det finns behov av detta.
Ett sådant behov uppstår sällan. På de flesta arbetsbelastningar fungerar kärnan mycket bra. Även om det finns en baksida. Historiskt sett har Linux-kärnan varit villig att förbruka mycket minne om möjligheten ges, inklusive cachning som det främsta sättet att förbättra prestandan.
I de flesta fall fungerar detta bra, men vid hög belastning kan det leda till problem.
Vi har stor erfarenhet av minnesintensiva system som CAD, EDA och liknande, som började sakta ner under hård belastning. Och ibland stötte vi på problem i Gluster. Efter att noggrant observerat minnesanvändningen och disklatensen i många dagar, fick vi deras överbelastning, enorma iowait, kärnfel (kernel oops), fryser, etc.
Den här artikeln är resultatet av många trimningsexperiment utförda i olika situationer. Tack vare dessa parametrar har inte bara den övergripande lyhördheten förbättrats, utan klustret har också stabiliserats avsevärt.
När det kommer till minnesinställning är det första att titta på det virtuella minnesundersystemet (VM, virtuellt minne), som har ett stort antal alternativ som kan förvirra dig.
vm.byte
Parameter vm.swappiness bestämmer hur mycket kärnan använder swap (swap, paging) jämfört med RAM. Det definieras också i källkoden som "tendens att stjäla mappat minne". En hög swappiness betyder att kärnan kommer att vara mer benägen att byta mappade sidor. Ett lågt swappiness-värde betyder motsatsen: kärnan kommer att söka mindre från minnet. Med andra ord, ju högre värde vm.swappiness, desto mer kommer systemet att använda swap.
En stor användning av swapping är oönskad, eftersom stora datablock laddas och laddas ur i RAM. Många hävdar att swapinessvärdet borde vara stort, men enligt min erfarenhet leder det till bättre prestanda att sätta det på "0".
Du kan läsa mer här -
Men återigen, dessa inställningar bör tillämpas med försiktighet och först efter att ha testat en viss applikation. För högbelastade streamingapplikationer bör denna parameter ställas in på "0". När den ändras till "0" förbättras systemets lyhördhet.
vm.vfs_cache_pressure
Den här inställningen styr minnet som konsumeras av kärnan för cachelagring av kataloger och inodobjekt (dentry och inode).
Med ett standardvärde på 100 kommer kärnan att försöka frigöra dentry- och inodcachen på en "rättvis" basis till pagecache och swapcache. Minskad vfs_cache_pressure gör att kärnan behåller dentry och inodcacher. När värdet är "0" kommer kärnan aldrig att spola tandborst och inodcache på grund av minnestryck, och detta kan lätt leda till ett fel i minnet. Att öka vfs_cache_pressure över 100 gör att kärnan prioriterar tandborst och inodspolning.
När man använder GlusterFS kan många användare med stora mängder data och många små filer lätt använda en betydande mängd RAM-minne på servern på grund av inod/dentry-cache, vilket kan leda till prestandaförsämring då kärnan måste bearbeta datastrukturer på ett system med 40 GB minne. Att ställa in detta värde över 100 har hjälpt många användare att uppnå rättvisare cachelagring och förbättrad känslighet för kärnan.
vm.dirty_background_ratio och vm.dirty_ratio
Första parametern (vm.dirty_background_ratio) bestämmer procentandelen minne med smutsiga sidor, efter att ha nått det är det nödvändigt att börja spola smutsiga sidor i bakgrunden till disken. Förrän denna procentandel har uppnåtts spolas inga sidor till disken. Och när en återställning startar körs den i bakgrunden utan att avbryta pågående processer.
Den andra parametern (vm.dirty_ratio) definierar den procentandel av minnet som kan upptas av smutsiga sidor innan tvångsblixt börjar. När denna tröskel har nåtts blir alla processer synkrona (blockerade) och tillåts inte fortsätta förrän den I/O de begärde faktiskt är klar och data finns på disken. Med tunga I/O orsakar detta problem eftersom det inte finns någon datacachning och alla processer som gör I/O blockeras i väntan på I/O. Detta leder till ett stort antal upphängda processer, hög belastning, systeminstabilitet och dålig prestanda.
Att minska dessa inställningar gör att data spolas till disken oftare och inte lagras i RAM. Detta kan hjälpa minnestunga system där det är normalt att spola 45-90 GB sidcacheminne till disken, vilket resulterar i enorm latens för front-end-applikationer, vilket minskar den övergripande responsen och interaktiviteten.
"1"> /proc/sys/vm/pagecache
En sidcache är en cache som lagrar data från filer och körbara program, det vill säga dessa är sidor med det faktiska innehållet i filer eller blockenheter. Denna cache används för att minska antalet diskläsningar. Ett värde på "1" betyder att 1% av RAM-minnet används för cachen och det blir fler läsningar från disk än från RAM. Det är inte nödvändigt att ändra den här inställningen, men om du är paranoid med att kontrollera sidcachen kan du använda den.
"deadline" > /sys/block/sdc/queue/scheduler
I/O-schemaläggaren är en Linux-kärnkomponent som hanterar läs- och skrivköer. I teorin är det bättre att använda "noop" för en smart RAID-kontroller, eftersom Linux inte vet någonting om den fysiska geometrin på disken, så det är mer effektivt att låta kontrollern, som kan diskens geometri väl, behandla begäran så snabbt som möjlig. Men det ser ut som att "deadline" förbättrar prestandan. Du kan läsa mer om schemaläggare i dokumentationen för Linux-kärnans källkod: linux/Documentation/block/*osched.txt. Och jag har också sett en ökning av läskapaciteten vid blandade operationer (många skriver).
"256" > /sys/block/sdc/queue/nr_requests
Antalet I/O-förfrågningar i bufferten innan de skickas till schemaläggaren. Vissa kontrollers interna köstorlek (queue_depth) är större än I/O-schemaläggarens nr_requests, så I/O-schemaläggaren har liten chans att korrekt prioritera och slå samman förfrågningar. För deadline- och CFQ-schemaläggare är det bättre när nr_requests är 2 gånger styrenhetens interna kö. Sammanfogning och omordningsförfrågningar hjälper schemaläggaren att vara mer lyhörd under tung belastning.
echo "16" > /proc/sys/vm/page-cluster
Sidklusterparametern styr antalet sidor som skrivs till bytet på en gång. I exemplet ovan är värdet satt till "16" enligt RAID-randstorleken på 64 KB. Det är inte vettigt med swappiness = 0, men om du ställer in swappiness till 10 eller 20 så kommer användningen av detta värde att hjälpa dig när RAID-randstorleken är 64K.
blockdev --setra 4096 /dev/<devname> (-sdb, hdc eller dev_mapper)
Standardinställningarna för blockeringsenhet för många RAID-kontroller resulterar ofta i fruktansvärda prestanda. Om du lägger till alternativet ovan ställs in läs framåt för 4096 * 512-byte sektorer. Åtminstone, för strömmande operationer, ökas hastigheten genom att fylla diskcachen på chipet med read-ahead under den period som används av kärnan för att förbereda I/O. Cachen kan innehålla data som kommer att begäras vid nästa läsning. För mycket förhämtning kan döda slumpmässig I/O för stora filer om den använder upp potentiellt användbar disktid eller laddar data utanför cachen.
Nedan finns några fler rekommendationer på filsystemnivå. Men de har inte testats än. Se till att ditt filsystem känner till storleken på remsan och antalet diskar i arrayen. Till exempel att detta är en 5K stripe raid64-array med sex diskar (faktiskt fem, eftersom en disk används för paritet). Dessa rekommendationer är baserade på teoretiska antaganden och sammanställda från olika bloggar/artiklar av RAID-experter.
-> 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))För stora filer, överväg att öka randstorlekarna som anges ovan.
FÖRSIKTIGHET Allt som beskrivs ovan är mycket subjektivt för vissa typer av applikationer. Den här artikeln garanterar inga förbättringar utan föregående användartestning av relaterade applikationer. Det bör endast användas om det är nödvändigt för att förbättra systemets övergripande lyhördhet, eller om det löser aktuella problem.
Ytterligare material:
Läs mer
Källa: will.com