{"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\/no\/blog\/administrirovanie\/nastrojka-yadra-linux-dlya-glusterfs","title":{"rendered":"Konfigurering av Linux-kjernen for GlusterFS","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Artikkelen er oversatt i forkant av oppstarten av kurset \u00abAdministrator Linux. Professionell\u00bb<\/a><\/noindex>.<\/i><\/b><\/p>\n

\"Konfigurering<\/p>\n

Det oppst\u00e5r fra tid til annen sp\u00f8rsm\u00e5l om Gluster sine anbefalinger for kjerneinnstillinger og om det er n\u00f8dvendig.<\/p>\n

Slik n\u00f8dvendighet oppst\u00e5r sjelden. I de fleste belastninger fungerer kjernen veldig bra. Men det er ogs\u00e5 en annen side. Historisk har Linux-kjernen v\u00e6rt kjent for \u00e5 konsumere mye minne hvis den f\u00e5r muligheten, inkludert for caching som den prim\u00e6re metoden for \u00e5 \u00f8ke ytelsen.<\/a><\/noindex><\/p>\n

I de fleste tilfeller fungerer dette utmerket, men ved h\u00f8y belastning kan det f\u00f8re til problemer. <\/p>\n

Vi har stor erfaring med systemer som bruker mye minne, som CAD, EDA og lignende, som begynte \u00e5 henge seg opp ved h\u00f8y belastning. Og av og til har vi opplevd problemer med Gluster. Etter \u00e5 ha overv\u00e5ket bruken av minne og ventetid p\u00e5 disker i flere dager, fikk vi dem til \u00e5 overbelaste, med enorme iowait, kjernfeil (kernel oops), henginger, osv. <\/p>\n

Denne artikkelen er et resultat av mange eksperimenter med justering av parametere utf\u00f8rt i ulike situasjoner. Takket v\u00e6re disse parameterne har ikke bare responsiviteten forbedret seg generelt, men ogs\u00e5 stabiliteten i klyngen har \u00f8kt betydelig.<\/p>\n

N\u00e5r det kommer til minneinnstillinger, er det f\u00f8rste man m\u00e5 se p\u00e5 underrutinen for virtuell hukommelse (VM, virtual memory), som har et stort antall alternativer som kan forvirre deg.<\/p>\n

vm.swappiness<\/h4>\n

\nParameter vm.swappiness<\/code> Angir hvor mye kjernen bruker swapping (swap, sidekopiering) i forhold til RAM. I kildekoden er det ogs\u00e5 definert som \u00abtendency to steal mapped memory\u00bb (tendens til \u00e5 stjele kartlagt minne). H\u00f8yt swappiness-verdi betyr at kjernen er mer tilb\u00f8yelig til \u00e5 laste ut kartlagte sider. Lavt swappiness-verdi betyr det motsatte: kjernen vil laste ut f\u00e6rre sider fra minnet. Med andre ord, jo h\u00f8yere verdi vm.swappiness<\/code>, jo mer vil systemet bruke swap.<\/p>\n

Omfattende bruk av swapping er u\u00f8nsket, ettersom enorme datablokker lastes inn og ut av RAM. Mange hevder at swapiness-verdien b\u00f8r v\u00e6re h\u00f8y, men etter min erfaring f\u00f8rer innstilling til \u00ab0\u00bb til bedre ytelse.<\/p>\n

Du kan lese mer om dette her \u2014 lwn.net\/Articles\/100978<\/a><\/noindex> <\/p>\n

Men, igjen, disse innstillingene m\u00e5 anvendes med forsiktighet og kun etter testing av det spesifikke programmet. For h\u00f8ybelastede str\u00f8mmende applikasjoner b\u00f8r dette parameteret settes til \"0\". Ved endring til \"0\" forbedres systemresponsen.<\/p>\n

vm.vfs_cache_pressure<\/h4>\n

\nDette parameteret kontrollerer minnet som brukes av kjernen for \u00e5 cache katalogobjekter og indeksdeskriptorer (dentry og inode).<\/p>\n

N\u00e5r standard verdien er 100, vil kjernen pr\u00f8ve \u00e5 frigj\u00f8re dentry- og inode-cache \"rettferdig\" i forhold til pagecache og swapcache. Reduksjon av vfs_cache_pressure f\u00f8rer til at kjernen beholder dentry- og inode-cache. N\u00e5r verdien er \"0\", vil ikke kjernen rydde dentry- og inode-cache p\u00e5 grunn av minnepress, noe som lett kan f\u00f8re til en out-of-memory-feil. \u00d8kning av vfs_cache_pressure utover 100 f\u00f8rer til at kjernen prioriterer \u00e5 t\u00f8mme dentry- og inode-cache.<\/p>\n

Ved bruk av GlusterFS kan mange brukere med store datamengder og mange sm\u00e5 filer enkelt bruke betydelig mengde RAM p\u00e5 serveren p\u00e5 grunn av inode\/dentry caching, noe som kan f\u00f8re til redusert ytelse, ettersom kjernen m\u00e5 h\u00e5ndtere datastrukturer i et system med 40 GB minne. \u00c5 sette dette parameteret over 100 har hjulpet mange brukere oppn\u00e5 en mer rettferdig caching og forbedret kernel-respons.<\/p>\n

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

\nDen f\u00f8rste parameteren (vm.dirty_background_ratio<\/code>) definerer prosentandelen av minnet med skitne sider, hvorp\u00e5 det m\u00e5 begynne en bakgrunnsutl\u00f8sning av skitne sider til disk. S\u00e5 lenge denne prosentandelen ikke er n\u00e5dd, blir sidene ikke utl\u00f8st til disk. N\u00e5r utl\u00f8sningen begynner, skjer det i bakgrunnen og forstyrrer ikke de kj\u00f8rende prosessene. <\/p>\n

Den andre parameteren (vm.dirty_ratio<\/code>) definerer prosentandelen av minne som kan v\u00e6re opptatt av skitne sider f\u00f8r tvungen dumping (forced flash) begynner. N\u00e5r denne grensen n\u00e5s, blir alle prosessene synkrone (blokkert), og de f\u00e5r ikke lov til \u00e5 fortsette f\u00f8r den forespurte I\/O-operasjonen faktisk er fullf\u00f8rt og dataene er lagret p\u00e5 disken. Ved h\u00f8y belastning av I\/O skaper dette problemer, ettersom datacaching er frav\u00e6rende, og alle prosessene som utf\u00f8rer I\/O blir blokkert og venter p\u00e5 I\/O. Dette f\u00f8rer til mange hengende prosesser, h\u00f8y belastning, ustabil drift av systemet og d\u00e5rlig ytelse.<\/p>\n

\u00c5 redusere verdiene av disse parameterne gj\u00f8r at data oftere dumpes til disken og ikke oppbevares i RAM. Dette kan hjelpe systemer med mye minne, der det er normalt \u00e5 dumpe 45\u201390 GB med kjernepages til disken, noe som f\u00f8rer til massive ventetider for frontend-applikasjoner, og reduserer den totale responsiviteten og interaktiviteten.<\/p>\n

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

\nSidelageret (page cache) er et cache der data fra filer og utf\u00f8rbare programmer lagres, det vil si sider med faktisk innhold fra filer eller blokker. Denne cachen brukes for \u00e5 redusere antall lesinger fra disken. Verdien \u00ab1\u00bb betyr at 1% av RAM brukes for cachen, og antallet leseoperasjoner fra disken vil v\u00e6re h\u00f8yere enn fra RAM. Det er ikke n\u00f8dvendig \u00e5 endre denne parameteren, men hvis du er paranoid n\u00e5r det gjelder kontroll over sidelageret, kan du bruke den.<\/p>\n

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

\nI\/O-planleggeren (I\/O scheduler) er et kjernekomponent i Linux som h\u00e5ndterer k\u00f8er for lesing og skriving. Teoretisk sett er det bedre \u00e5 bruke \u00abnoop\u00bb for en smart RAID-kontroller, fordi Linux ikke vet noe om den fysiske geometrien til disken, s\u00e5 det er mer effektivt \u00e5 la kontrolleren, som godt kjenner disks geometriske oppsett, behandle foresp\u00f8rselen s\u00e5 raskt som mulig. Men det ser ut til at \u00abdeadline\u00bb forbedrer ytelsen. Mer om planleggerne kan leses i dokumentasjonen til kildekoden til Linux-kjernen: linux\/Documentation\/block\/*osched.txt<\/code>. Jeg har ogs\u00e5 observert en \u00f8kning i lesehastighet under blandede operasjoner (mange skriveoperasjoner).<\/p>\n

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

\nAntall I\/O-foresp\u00f8rsel i bufferen f\u00f8r de sendes til planleggeren. St\u00f8rrelsen p\u00e5 den interne k\u00f8en for noen kontroller (queue_depth) er st\u00f8rre enn nr_requests for I\/O-planleggeren, noe som gir lite rom for at I\/O-planleggeren kan prioritere og utf\u00f8re foresp\u00f8rselssammensl\u00e5ing korrekt. For deadline- og CFQ-planleggere er det best n\u00e5r nr_requests er dobbelt s\u00e5 stort som den interne k\u00f8en til kontrolleren. Sammensl\u00e5ing og omorganisering av foresp\u00f8rslene hjelper planleggeren med \u00e5 v\u00e6re mer responsiv under h\u00f8y belastning.<\/p>\n

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

\nParameteren page-cluster styrer antallet sider som skrives til swap om gangen. I eksempelet ovenfor settes verdien til \u00ab16\u00bb i samsvar med stripe-st\u00f8rrelsen (stripe size) av RAID til 64 KB. Dette gir ikke mening med swappiness = 0, men hvis du har satt swappiness til 10 eller 20, vil dette hjelpe deg n\u00e5r stripe-st\u00f8rrelsen for RAID er 64 KB.<\/p>\n

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

\nStandardinnstillingene for blokkenheter for mange RAID-kontrollere f\u00f8rer ofte til forferdelig ytelse. \u00c5 legge til alternativet ovenfor konfigurerer forh\u00e5ndslesing for 4096 * 512-byte sektorer. I det minste for str\u00f8mmende operasjoner \u00f8ker dette hastigheten ved \u00e5 fylle den innebygde diskbufferen via forh\u00e5ndslesing i l\u00f8pet av den tiden kjernen bruker til \u00e5 forberede I\/O. Data kan buffres som vil bli forespurt ved neste lesing. For mye forh\u00e5ndslesing kan \u00f8delegge tilfeldig I\/O for store filer hvis den bruker potensielt nyttig disk-tid eller henter data utenfor cachen.<\/p>\n

Her er noen flere anbefalinger p\u00e5 filsystemniv\u00e5. Men de har ikke blitt testet enn\u00e5. S\u00f8rg for at filsystemet ditt kjenner stripe-st\u00f8rrelsen og antallet disker i oppsettet. For eksempel at dette er et raid5-oppsett med en stripe-st\u00f8rrelse p\u00e5 64K fra seks disker (faktisk fem, ettersom en disk brukes til paritet). Disse anbefalingene er basert p\u00e5 teoretiske antagelser og samlet fra forskjellige blogger\/artikler av RAID-eksperter.<\/p>\n

-> ext4 fs, 5 disker, 64K stripe, enheter i 4K blokker\nmkfs -text4 -E stride=$((64\/4))\n-> xfs, 5 disker, 64K stripe, enheter i 512-byte sektorer\nmkfs -txfs -d sunit=$((64*2)) -d swidth=$((5*64*2))<\/code><\/pre>\n
\nFor large files, you might consider increasing the previously mentioned stripe sizes.<\/p>\n
WARNING!<\/b> Everything described above is highly subjective for certain types of applications. This article does not guarantee any improvements without prior testing of the corresponding applications by the user. It should only be applied if it improves overall system responsiveness or if it addresses current issues.<\/p>\n
Additional materials:<\/h4>\n
<\/p>\n