🥇Inställning av Linux-kärnan för GlusterFS

Översättningen av artikeln är framtagen inför kursstarten «Linux Administrator. Professionell».

Ibland dyker frågor upp här och där angående Glusters rekommendationer för kärninställningar och om det verkligen är nödvändigt.

Sådana behov uppstår sällan. I de flesta belastningar fungerar kärnan mycket bra. Men det finns även en annan sida. Historiskt sett är Linux-kärnan benägen att konsumera mycket minne om man ger den möjligheten, inklusive för caching som det primära sättet att öka prestanda.

I de flesta fall fungerar detta utmärkt, men vid hög belastning kan det leda till problem.

Vi har stor erfarenhet av system som använder mycket minne, som CAD, EDA och liknande, som började bromsa vid hög belastning. Och ibland har vi stött på problem med Gluster. Genom att noggrant övervaka minnesanvändning och diskens svarstider under flera dagar har vi fått dem att överbelastas, med enorma iowait, kärnfel (kernel oops), frysningar osv.

Denna artikel är resultatet av många experiment med inställning av parametrar utförda under olika förhållanden. Tack vare dessa parametrar har både responsiviteten förbättrats och klustrets stabilitet ökat avsevärt.

När det kommer till minnesinställningar är det först och främst viktigt att titta på det virtuella minnessystemet (VM, virtual memory), som har många alternativ som kan förvirra.

vm.swappiness

Parameter vm.swappiness bestämmer hur mycket kärnan använder swap (utbyte) jämfört med det fasta minnet. I källkoden definieras det också som «tendency to steal mapped memory» (tendens att stjäla kartlagt minne). Ett högt värde av swappiness betyder att kärnan kommer att ha en större benägenhet att avlasta kartlagda sidor. Ett lågt värde av swappiness innebär det motsatta: kärnan kommer att avlasta sidor mindre från minnet. Med andra ord, ju högre värde, vm.swappiness, desto mer kommer systemet att använda swap.

Ett stort användande av swap är oönskat, eftersom stora datamängder laddas in och ut ur RAM-minnet. Många hävdar att värdet för swappiness bör vara högt, men enligt min erfarenhet ger en inställning på «0» ökad prestanda.

Mer information kan läsas här — lwn.net/Articles/100978

Men återigen, dessa inställningar bör tillämpas med försiktighet och endast efter att ha testat den specifika applikationen. För högbelastade strömmande applikationer bör detta värde sättas till "0". När det ändras till "0" förbättras systemets respons.

vm.vfs_cache_pressure

Denna parameter kontrollerar minnet som används av kärnan för att cachea katalogobjekt och indexeringsbeskrivare (dentry och inode).

Med standardvärdet på 100 kommer kärnan att försöka frigöra dentry- och inode-cache rättvist i förhållande till pagecache och swapcache. Att minska vfs_cache_pressure resulterar i att kärnan behåller dentry- och inode-cachar. När värdet är "0" kommer kärnan aldrig att rensa dentry- och inode-cache på grund av minnesbrist, och detta kan lätt leda till en out-of-memory-fel. Att öka vfs_cache_pressure till mer än 100 ger kärnan prioritet för att frigöra dentry- och inode-cache.

När man använder GlusterFS kan många användare med stora datamängder och många små filer lätt använda en betydande mängd RAM på servern på grund av caching av inode/dentry, vilket kan leda till minskad prestanda, eftersom kärnan måste hantera datastrukturer i ett system med 40 GB minne. Att ställa in denna parameter till över 100 har hjälpt många användare att uppnå mer rättvis caching och förbättra kärnans respons.

vm.dirty_background_ratio och vm.dirty_ratio

Den första parametern (vm.dirty_background_ratio) definierar procentandelen av minnet med smutsiga sidor, efter att ha nått vilket man måste börja en bakgrundsskrivning av smutsiga sidor till disk. Så länge denna procentandel inte har nåtts skrivs sidor inte till disk. Och när skrivningen börjar sker den i bakgrunden utan att avbryta pågående processer.

Den andra parametern (vm.dirty_ratio) definierar procentandelen minne som kan användas av smutsiga sidor innan en tvingad skrivning (forced flash) börjar. När denna tröskel nås blir alla processer synkrona (blockeras), och de ges inget tillstånd att fortsätta förrän den begärda in- och utdataoperationen faktiskt har slutförts och data är på disken. Vid högbelastad in- och utdata skapar detta problem eftersom datacachning saknas, och alla processer som utför in- och utdata blockeras i väntan på in- och utdata. Detta leder till ett stort antal hängande processer, hög belastning, instabil drift av systemet och dålig prestanda.

