Þýðing á greininni var unnin í aðdraganda námskeiðsins .
Af og til vakna hér og þar spurningar um ráðleggingar Gluster varðandi aðlögun kjarna og hvort það sé nauðsynlegt.
Þessi þörf kemur sjaldan upp. Kjarninn stendur sig mjög vel undir flestu vinnuálagi. Þó það sé galli. Sögulega notar Linux kjarninn auðveldlega mikið af minni ef tækifæri gefst, þar á meðal fyrir skyndiminni sem aðal leið til að bæta árangur.
Í flestum tilfellum virkar þetta frábærlega, en undir miklu álagi getur það valdið vandræðum.
Við höfum mikla reynslu af því að vinna með kerfi sem eyða miklu minni eins og CAD, EDA og þess háttar sem fór að hægja á sér við mikið álag. Og stundum lentum við í vandræðum í Gluster. Eftir að hafa fylgst vandlega með minni sem notað er og biðtíma disks í meira en einn dag, fengum við ofhleðslu á diskum, gríðarlega iowait, kjarnavillur (kjarna úps), frýs o.s.frv.
Þessi grein er afrakstur margra breytustillingstilrauna sem gerðar eru við ýmsar aðstæður. Þökk sé þessum breytum batnaði ekki aðeins svörun almennt heldur var rekstur klasans verulega stöðugur.
Þegar kemur að því að stilla minni er fyrsti staðurinn til að leita er sýndarminni undirkerfið (VM), sem hefur mikinn fjölda valkosta sem geta ruglað þig.
vm.skipti
Viðfang vm.swappiness ákvarðar hversu mikið kjarninn notar swap samanborið við vinnsluminni. Það er einnig skilgreint í frumkóðanum sem „tilhneiging til að stela kortlagt minni. Hátt skiptagildi þýðir að kjarnanum er hættara við að skipta um kortlagðar síður. Lágt skiptigildi þýðir hið gagnstæða: kjarninn mun síður skipta um síður úr minni. Með öðrum orðum, því hærra sem gildið er vm.swappiness, því meira sem kerfið notar skipti.
Mikil notkun skipta er óæskileg, þar sem risastórar gagnablokkir eru hlaðnar og losaðar í vinnsluminni. Margir halda því fram að skiptagildið ætti að vera hátt, en mín reynsla, að setja það á „0“, skilar betri árangri.
Þú getur lesið meira hér -
En aftur, þessar stillingar ætti að nota með varúð og aðeins eftir að hafa prófað tiltekið forrit. Fyrir streymisforrit sem eru mikið hlaðin ætti þessi færibreyta að vera stillt á „0“. Þegar það er breytt í „0“ batnar viðbragð kerfisins.
vm.vfs_cache_pressure
Þessi stilling stjórnar minninu sem kjarninn notar til að geyma skráarhluti og innóða (dentry og inode).
Með sjálfgefnu gildinu 100 mun kjarninn reyna að losa tannskyndiminni og inode skyndiminni á sanngjarnan hátt í pagecache og swapcache. Minnkandi vfs_cache_pressure veldur því að kjarninn varðveitir tannskemmdir og inode skyndiminni. Þegar gildið er „0“ mun kjarninn aldrei skola tannskyndiminni og inode skyndiminni vegna minnisþrýstings og það getur auðveldlega leitt til villu úr minni. Aukning vfs_cache_pressure yfir 100 veldur því að kjarninn veitir forgangi fyrir tönn og inode pageouts.
Þegar GlusterFS er notað geta margir notendur með mikið gagnamagn og margar litlar skrár auðveldlega notað umtalsvert magn af vinnsluminni á þjóninum vegna inode/dentry skyndiminni, sem getur leitt til lélegrar frammistöðu þar sem kjarninn þarf að höndla gagnauppbyggingu á kerfi. með 40 GB minni. Að stilla þessa færibreytu á meira en 100 hefur hjálpað mörgum notendum að ná sanngjarnari skyndiminni og bættri svörun kjarna.
vm.dirty_background_ratio og vm.dirty_ratio
Fyrsta færibreytan (vm.dirty_background_ratio) ákvarðar hlutfall minnis með óhreinum síðum, þegar þeim er náð er nauðsynlegt að hefja bakgrunnsskolun á óhreinum síðum á diskinn. Þangað til þessu hlutfalli er náð eru síður ekki skolaðar á diskinn. Og þegar endurstillingin byrjar, keyrir hún í bakgrunni án þess að trufla hlaupandi ferli.
Önnur færibreyta (vm.dirty_ratio) ákvarðar hlutfall af minni sem getur verið upptekið af óhreinum síðum áður en þvingað flass byrjar. Þegar þessum þröskuldi er náð verða öll ferli samstillt (lokuð) og er ekki leyft að halda áfram að keyra fyrr en I/O aðgerðinni sem þeir báðu um er í raun lokið og gögnin eru á disknum. Með miklu I/O álagi veldur þetta vandamálum vegna þess að það er engin skyndiminni gagna og öll ferli sem gera I/O eru læst og bíða eftir I/O. Þetta hefur í för með sér mikinn fjölda hengdra ferla, mikið álag, óstöðugleika kerfisins og léleg frammistöðu.
Lækkun á gildum þessara breytu veldur því að gögn eru skoluð á diskinn oftar og ekki geymd í vinnsluminni. Þetta getur hjálpað minnisþungum kerfum þar sem eðlilegt er að skola 45-90GB síðu skyndiminni á diskinn, sem leiðir til mikillar leynd fyrir framendaforrit, sem dregur úr almennri svörun og gagnvirkni.
"1"> /proc/sys/vm/pagecache
Page Cache er skyndiminni sem geymir gögn úr skrám og keyranlegum forritum, það er að segja þetta eru síður með raunverulegu innihaldi skráa eða blokkartæki. Þetta skyndiminni er notað til að fækka disklestri. Gildið "1" þýðir að skyndiminni notar 1% af vinnsluminni og það verður meira lesið af diski en af vinnsluminni. Það er ekki nauðsynlegt að breyta þessari stillingu, en ef þú ert vænisjúkur um að stjórna skyndiminni síðunnar geturðu notað það.
"frestur" > /sys/block/sdc/queue/scheduler
I/O tímaáætlunarmaðurinn er hluti af Linux kjarnanum sem sér um lestrar- og ritraðir. Fræðilega séð er betra að nota "noop" fyrir snjall RAID stjórnandi, því Linux veit ekkert um eðlisfræðilega rúmfræði disksins, þannig að það er skilvirkara að láta stjórnandann, sem þekkir rúmfræði disksins vel, afgreiða beiðnina sem fljótt og hægt er. En það virðist sem "deadline" bætir árangur. Frekari upplýsingar um tímasetningar er að finna í skjölunum fyrir Linux kjarna frumkóðann: linux/Documentation/block/*osched.txt. Og ég sá líka aukningu á lestrarflæði við blandaðar aðgerðir (mikið af skrifum).
"256"> /sys/block/sdc/queue/nr_requests
Fjöldi I/O beiðna í biðminni áður en þær eru sendar til tímaáætlunar. Innri biðraðarstærð sumra stýrimanna (queue_depth) er stærri en nr_requests I/O tímaáætlunarmannsins, þannig að I/O tímaáætlunarmaðurinn hefur litla möguleika á að forgangsraða rétt og sameina beiðnir. Fyrir frest og CFQ tímaáætlun er betra þegar nr_requests er 2 sinnum stærri en innri biðröð stjórnandans. Sameining og endurröðun fyrirspurna hjálpar tímaáætlunarmanninum að vera móttækilegri undir miklu álagi.
echo "16"> /proc/sys/vm/page-cluster
Síðuklasa færibreytan stjórnar fjölda síðna sem eru skrifaðar í skiptin í einu. Í dæminu hér að ofan er gildið stillt á „16“ til að passa við RAID röndastærðina 64 KB. Þetta er ekki skynsamlegt þegar swappiness = 0, en ef þú stillir swappiness á 10 eða 20, þá mun það að nota þetta gildi hjálpa þér þegar RAID röndastærðin er 64 KB.
blockdev --setra 4096 /dev/<devname> (-sdb, hdc eða dev_mapper)
Sjálfgefnar blokkunarstillingar fyrir marga RAID stýringar leiða oft til hræðilegrar frammistöðu. Með því að bæta við ofangreindum valkosti stillirðu framlestur fyrir 4096*512 bæta geira. Að minnsta kosti fyrir streymisaðgerðir er hraðinn aukinn með því að fylla skyndiminni á flís disknum í gegnum read-ahead á tímabilinu sem kjarninn notar til að undirbúa I/O. Skyndiminnið getur geymt gögn sem beðið verður um við næstu lestur. Of mikið aflestur getur drepið handahófskennt I/O fyrir stórar skrár ef það notar mögulega gagnlegan disktíma eða hleður gögnum utan skyndiminni.
Hér að neðan eru nokkrar fleiri ráðleggingar á skráarkerfisstigi. En þeir hafa ekki verið prófaðir ennþá. Gakktu úr skugga um að skráarkerfið þitt viti röndastærðina og fjölda diska í fylkinu. Til dæmis, að þetta er raid5 fylki með röndastærð 64K af sex diskum (reyndar fimm, vegna þess að einn diskur er notaður fyrir parity). Þessar ráðleggingar eru byggðar á fræðilegum forsendum og safnað úr ýmsum bloggum/greinum af RAID sérfræðingum.
-> 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))Fyrir stærri skrár gætirðu íhugað að auka ofangreindar röndastærðir.
VIÐVÖRUN! Allt sem lýst er hér að ofan er afar huglægt fyrir sumar tegundir forrita. Þessi grein ábyrgist ekki endurbætur án þess að prófa viðkomandi forrit fyrst af notandanum. Það ætti aðeins að nota ef þörf er á að bæta heildarviðbrögð kerfisins eða ef það leysir núverandi vandamál.
Viðbótarefni:
Lestu meira
Heimild: www.habr.com