🥇Kärninstallation Linux för GlusterFS

Översättningen av artikeln förbereddes strax före kursstart Administratör LinuxProfessionell».

Då och då uppstår frågor om Glusters rekommendationer angående kärnjustering och om det är nödvändigt.

Detta behov uppstår sällan. Under de flesta arbetsbelastningar presterar kärnan mycket bra. Det finns dock en nackdel. Historiskt sett har kärnan Linux förbrukar villigt mycket minne om den ges möjlighet, inklusive för cachning som det främsta sättet att förbättra prestanda.

I de flesta fall fungerar detta bra, men under hög belastning kan det orsaka problem.

Vi har lång erfarenhet av minnesintensiva system som CAD, EDA och liknande som skulle börja sakta ner under hög belastning. Och ibland stötte vi på problem i Gluster. Efter att noggrant ha övervakat minnesanvändningen och diskens väntetid i mer än en dag, fick vi dem överbelastade, enorma iowait, kernel oops, fryser, etc.

Den här artikeln är resultatet av många parameterinställningsexperiment utförda i olika situationer. Tack vare dessa parametrar har inte bara den övergripande responsen förbättrats, utan klusterdriften har också stabiliserats avsevärt.

När det kommer till att konfigurera minne är det första att titta på delsystemet virtuellt minne (VM), som har ett stort antal alternativ som kan vara förvirrande.

vm.byte

Parameter vm.swappiness bestämmer hur mycket kärnan använder swap jämfört med RAM. I källkoden definieras det också som "tendens att stjäla mappat minne". Ett högt swappiness-värde betyder att kärnan är mer benägen att byta ut mappade sidor. Ett lågt swappiness-värde betyder motsatsen: kärnan kommer att byta ut färre sidor från minnet. Med andra ord, ju högre värde vm.swappiness, desto mer kommer systemet att använda swap.

Stor swap-användning är oönskad eftersom enorma datablock laddas och laddas ur i RAM. Många människor hävdar att swapiness bör sättas högt, men min erfarenhet ger bättre prestanda att sätta den till 0.

Du kan läsa mer här - lwn.net/Articles/100978

Men återigen, dessa inställningar bör användas med försiktighet och endast efter att ha testat den specifika applikationen. För streamingapplikationer med hög belastning bör denna parameter ställas in på "0". Att ändra till "0" förbättrar systemets lyhördhet.

vm.vfs_cache_pressure

Den här parametern styr minnet som konsumeras av kärnan för cachelagring av katalogobjekt och inoder.

Med standardvärdet 100 kommer kärnan att försöka frigöra dentry- och inodcacher "ganska" med avseende på pagecache och swapcache. Att reducera vfs_cache_pressure gör att kärnan bevarar 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 urladdning av tandborst och inoder.

När man använder GlusterFS kan många användare med stora mängder data och många små filer lätt konsumera en betydande mängd RAM på servern på grund av inode/dentry-cache, vilket kan leda till prestandaförsämring då kärnan måste bearbeta datastrukturer på ett system med 40GB minne. Att ställa in den här parametern till mer än 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) definierar procentandelen minne med smutsiga sidor, när man når vilken det är nödvändigt att starta bakgrundsspolning av smutsiga sidor till disken. Förrän denna procentandel har uppnåtts spolas inte sidor till disken. Och när återställningen börjar utförs den i bakgrunden, utan att avbryta pågående processer.

Den andra parametern (vm.dirty_ratio) bestämmer procentandelen av minnet som kan upptas av smutsiga sidor innan en påtvingad blixt inträffar. När detta tröskelvärde nås blir alla processer synkrona (blockerade) och tillåts inte fortsätta köras förrän den I/O-operation de begärde faktiskt är slutförd och data finns på disken. Under hög I/O-belastning orsakar detta ett problem eftersom det inte finns någon datacachning och alla processer som utför I/O blockeras i väntan på I/O. Detta resulterar i ett stort antal frusna processer, hög belastning, instabil systemdrift och dålig prestanda.

Att minska värdena för dessa parametrar resulterar i att data spolas till disken oftare och inte lagras i RAM. Detta kan hjälpa minnesintensiva system som normalt spolar 45-90 GB sidcache 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 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 cache och det kommer att bli fler läsoperationer 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 kärnkomponent. Linux, som hanterar läs- och skrivköer. Teoretiskt sett är det bättre att använda "noop" för en smart RAID-kontroller eftersom Linux Schemaläggaren vet ingenting om diskens fysiska geometri, så det är mer effektivt att låta styrenheten, som har god kunskap om diskens geometri, bearbeta begäran så snabbt som möjligt. "Deadline" verkar dock förbättra prestandan. Mer information om schemaläggare finns i kärnans källkodsdokumentation. Linux: linux/Documentation/block/*osched.txt. Och jag såg också en ökning av läskapaciteten under blandade operationer (många skrivningar).

"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 den interna kön för regulatorn. Att kombinera och ordna om frågor hjälper planeraren att vara mer lyhörd under tung belastning.

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

Parametern page-cluster styr antalet sidor som skrivs för att byta på en gång. I exemplet ovan är värdet satt till "16" för att matcha RAID-randstorleken på 64 KB. Det här är inte vettigt med swappiness=0, men om du ställer in swappiness till 10 eller 20, kommer det här värdet att hjälpa dig när RAID-randstorleken är 64KB.

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. Genom att lägga till ovanstående alternativ konfigureras läs framåt för 4096*512-byte sektorer. Åtminstone för streamingoperationer ökas hastigheten genom att fylla på diskcachen med read-ahead under den period kärnan använder för att förbereda I/O. Cachen kan lagra data som kommer att begäras nästa gång den läses. För mycket läsning framåt kan döda slumpmässig I/O på stora filer om den använder potentiellt användbar disktid eller laddar data utanför cachen.

Nedan finns några fler rekommendationer på filsystemsnivå. Men de har inte testats än. Se till att ditt filsystem känner till randstorleken och antalet diskar i arrayen. Till exempel är det en raid5-array med en 64K randstorlek på sex diskar (faktiskt fem, eftersom en disk används för paritet). Dessa rekommendationer är baserade på teoretiska antaganden och samlade 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 större filer kan du överväga att öka randstorlekarna ovan.

FÖRSIKTIGHET Allt som beskrivs ovan är extremt subjektivt för vissa typer av applikationer. Denna artikel garanterar inga förbättringar utan föregående testning av respektive applikation av användaren. Det bör endast användas om det finns ett behov av att förbättra systemets övergripande lyhördhet eller om det löser aktuella problem.