{"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\/da\/blog\/administrirovanie\/nastrojka-yadra-linux-dlya-glusterfs","title":{"rendered":"Konfiguration af Linux-kernen til GlusterFS","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Overs\u00e6ttelsen af artiklen er udarbejdet forud for begyndelsen af kurset \u00abAdministrator Linux. Professionel\u00bb<\/a><\/noindex>.<\/i><\/b><\/p>\n

\"Konfiguration<\/p>\n

Der opst\u00e5r ind im mellem sp\u00f8rgsm\u00e5l om Glusters anbefalinger til kerneindstillinger, og om der er behov for dem.<\/p>\n

S\u00e5danne behov opst\u00e5r sj\u00e6ldent. I de fleste belastninger fungerer kernen rigtig godt. Der er dog en bagside. Historisk set har Linux-kernen en tendens til at forbruge meget hukommelse, hvis den f\u00e5r mulighed for det, herunder til caching som den prim\u00e6re metode til at \u00f8ge ydeevnen.<\/a><\/noindex><\/p>\n

I de fleste tilf\u00e6lde fungerer det fremragende, men ved stor belastning kan det f\u00f8re til problemer. <\/p>\n

Vi har stor erfaring med systemer, der forbruger meget hukommelse, s\u00e5som CAD, EDA og lignende, som begyndte at bremse under h\u00f8j belastning. Og nogle gange har vi st\u00f8dt p\u00e5 problemer i Gluster. Ved n\u00f8je at overv\u00e5ge hukommelsesforbruget og disktoppen i flere dage fik vi overbelastning, enorme iowait, kernel fejl (kernel oops), h\u00e6ngninger osv. <\/p>\n

Denne artikel er resultatet af mange eksperimenter med konfigurationer udf\u00f8rt i forskellige situationer. Takket v\u00e6re disse parametre er ikke kun responsiviteten generelt blevet forbedret, men stabiliteten i klyngen er ogs\u00e5 markant steget.<\/p>\n

N\u00e5r det kommer til hukommelsesindstillinger, skal man f\u00f8rst se p\u00e5 den virtuelle hukommelsessubsystem (VM, virtual memory), som har et stort antal indstillinger, der kan forvirre dig.<\/p>\n

vm.swappiness<\/h4>\n

\nParameter vm.swappiness<\/code> bestemmer, hvor meget kernen bruger swap sammenlignet med RAM. I kildekoden er det ogs\u00e5 defineret som \"tendency to steal mapped memory\". H\u00f8j v\u00e6rdi af swappiness betyder, at kernen vil v\u00e6re mere tilb\u00f8jelig til at udlade mappede sider. Lav v\u00e6rdi af swappiness betyder det modsatte: kernen vil udlade f\u00e6rre sider fra hukommelsen. Med andre ord, jo h\u00f8jere v\u00e6rdi, vm.swappiness<\/code>, jo mere vil systemet bruge swap.<\/p>\n

H\u00f8j brug af swapping er u\u00f8nsket, da enorme datablokke indl\u00e6ses og udl\u00e6ses i hukommelsen. Mange h\u00e6vder, at v\u00e6rdien for swappiness skal v\u00e6re h\u00f8j, men efter min erfaring f\u00f8rer en indstilling p\u00e5 \"0\" til bedre ydeevne.<\/p>\n

Du kan l\u00e6se mere her \u2014 lwn.net\/Articles\/100978<\/a><\/noindex> <\/p>\n

Men igen, disse indstillinger b\u00f8r anvendes med forsigtighed og kun efter test af den specifikke applikation. For h\u00f8jtydende streaming-applikationer b\u00f8r denne parameter indstilles til \"0\". N\u00e5r v\u00e6rdien \u00e6ndres til \"0\", forbedres systemets reaktionshastighed.<\/p>\n

vm.vfs_cache_pressure<\/h4>\n

\nDenne parameter styrer den hukommelse, som kernen bruger til at cache katalogobjekter og indeksdekskriptorer (dentry og inode).<\/p>\n

Med en standardv\u00e6rdi p\u00e5 100 vil kernen fors\u00f8ge at frigive dentry- og inode-cachen \"retf\u00e6rdigt\" i forhold til pagecache og swapcache. At reducere vfs_cache_pressure f\u00e5r kernen til at gemme dentry- og inode-cachene. N\u00e5r v\u00e6rdien er \"0\", vil kernen aldrig rense dentry- og inode-cachen p\u00e5 grund af hukommelsespres, hvilket let kan f\u00f8re til en out-of-memory-fejl. At \u00f8ge vfs_cache_pressure til over 100 giver kernen prioritet for at t\u00f8mme dentry og inode.<\/p>\n

N\u00e5r man bruger GlusterFS, kan mange brugere med store datam\u00e6ngder og mange sm\u00e5 filer nemt bruge betydelige m\u00e6ngder RAM p\u00e5 serveren p\u00e5 grund af caching af inode\/dentry, hvilket kan f\u00f8re til nedsat ydeevne, da kernen skal h\u00e5ndtere datostrukturer i et system med 40 GB hukommelse. At s\u00e6tte denne parameter til over 100 har hjulpet mange brugere med at opn\u00e5 mere retf\u00e6rdig caching og forbedre kernen's reaktionshastighed.<\/p>\n

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

\nDen f\u00f8rste parameter (vm.dirty_background_ratio<\/code>) bestemmer procentdelen af hukommelse med beskidte sider, ved hvilken man skal begynde den baggrundsbaserede rensning af beskidte sider til disken. S\u00e5 l\u00e6nge denne procentsats ikke er n\u00e5et, renses siderne ikke til disken. Og n\u00e5r rensningen begynder, sker det i baggrunden uden at forstyrre de k\u00f8rende processer. <\/p>\n

Den anden parameter (vm.dirty_ratio<\/code>) definerer den procentdel af hukommelsen, der kan optages af beskidte sider, f\u00f8r der p\u00e5begyndes et tvunget flash-reset. N\u00e5r denne gr\u00e6nse n\u00e5s, bliver alle processer synkrone (blokeres), og de f\u00e5r ikke lov til at forts\u00e6tte, indtil den anmodede I\/O-operation rent faktisk er afsluttet, og dataene er p\u00e5 disken. Ved h\u00f8j-belastet I\/O medf\u00f8rer dette problemer, da datacaching mangler, og alle processer, der udf\u00f8rer I\/O, blokeres i forventning om I\/O. Dette f\u00f8rer til mange h\u00e6ngende processer, h\u00f8j belastning, ustabil systemdrift og d\u00e5rlig ydeevne.<\/p>\n

At reducere v\u00e6rdierne for disse parametre medf\u00f8rer, at data oftere bliver skrevet til disken og ikke gemmes i RAM. Dette kan v\u00e6re nyttigt for systemer med meget hukommelse, hvor det er normalt at skrive en cache af sider p\u00e5 45\u201390 GB til disken, hvilket f\u00f8rer til enorme ventetider for frontend-applikationer, der mindsker den samlede respons og interaktivitet.<\/p>\n

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

\nSidedatabase (page cache) er en cache, hvor data fra filer og eksekverbare programmer opbevares, dvs. sider med det faktiske indhold af filer eller blokkerede enheder. Denne cache bruges til at reducere antallet af l\u00e6sninger fra disken. V\u00e6rdien \u00ab1\u00bb betyder, at 1% af RAM bruges til cachen, og der vil v\u00e6re flere l\u00e6seoperationer fra disken end fra RAM. Det er ikke n\u00f8dvendigt at \u00e6ndre denne parameter, men hvis du er paranoid omkring kontrol af sidescachen, kan du bruge den.<\/p>\n

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

\nI\/O-planl\u00e6ggeren (I\/O scheduler) er en komponent i Linux-kernen, der h\u00e5ndterer k\u00f8er af l\u00e6se- og skriveanmodninger. Teoretisk set er det bedre at bruge \u00abnoop\u00bb for en intelligent RAID-controller, fordi Linux ikke ved noget om den fysiske geometri af disken; derfor er det mere effektivt at lade controlleren, der kender diskens geometri, h\u00e5ndtere anmodningen s\u00e5 hurtigt som muligt. Men det ser ud til, at \u00abdeadline\u00bb forbedrer ydeevnen. Du kan l\u00e6se mere om planl\u00e6ggere i dokumentationen til Linux-kildekoden: linux\/Documentation\/block\/*osched.txt<\/code>. Og jeg har ogs\u00e5 observeret en stigning i l\u00e6sehastigheden under blandede operationer (mange skriveoperationer).<\/p>\n

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

\nAntallet af input-output anmodninger i bufferen, f\u00f8r de sendes til planl\u00e6ggeren. St\u00f8rrelsen p\u00e5 den interne k\u00f8 for nogle controllere (queue_depth) er st\u00f8rre end nr_requests for input-output planl\u00e6ggeren, hvilket betyder, at planl\u00e6ggeren har lidt chance for korrekt at prioritere og udf\u00f8re sammenl\u00e6gning af anmodninger. For deadline- og CFQ-planl\u00e6ggere er det bedst, n\u00e5r nr_requests er dobbelt s\u00e5 stort som den interne k\u00f8 for controlleren. Sammenl\u00e6gning og omorganisering af anmodninger hj\u00e6lper planl\u00e6ggeren med at v\u00e6re mere responsiv under h\u00f8j belastning.<\/p>\n

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

\nParameteren page-cluster styrer antallet af sider, der skrives til swap ad gangen. I eksemplet ovenfor er v\u00e6rdien indstillet til \u00ab16\u00bb i henhold til stripe-st\u00f8rrelsen (stripe size) i RAID p\u00e5 64 KB. Dette giver ikke mening ved swappiness = 0, men hvis du har indstillet swappiness til 10 eller 20, vil brugen af denne v\u00e6rdi v\u00e6re til hj\u00e6lp, n\u00e5r stripe-st\u00f8rrelsen i RAID er 64 KB.<\/p>\n

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

\nStandardindstillingerne for blok-enheder for mange RAID-controllere resulterer ofte i forf\u00e6rdelig ydeevne. Ved at tilf\u00f8je ovenst\u00e5ende mulighed indstilles forudsigende l\u00e6sning til 4096 * 512-byte sektioner. Mindst for stream operationer \u00f8ges hastigheden ved at fylde den indbyggede diskcache med forudsigende l\u00e6sning i den periode, der bruges af kernen til at forberede input-output. Data, der vil blive anmodet om ved n\u00e6ste l\u00e6sning, kan gemmes i cachen. Forudsigende l\u00e6sning, der er for stor, kan dr\u00e6be tilf\u00e6ldig input-output for store filer, hvis den bruger potentielt nyttig disktid eller indl\u00e6ser data uden for cachen.<\/p>\n

Her er nogle yderligere anbefalinger p\u00e5 filsystemniveau. Men de er endnu ikke testet. S\u00f8rg for, at dit filsystem kender stripe-st\u00f8rrelsen og antallet af diske i arrayet. For eksempel, at det er et raid5 array med stripe-st\u00f8rrelse p\u00e5 64K best\u00e5ende af seks diske (faktisk fem, fordi en disk bruges til paritet). Disse anbefalinger er baseret p\u00e5 teoretiske antagelser og er indsamlet fra forskellige blogs\/artikler fra RAID-eksperter.<\/p>\n

-> ext4 fs, 5 diske, 64K stripe, enheder i 4K blokke\nmkfs -text4 -E stride=$((64\/4))\n-> xfs, 5 diske, 64K stripe, enheder i 512-byte sektioner\nmkfs -txfs -d sunit=$((64*2)) -d swidth=$((5*64*2))<\/code><\/pre>\n
\nFor large files, consider increasing the specified strip sizes above.<\/p>\n
ADVISORY!<\/b> Everything described above is highly subjective for some types of applications. This article does not guarantee any improvements without prior testing of the relevant applications by the user. It should only be applied when necessary to improve overall system responsiveness or if it addresses current issues.<\/p>\n
Additional materials:<\/h4>\n
<\/p>\n