Att sänka värdena för dessa parametrar gör att data oftare skrivs till disken och inte lagras i RAM. Detta kan hjälpa system med mycket minne, där det är normalt att skriva $45–90 GB sidcache till disken, vilket leder till enorma väntetider för frontend-applikationer och minskar den övergripande responsiviteten och interaktiviteten.

«1» > /proc/sys/vm/pagecache

Sidcache (page cache) är en cache där data från filer och körbara program lagras, det vill säga sidor med den faktiska innehållet från filer eller blockenheter. Denna cache används för att minska antalet läsningar från disken. Värdet «1» betyder att cachen använder 1% av RAM och antalet läsningar från disken kommer att vara fler än från RAM. Det är inte nödvändigt att ändra detta parameter, men om du är paranoid över kontrollen av sidcache, kan du använda den.

«deadline» > /sys/block/sdc/queue/scheduler

In- och utdata-schemaläggaren (I/O scheduler) är en komponent i Linux-kärnan som hanterar köer för läsning och skrivning. Teoretiskt sett är det bättre att använda «noop» för en smart RAID-kontroller, eftersom Linux inte vet något om diskens fysiska geometri, så det är mer effektivt att låta kontroller som väl känner till diskens geometri bearbeta begäran så snabbt som möjligt. Men det verkar som att «deadline» ökar prestandan. Mer information om schemaläggarna kan läsas i dokumentationen till Linux-kärnans källkod: linux/Documentation/block/*osched.txt. Och jag har också observerat en ökning av läshastigheten under blandade operationer (många skrivoperationer).

«256» > /sys/block/sdc/queue/nr_requests

Antalet in- och utdatafrågor i bufferten innan de överförs till schemaläggaren. Storleken på den interna kön för vissa kontroller (queue_depth) är större än nr_requests för in- och utdata-schemaläggaren, vilket gör att schemaläggaren har få chanser att korrekt prioritera och genomföra sammanfogning av förfrågningar. För deadline- och CFQ-schemaläggare är det bättre när nr_requests är dubbelt så stort som den interna kön för kontrollern. Sammanfogning och omstrukturering av förfrågningar hjälper schemaläggaren att vara mer responsiv under hög belastning.

echo «16» > /proc/sys/vm/page-cluster

Parametern page-cluster styr antalet sidor som skrivs till swap åt gången. I ovanstående exempel sätts värdet till "16" enligt storleken på stripe (stripe size) för RAID på 64 KB. Detta är meningslöst vid swappiness = 0, men om du har ställt in swappiness på 10 eller 20, kommer användning av detta värde hjälpa när storleken på RAID-stripe är 64 KB.

blockdev —setra 4096 /dev/`<`devname`>` (-sdb, hdc eller dev_mapper)

Standardinställningarna för blockenheter för många RAID-kontroller leder ofta till usel prestanda. Genom att lägga till den ovanstående parametern ställer du in förhandsläsning för 4096 * 512-byte sektorer. Åtminstone för strömmande operationer ökar hastigheten genom att fylla det inbyggda diskkaket via förhandsläsning under den tid som kärnan använder för att förbereda in- och utdata. Data som kommer att begäras vid nästa läsning kan placeras i cache. För mycket förhandsläsning kan förstöra slumpmässig in- och utdata för stora filer om det utnyttjar potentiellt nyttig disk tid eller laddar data utanför cachen.

Nedan följer några fler rekommendationer på filsystemsnivå. Men de har inte testats ännu. Se till att ditt filsystem känner till storleken på stripe och antalet diskar i arrayen. Till exempel, att detta är en RAID5-array med stripe-storlek på 64K av sex diskar (egentligen fem, eftersom en disk används för paritet). Dessa rekommendationer baseras på teoretiska antaganden och har samlats från olika bloggar/artiklar av experter inom RAID.

-> ext4 fs, 5 diskar, 64K stripe, enheter i 4K block
mkfs -text4 -E stride=$((64/4))
-> xfs, 5 diskar, 64K stripe, enheter i 512-byte sektorer
mkfs -txfs -d sunit=$((64*2)) -d swidth=$((5*64*2))

För stora filer kan du överväga att öka de angivna stripstorlekarna ovan.

VARNING! Allt som beskrivs ovan är ytterst subjektivt för vissa typer av applikationer. Denna artikel garanterar inte några förbättringar utan föregående testning av de berörda applikationerna av användaren. Den bör endast tillämpas om det är nödvändigt att förbättra systemets övergripande respons eller om den löser aktuella problem.