{"id":95783,"date":"2020-10-03T13:42:02","date_gmt":"2020-10-03T11:42:02","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/nastrojka-yadra-linux-dlya-glusterfs"},"modified":"2020-10-03T13:42:02","modified_gmt":"2020-10-03T11:42:02","slug":"nastrojka-yadra-linux-dlya-glusterfs","status":"publish","type":"post","link":"https:\/\/prohoster.info\/sv\/blog\/administrirovanie\/nastrojka-yadra-linux-dlya-glusterfs","title":{"rendered":"Konfiguration av Linux-k\u00e4rnan f\u00f6r GlusterFS","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\u00d6vers\u00e4ttningen av artikeln \u00e4r framtagen inf\u00f6r kursstarten \u00abLinux Administrator. Professionell\u00bb<\/a><\/noindex>.<\/i><\/b><\/p>\n

\"Konfiguration<\/p>\n

Ibland dyker fr\u00e5gor upp h\u00e4r och d\u00e4r ang\u00e5ende Glusters rekommendationer f\u00f6r k\u00e4rninst\u00e4llningar och om det verkligen \u00e4r n\u00f6dv\u00e4ndigt.<\/p>\n

S\u00e5dana behov uppst\u00e5r s\u00e4llan. I de flesta belastningar fungerar k\u00e4rnan mycket bra. Men det finns \u00e4ven en annan sida. Historiskt sett \u00e4r Linux-k\u00e4rnan ben\u00e4gen att konsumera mycket minne om man ger den m\u00f6jligheten, inklusive f\u00f6r caching som det prim\u00e4ra s\u00e4ttet att \u00f6ka prestanda.<\/a><\/noindex><\/p>\n

I de flesta fall fungerar detta utm\u00e4rkt, men vid h\u00f6g belastning kan det leda till problem. <\/p>\n

Vi har stor erfarenhet av system som anv\u00e4nder mycket minne, som CAD, EDA och liknande, som b\u00f6rjade bromsa vid h\u00f6g belastning. Och ibland har vi st\u00f6tt p\u00e5 problem med Gluster. Genom att noggrant \u00f6vervaka minnesanv\u00e4ndning och diskens svarstider under flera dagar har vi f\u00e5tt dem att \u00f6verbelastas, med enorma iowait, k\u00e4rnfel (kernel oops), frysningar osv. <\/p>\n

Denna artikel \u00e4r resultatet av m\u00e5nga experiment med inst\u00e4llning av parametrar utf\u00f6rda under olika f\u00f6rh\u00e5llanden. Tack vare dessa parametrar har b\u00e5de responsiviteten f\u00f6rb\u00e4ttrats och klustrets stabilitet \u00f6kat avsev\u00e4rt.<\/p>\n

N\u00e4r det kommer till minnesinst\u00e4llningar \u00e4r det f\u00f6rst och fr\u00e4mst viktigt att titta p\u00e5 det virtuella minnessystemet (VM, virtual memory), som har m\u00e5nga alternativ som kan f\u00f6rvirra.<\/p>\n

vm.swappiness<\/h4>\n

\nParameter vm.swappiness<\/code> best\u00e4mmer hur mycket k\u00e4rnan anv\u00e4nder swap (utbyte) j\u00e4mf\u00f6rt med det fasta minnet. I k\u00e4llkoden definieras det ocks\u00e5 som \u00abtendency to steal mapped memory\u00bb (tendens att stj\u00e4la kartlagt minne). Ett h\u00f6gt v\u00e4rde av swappiness betyder att k\u00e4rnan kommer att ha en st\u00f6rre ben\u00e4genhet att avlasta kartlagda sidor. Ett l\u00e5gt v\u00e4rde av swappiness inneb\u00e4r det motsatta: k\u00e4rnan kommer att avlasta sidor mindre fr\u00e5n minnet. Med andra ord, ju h\u00f6gre v\u00e4rde, vm.swappiness<\/code>, desto mer kommer systemet att anv\u00e4nda swap.<\/p>\n

Ett stort anv\u00e4ndande av swap \u00e4r o\u00f6nskat, eftersom stora datam\u00e4ngder laddas in och ut ur RAM-minnet. M\u00e5nga h\u00e4vdar att v\u00e4rdet f\u00f6r swappiness b\u00f6r vara h\u00f6gt, men enligt min erfarenhet ger en inst\u00e4llning p\u00e5 \u00ab0\u00bb \u00f6kad prestanda.<\/p>\n

Mer information kan l\u00e4sas h\u00e4r \u2014 lwn.net\/Articles\/100978<\/a><\/noindex> <\/p>\n

Men \u00e5terigen, dessa inst\u00e4llningar b\u00f6r till\u00e4mpas med f\u00f6rsiktighet och endast efter att ha testat den specifika applikationen. F\u00f6r h\u00f6gbelastade str\u00f6mmande applikationer b\u00f6r detta v\u00e4rde s\u00e4ttas till \"0\". N\u00e4r det \u00e4ndras till \"0\" f\u00f6rb\u00e4ttras systemets respons.<\/p>\n

vm.vfs_cache_pressure<\/h4>\n

\nDenna parameter kontrollerar minnet som anv\u00e4nds av k\u00e4rnan f\u00f6r att cachea katalogobjekt och indexeringsbeskrivare (dentry och inode).<\/p>\n

Med standardv\u00e4rdet p\u00e5 100 kommer k\u00e4rnan att f\u00f6rs\u00f6ka frig\u00f6ra dentry- och inode-cache r\u00e4ttvist i f\u00f6rh\u00e5llande till pagecache och swapcache. Att minska vfs_cache_pressure resulterar i att k\u00e4rnan beh\u00e5ller dentry- och inode-cachar. N\u00e4r v\u00e4rdet \u00e4r \"0\" kommer k\u00e4rnan aldrig att rensa dentry- och inode-cache p\u00e5 grund av minnesbrist, och detta kan l\u00e4tt leda till en out-of-memory-fel. Att \u00f6ka vfs_cache_pressure till mer \u00e4n 100 ger k\u00e4rnan prioritet f\u00f6r att frig\u00f6ra dentry- och inode-cache.<\/p>\n

N\u00e4r man anv\u00e4nder GlusterFS kan m\u00e5nga anv\u00e4ndare med stora datam\u00e4ngder och m\u00e5nga sm\u00e5 filer l\u00e4tt anv\u00e4nda en betydande m\u00e4ngd RAM p\u00e5 servern p\u00e5 grund av caching av inode\/dentry, vilket kan leda till minskad prestanda, eftersom k\u00e4rnan m\u00e5ste hantera datastrukturer i ett system med 40 GB minne. Att st\u00e4lla in denna parameter till \u00f6ver 100 har hj\u00e4lpt m\u00e5nga anv\u00e4ndare att uppn\u00e5 mer r\u00e4ttvis caching och f\u00f6rb\u00e4ttra k\u00e4rnans respons.<\/p>\n

vm.dirty_background_ratio och vm.dirty_ratio<\/h4>\n

\nDen f\u00f6rsta parametern (vm.dirty_background_ratio<\/code>) definierar procentandelen av minnet med smutsiga sidor, efter att ha n\u00e5tt vilket man m\u00e5ste b\u00f6rja en bakgrundsskrivning av smutsiga sidor till disk. S\u00e5 l\u00e4nge denna procentandel inte har n\u00e5tts skrivs sidor inte till disk. Och n\u00e4r skrivningen b\u00f6rjar sker den i bakgrunden utan att avbryta p\u00e5g\u00e5ende processer. <\/p>\n

Den andra parametern (vm.dirty_ratio<\/code>) definierar procentandelen minne som kan anv\u00e4ndas av smutsiga sidor innan en tvingad skrivning (forced flash) b\u00f6rjar. N\u00e4r denna tr\u00f6skel n\u00e5s blir alla processer synkrona (blockeras), och de ges inget tillst\u00e5nd att forts\u00e4tta f\u00f6rr\u00e4n den beg\u00e4rda in- och utdataoperationen faktiskt har slutf\u00f6rts och data \u00e4r p\u00e5 disken. Vid h\u00f6gbelastad in- och utdata skapar detta problem eftersom datacachning saknas, och alla processer som utf\u00f6r in- och utdata blockeras i v\u00e4ntan p\u00e5 in- och utdata. Detta leder till ett stort antal h\u00e4ngande processer, h\u00f6g belastning, instabil drift av systemet och d\u00e5lig prestanda.<\/p>\n

Att s\u00e4nka v\u00e4rdena f\u00f6r dessa parametrar g\u00f6r att data oftare skrivs till disken och inte lagras i RAM. Detta kan hj\u00e4lpa system med mycket minne, d\u00e4r det \u00e4r normalt att skriva $45\u201390 GB sidcache till disken, vilket leder till enorma v\u00e4ntetider f\u00f6r frontend-applikationer och minskar den \u00f6vergripande responsiviteten och interaktiviteten.<\/p>\n

\u00ab1\u00bb > \/proc\/sys\/vm\/pagecache<\/h4>\n

\nSidcache (page cache) \u00e4r en cache d\u00e4r data fr\u00e5n filer och k\u00f6rbara program lagras, det vill s\u00e4ga sidor med den faktiska inneh\u00e5llet fr\u00e5n filer eller blockenheter. Denna cache anv\u00e4nds f\u00f6r att minska antalet l\u00e4sningar fr\u00e5n disken. V\u00e4rdet \u00ab1\u00bb betyder att cachen anv\u00e4nder 1% av RAM och antalet l\u00e4sningar fr\u00e5n disken kommer att vara fler \u00e4n fr\u00e5n RAM. Det \u00e4r inte n\u00f6dv\u00e4ndigt att \u00e4ndra detta parameter, men om du \u00e4r paranoid \u00f6ver kontrollen av sidcache, kan du anv\u00e4nda den.<\/p>\n

\u00abdeadline\u00bb > \/sys\/block\/sdc\/queue\/scheduler<\/h4>\n

\nIn- och utdata-schemal\u00e4ggaren (I\/O scheduler) \u00e4r en komponent i Linux-k\u00e4rnan som hanterar k\u00f6er f\u00f6r l\u00e4sning och skrivning. Teoretiskt sett \u00e4r det b\u00e4ttre att anv\u00e4nda \u00abnoop\u00bb f\u00f6r en smart RAID-kontroller, eftersom Linux inte vet n\u00e5got om diskens fysiska geometri, s\u00e5 det \u00e4r mer effektivt att l\u00e5ta kontroller som v\u00e4l k\u00e4nner till diskens geometri bearbeta beg\u00e4ran s\u00e5 snabbt som m\u00f6jligt. Men det verkar som att \u00abdeadline\u00bb \u00f6kar prestandan. Mer information om schemal\u00e4ggarna kan l\u00e4sas i dokumentationen till Linux-k\u00e4rnans k\u00e4llkod: linux\/Documentation\/block\/*osched.txt<\/code>. Och jag har ocks\u00e5 observerat en \u00f6kning av l\u00e4shastigheten under blandade operationer (m\u00e5nga skrivoperationer).<\/p>\n

\u00ab256\u00bb > \/sys\/block\/sdc\/queue\/nr_requests<\/h4>\n

\nAntalet in- och utdatafr\u00e5gor i bufferten innan de \u00f6verf\u00f6rs till schemal\u00e4ggaren. Storleken p\u00e5 den interna k\u00f6n f\u00f6r vissa kontroller (queue_depth) \u00e4r st\u00f6rre \u00e4n nr_requests f\u00f6r in- och utdata-schemal\u00e4ggaren, vilket g\u00f6r att schemal\u00e4ggaren har f\u00e5 chanser att korrekt prioritera och genomf\u00f6ra sammanfogning av f\u00f6rfr\u00e5gningar. F\u00f6r deadline- och CFQ-schemal\u00e4ggare \u00e4r det b\u00e4ttre n\u00e4r nr_requests \u00e4r dubbelt s\u00e5 stort som den interna k\u00f6n f\u00f6r kontrollern. Sammanfogning och omstrukturering av f\u00f6rfr\u00e5gningar hj\u00e4lper schemal\u00e4ggaren att vara mer responsiv under h\u00f6g belastning.<\/p>\n

echo \u00ab16\u00bb > \/proc\/sys\/vm\/page-cluster<\/h4>\n

\nParametern page-cluster styr antalet sidor som skrivs till swap \u00e5t g\u00e5ngen. I ovanst\u00e5ende exempel s\u00e4tts v\u00e4rdet till \"16\" enligt storleken p\u00e5 stripe (stripe size) f\u00f6r RAID p\u00e5 64 KB. Detta \u00e4r meningsl\u00f6st vid swappiness = 0, men om du har st\u00e4llt in swappiness p\u00e5 10 eller 20, kommer anv\u00e4ndning av detta v\u00e4rde hj\u00e4lpa n\u00e4r storleken p\u00e5 RAID-stripe \u00e4r 64 KB.<\/p>\n

blockdev \u2014setra 4096 \/dev\/<<\/code>devname><\/code> (-sdb, hdc eller dev_mapper)<\/h4>\n

\nStandardinst\u00e4llningarna f\u00f6r blockenheter f\u00f6r m\u00e5nga RAID-kontroller leder ofta till usel prestanda. Genom att l\u00e4gga till den ovanst\u00e5ende parametern st\u00e4ller du in f\u00f6rhandsl\u00e4sning f\u00f6r 4096 * 512-byte sektorer. \u00c5tminstone f\u00f6r str\u00f6mmande operationer \u00f6kar hastigheten genom att fylla det inbyggda diskkaket via f\u00f6rhandsl\u00e4sning under den tid som k\u00e4rnan anv\u00e4nder f\u00f6r att f\u00f6rbereda in- och utdata. Data som kommer att beg\u00e4ras vid n\u00e4sta l\u00e4sning kan placeras i cache. F\u00f6r mycket f\u00f6rhandsl\u00e4sning kan f\u00f6rst\u00f6ra slumpm\u00e4ssig in- och utdata f\u00f6r stora filer om det utnyttjar potentiellt nyttig disk tid eller laddar data utanf\u00f6r cachen.<\/p>\n

Nedan f\u00f6ljer n\u00e5gra fler rekommendationer p\u00e5 filsystemsniv\u00e5. Men de har inte testats \u00e4nnu. Se till att ditt filsystem k\u00e4nner till storleken p\u00e5 stripe och antalet diskar i arrayen. Till exempel, att detta \u00e4r en RAID5-array med stripe-storlek p\u00e5 64K av sex diskar (egentligen fem, eftersom en disk anv\u00e4nds f\u00f6r paritet). Dessa rekommendationer baseras p\u00e5 teoretiska antaganden och har samlats fr\u00e5n olika bloggar\/artiklar av experter inom RAID.<\/p>\n

-> ext4 fs, 5 diskar, 64K stripe, enheter i 4K block\nmkfs -text4 -E stride=$((64\/4))\n-> xfs, 5 diskar, 64K stripe, enheter i 512-byte sektorer\nmkfs -txfs -d sunit=$((64*2)) -d swidth=$((5*64*2))<\/code><\/pre>\n
\nF\u00f6r stora filer kan du \u00f6verv\u00e4ga att \u00f6ka de angivna stripstorlekarna ovan.<\/p>\n
VARNING!<\/b> Allt som beskrivs ovan \u00e4r ytterst subjektivt f\u00f6r vissa typer av applikationer. Denna artikel garanterar inte n\u00e5gra f\u00f6rb\u00e4ttringar utan f\u00f6reg\u00e5ende testning av de ber\u00f6rda applikationerna av anv\u00e4ndaren. Den b\u00f6r endast till\u00e4mpas om det \u00e4r n\u00f6dv\u00e4ndigt att f\u00f6rb\u00e4ttra systemets \u00f6vergripande respons eller om den l\u00f6ser aktuella problem.<\/p>\n
Ytterligare material:<\/h4>\n
<\/p>\n