Die vertaling van die artikel is voorberei op die vooraand van die aanvang van die kursus .
Van tyd tot tyd ontstaan hier en daar vrae oor Gluster se aanbevelings rakende pitaanpassing en of dit nodig is.
Hierdie behoefte ontstaan selde. Die kern presteer baie goed onder die meeste werkladings. Alhoewel daar 'n nadeel is. Histories verbruik die Linux-kern geredelik baie geheue as dit die geleentheid kry, insluitend vir kas as 'n primêre manier om werkverrigting te verbeter.
In die meeste gevalle werk dit uitstekend, maar onder swaar vrag kan dit probleme veroorsaak.
Ons het uitgebreide ondervinding om met stelsels te werk wat baie geheue verbruik, soos CAD, EDA en dies meer, wat onder hoë las begin vertraag het. En soms het ons probleme in Gluster ondervind. Nadat ons die geheue wat gebruik is en die skyfwagtyd vir meer as een dag noukeurig gemonitor het, het ons skyfoorlading, groot iowait, kernfoute (kern oops), vries, ens.
Hierdie artikel is die resultaat van baie parameter tuning eksperimente wat in verskillende situasies uitgevoer is. Danksy hierdie parameters het nie net die reaksie in die algemeen verbeter nie, maar ook die werking van die groepering is aansienlik gestabiliseer.
Wanneer dit kom by die konfigurasie van geheue, is die eerste plek om te kyk die virtuele geheue substelsel (VM), wat 'n groot aantal opsies het wat jou kan verwar.
vm.ruil
Parameter vm.swappiness bepaal hoeveel die kern swap gebruik in vergelyking met RAM. Dit word ook in die bronkode gedefinieer as "neiging om gekarteerde geheue te steel." 'n Hoë ruilwaarde beteken dat die kern meer geneig sal wees om gekarteerde bladsye te ruil. 'n Lae ruilwaarde beteken die teenoorgestelde: die kern sal bladsye uit die geheue minder ruil. Met ander woorde, hoe hoër die waarde vm.swappiness, hoe meer sal die stelsel swap gebruik.
Uitgebreide gebruik van omruiling is ongewens, aangesien groot blokke data in RAM gelaai en afgelaai word. Baie mense argumenteer dat die omruilwaarde hoog moet wees, maar volgens my ervaring lei dit tot beter prestasie as dit op "0" gestel word.
Jy kan meer hier lees -
Maar weereens, hierdie instellings moet met omsigtigheid gebruik word en eers nadat die spesifieke toepassing getoets is. Vir hoogs gelaaide stroomtoepassings, moet hierdie parameter op "0" gestel word. As dit na "0" verander word, verbeter die reaksie van die stelsel.
vm.vfs_cache_pressure
Hierdie instelling beheer die geheue wat deur die kern verbruik word vir die kas van gidsvoorwerpe en inodes (dentry en inode).
Met die verstekwaarde van 100, sal die kern probeer om die dentry- en inode-kas op 'n billike wyse na die pagecache en swapcache vry te maak. Die vermindering van vfs_cache_pressure veroorsaak dat die kern tande en inode-kas bewaar. Wanneer die waarde "0" is, sal die kern nooit die dentry en inode kas spoel nie as gevolg van geheue druk, en dit kan maklik lei tot 'n buite-geheue fout. Die verhoging van vfs_cache_pressure bo 100 veroorsaak dat die kern prioriteit gee aan tande en inode-bladsye.
Wanneer GlusterFS gebruik word, kan baie gebruikers met groot hoeveelhede data en baie klein lêers maklik 'n aansienlike hoeveelheid RAM op die bediener gebruik as gevolg van inode/dentry caching, wat kan lei tot swak werkverrigting aangesien die kern datastrukture op 'n stelsel moet hanteer met 40 GB geheue. Deur hierdie parameter op groter as 100 te stel, het baie gebruikers gehelp om regverdiger kas en verbeterde kernreaksie te bereik.
vm.dirty_background_ratio en vm.dirty_ratio
Eerste parameter (vm.dirty_background_ratio) bepaal die persentasie geheue met vuil bladsye, wanneer dit bereik is, is dit nodig om agtergrondspoeling van vuil bladsye na skyf te begin. Totdat hierdie persentasie bereik is, word bladsye nie na skyf gespoel nie. En wanneer die terugstelling begin, loop dit op die agtergrond sonder om lopende prosesse te onderbreek.
Tweede parameter (vm.dirty_ratio) bepaal die persentasie geheue wat deur vuil bladsye beset kan word voordat 'n gedwonge flits begin. Sodra hierdie drempel bereik is, word alle prosesse sinchronies (geblokkeer) en word nie toegelaat om voort te gaan totdat die I/O-bewerking wat hulle versoek het, werklik voltooi is en die data op skyf is nie. Met 'n hoë I/O-lading veroorsaak dit 'n probleem omdat daar geen datakas is nie en alle prosesse wat I/O doen word geblokkeer en wag vir I/O. Dit lei tot 'n groot aantal gehang prosesse, hoë las, stelsel onstabiliteit en swak werkverrigting.
Die vermindering van die waardes van hierdie parameters veroorsaak dat data meer gereeld na skyf gespoel word en nie in RAM gestoor word nie. Dit kan geheue-swaar stelsels help waar dit normaal is om 45-90GB bladsy-kasgeheue na skyf te stort, wat lei tot groot latensie vir voorkanttoepassings, wat algehele responsiwiteit en interaktiwiteit verminder.
"1"> /proc/sys/vm/pagecache
Bladsykas is 'n kas wat data van lêers en uitvoerbare programme stoor, dit wil sê, dit is bladsye met die werklike inhoud van lêers of blokkeertoestelle. Hierdie kas word gebruik om die aantal skyflesings te verminder. 'n Waarde van "1" beteken dat die kas 1% van RAM gebruik en daar sal meer lees vanaf skyf as vanaf RAM wees. Dit is nie nodig om hierdie instelling te verander nie, maar as jy paranoïes is oor die beheer van die bladsykas, kan jy dit gebruik.
"sperdatum" > /sys/block/sdc/queue/scheduler
Die I/O-skeduleerder is 'n komponent van die Linux-kern wat lees- en skryfrye hanteer. In teorie is dit beter om "noop" vir 'n slim RAID-beheerder te gebruik, want Linux weet niks van die fisiese geometrie van die skyf nie, dus is dit meer doeltreffend om die beheerder, wat die skyfgeometrie goed ken, die versoek te laat verwerk as vinnig as moontlik. Maar dit blyk dat "sperdatum" prestasie verbeter. Meer inligting oor skeduleers kan gevind word in die dokumentasie vir die Linux kern bronkode: linux/Documentation/block/*osched.txt. En ek het ook 'n toename in leesdeurvloei tydens gemengde bewerkings waargeneem (baie skryfwerk).
"256"> /sys/block/sdc/queue/nr_requests
Die aantal I/O-versoeke in die buffer voordat dit na die skeduleerder gestuur word. Sommige beheerders se interne tou-grootte (queue_depth) is groter as die I/O-skeduleerder se nr_requests, so die I/O-skeduleerder het min kans om versoeke korrek te prioritiseer en saam te voeg. Vir sperdatums en CFQ-skeduleerders is dit beter wanneer nr_requests 2 keer groter is as die beheerder se interne tou. Om navrae saam te voeg en te herrangskik help die skeduleerder om meer reageer onder swaar vrag.
eggo "16"> /proc/sys/vm/page-cluster
Die page-cluster parameter beheer die aantal bladsye wat op een slag na die ruil geskryf word. In die voorbeeld hierbo is die waarde op "16" gestel om by die RAID-streepgrootte van 64 KB te pas. Dit maak nie sin wanneer swappiness = 0 nie, maar as jy swappiness op 10 of 20 stel, sal die gebruik van hierdie waarde jou help wanneer die RAID-streepgrootte 64 KB is.
blockdev --setra 4096 /dev/<devnaam> (-sdb, hdc of dev_mapper)
Die verstekbloktoestelinstellings vir baie RAID-beheerders lei dikwels tot verskriklike werkverrigting. Deur die bogenoemde opsie by te voeg, konfigureer leesvooruit vir 4096*512 grepe-sektore. Ten minste vir stroomoperasies, word spoed verhoog deur die op-skyfskyfkas te vul via leesvooruit gedurende die tydperk wat die kern gebruik om I/O voor te berei. Die kas kan data bevat wat tydens die volgende lees aangevra sal word. Te veel leesvooruit kan ewekansige I/O vir groot lêers doodmaak as dit potensieel nuttige skyftyd opgebruik of data buite die kas laai.
Hieronder is nog 'n paar aanbevelings op die lêerstelselvlak. Maar hulle is nog nie getoets nie. Maak seker dat jou lêerstelsel die streepgrootte en die aantal skywe in die skikking ken. Byvoorbeeld, dat dit 'n raid5-skikking is met 'n streepgrootte van 64K van ses skywe (eintlik vyf, want een skyf word vir pariteit gebruik). Hierdie aanbevelings is gebaseer op teoretiese aannames en versamel uit verskeie blogs/artikels deur RAID-kundiges.
-> 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))Vir groter lêers, kan jy oorweeg om die bogenoemde streepgroottes te vergroot.
WAARSKUWING! Alles wat hierbo beskryf word, is uiters subjektief vir sommige soorte toepassings. Hierdie artikel waarborg geen verbeterings sonder om eers die onderskeie toepassings deur die gebruiker te toets nie. Dit moet slegs gebruik word as daar 'n behoefte is om algehele stelselresponsiwiteit te verbeter of as dit huidige probleme oplos.
Bykomende materiale:
Lees meer
Bron: will.com