Artikkelin käännös valmistettiin kurssin alkamisen aattona .
Ajoittain herää siellä täällä kysymyksiä Glusterin ytimen mukauttamissuosituksista ja sen tarpeellisuudesta.
Tätä tarvetta tulee harvoin. Ydin toimii erittäin hyvin useimmissa työkuormissa. Vaikka siinä on huono puoli. Historiallisesti Linux-ydin kuluttaa helposti paljon muistia, jos siihen annetaan mahdollisuus, mukaan lukien välimuistin käyttäminen ensisijaisena suorituskyvyn parantamiskeinona.
Useimmissa tapauksissa tämä toimii hyvin, mutta raskaassa kuormituksessa se voi aiheuttaa ongelmia.
Meillä on laaja kokemus työskentelystä paljon muistia kuluttavien järjestelmien kanssa, kuten CAD, EDA ja vastaavat, jotka alkoivat hidastua suuressa kuormituksessa. Ja joskus kohtasimme ongelmia Glusterissa. Tarkkailtuamme käytettyä muistia ja levyn odotusaikaa yli yhden päivän ajan, saimme levyn ylikuormituksen, valtavan iowaitin, ydinvirheitä (ytimen oho), jumiutumia jne.
Tämä artikkeli on tulos monista eri tilanteissa suoritetuista parametrien säätökokeista. Näiden parametrien ansiosta ei vain reagointikyky yleisesti parantunut, vaan myös klusterin toiminta vakiintui merkittävästi.
Mitä tulee muistin määrittämiseen, ensimmäinen paikka on katsoa virtuaalimuistin alijärjestelmää (VM), jossa on suuri määrä vaihtoehtoja, jotka voivat hämmentää sinua.
vm.swappiness
Parametri vm.swappiness määrittää kuinka paljon ydin käyttää swapia verrattuna RAM-muistiin. Se on myös määritelty lähdekoodissa "taipumukseksi varastaa kartoitettua muistia". Korkea swappiness-arvo tarkoittaa, että ydin on alttiimpi vaihtamaan kartoitettuja sivuja. Alhainen vaihtoarvo tarkoittaa päinvastaista: ydin vaihtaa sivuja muistista vähemmän. Toisin sanoen mitä korkeampi arvo vm.swappiness, sitä enemmän järjestelmä käyttää swapia.
Laaja vaihtamisen käyttö ei ole toivottavaa, koska RAM-muistiin ladataan ja puretaan valtavia tietolohkoja. Monet ihmiset väittävät, että vaihtoarvon pitäisi olla korkea, mutta kokemukseni mukaan sen asettaminen arvoon "0" johtaa parempaan suorituskykyyn.
Voit lukea lisää täältä -
Mutta jälleen kerran, näitä asetuksia tulee käyttää varoen ja vasta sen jälkeen, kun tietty sovellus on testattu. Korkeasti ladatuissa suoratoistosovelluksissa tämän parametrin arvoksi tulee asettaa "0". Kun se muutetaan arvoon "0", järjestelmän reagointikyky paranee.
vm.vfs_cache_pressure
Tämä asetus ohjaa muistia, jonka ydin kuluttaa hakemistoobjektien ja inodien (dentry ja inode) välimuistiin tallentamiseen.
Oletusarvolla 100 ydin yrittää vapauttaa dentry- ja inode-välimuistit reilulla tavalla sivuvälimuistiin ja swapcacheen. Vfs_cache_pressure-arvon pienentäminen saa ytimen säilyttämään dentry- ja inode-välimuistit. Kun arvo on "0", ydin ei koskaan tyhjennä dentry- ja inode-välimuistia muistin paineen vuoksi, ja tämä voi helposti johtaa muistin lopussa -virheeseen. Jos vfs_cache_pressure nostetaan yli 100:n, ydin antaa etusijalle dentry- ja inode-sivun poistot.
GlusterFS:ää käytettäessä monet käyttäjät, joilla on suuria tietomääriä ja pieniä tiedostoja, voivat helposti käyttää huomattavan määrän RAM-muistia palvelimella inode/dentry-välimuistin vuoksi, mikä voi johtaa huonoon suorituskykyyn, koska ytimen on käsiteltävä järjestelmän tietorakenteita. 40GB muistilla. Tämän parametrin asettaminen suuremmaksi kuin 100 on auttanut monia käyttäjiä saavuttamaan oikeudenmukaisemman välimuistin ja parantanut ytimen reagointikykyä.
vm.dirty_background_ratio ja vm.dirty_ratio
Ensimmäinen parametri (vm.dirty_background_ratio) määrittää likaisten sivujen muistin prosenttiosuuden, jonka saavuttaessa on käynnistettävä likaisten sivujen taustahuuhtelu levylle. Ennen kuin tämä prosentti on saavutettu, sivuja ei huuhdeta levylle. Ja kun nollaus alkaa, se toimii taustalla keskeyttämättä käynnissä olevia prosesseja.
Toinen parametri (vm.dirty_ratio) määrittää prosenttiosuuden muistista, jonka likaiset sivut voivat varata ennen kuin pakotettu salama alkaa. Kun tämä kynnys saavutetaan, kaikista prosesseista tulee synkronisia (estetty) eivätkä ne saa jatkaa toimintaansa ennen kuin niiden pyytämä I/O-toiminto on todella suoritettu ja tiedot ovat levyllä. Suurella I/O-kuormalla tämä aiheuttaa ongelman, koska tiedon välimuistia ei ole ja kaikki I/O:ta suorittavat prosessit estetään odottamassa I/O:ta. Tämä johtaa suureen määrään ripustettuja prosesseja, suurta kuormitusta, järjestelmän epävakautta ja huonoa suorituskykyä.
Näiden parametrien arvojen pienentäminen aiheuttaa sen, että tiedot huuhdellaan levylle useammin eikä niitä tallenneta RAM-muistiin. Tämä voi auttaa paljon muistia vaativissa järjestelmissä, joissa on normaalia huuhdella 45–90 Gt sivuvälimuistia levylle, mikä johtaa valtavaan viiveeseen käyttöliittymäsovelluksissa, mikä vähentää yleistä reagointikykyä ja interaktiivisuutta.
"1" > /proc/sys/vm/pagecache
Sivuvälimuisti on välimuisti, joka tallentaa tietoja tiedostoista ja suoritettavista ohjelmista, eli nämä ovat sivuja, joilla on tiedostojen tai estolaitteiden todellinen sisältö. Tätä välimuistia käytetään vähentämään levylukujen määrää. Arvo "1" tarkoittaa, että välimuisti käyttää 1 % RAM-muistista ja levyltä luetaan enemmän kuin RAM-muistista. Tätä asetusta ei tarvitse muuttaa, mutta jos olet vainoharhainen sivun välimuistin hallinnassa, voit käyttää sitä.
"deadline" > /sys/block/sdc/queue/scheduler
I/O-ajastin on Linux-ytimen komponentti, joka käsittelee luku- ja kirjoitusjonoja. Teoriassa on parempi käyttää "noop" älykkäälle RAID-ohjaimelle, koska Linux ei tiedä mitään levyn fyysisestä geometriasta, joten on tehokkaampaa antaa ohjaimen, joka tuntee levyn geometrian hyvin, käsitellä pyyntö mahdollisimman nopeasti. Mutta näyttää siltä, että "deadline" parantaa suorituskykyä. Lisätietoja ajoittajista löytyy Linux-ytimen lähdekoodin dokumentaatiosta: linux/Documentation/block/*osched.txt. Ja huomasin myös lukunopeuden lisääntymisen sekatoimintojen aikana (paljon kirjoitusta).
"256" > /sys/block/sdc/queue/nr_requests
Puskurissa olevien I/O-pyyntöjen määrä ennen kuin ne lähetetään ajoittimelle. Joidenkin ohjaimien sisäinen jonokoko (queue_depth) on suurempi kuin I/O-skedoijan nr_requests, joten I/O-ajastimella on vähän mahdollisuuksia priorisoida ja yhdistää pyynnöt oikein. Deadline- ja CFQ-aikatauluttajille on parempi, kun nr_requests on 2 kertaa suurempi kuin ohjaimen sisäinen jono. Kyselyjen yhdistäminen ja uudelleenjärjestäminen auttaa ajoittajaa reagoimaan paremmin raskaassa kuormituksessa.
echo "16" > /proc/sys/vm/page-cluster
Page-cluster-parametri ohjaa sivujen määrää, jotka kirjoitetaan sivuun kerralla. Yllä olevassa esimerkissä arvoksi on asetettu "16", joka vastaa 64 kt:n RAID-raidan kokoa. Tämä ei ole järkevää, kun swapiness = 0, mutta jos asetat swapinessiksi 10 tai 20, tämän arvon käyttäminen auttaa sinua, kun RAID-raidan koko on 64 kt.
blockdev --setra 4096 /dev/<kehittäjän nimi> (-sdb, hdc tai dev_mapper)
Monien RAID-ohjainten oletusarvoiset estolaitteet johtavat usein kauheaseen suorituskykyyn. Yllä olevan vaihtoehdon lisääminen määrittää 4096 * 512 tavun sektorien ennakkoluukun. Ainakin suoratoistooperaatioissa nopeutta lisätään täyttämällä sirulla oleva levyvälimuisti ennakkoluennon kautta sinä aikana, jota ydin käyttää I/O:n valmistelemiseen. Välimuistissa voi olla tietoja, joita pyydetään seuraavan lukemisen aikana. Liian paljon eteenpäin luettavaa voi tappaa satunnaisen I/O:n suurille tiedostoille, jos se käyttää mahdollisesti hyödyllistä levyaikaa tai lataa tietoja välimuistin ulkopuolella.
Alla on muutamia muita suosituksia tiedostojärjestelmätasolla. Mutta niitä ei ole vielä testattu. Varmista, että tiedostojärjestelmäsi tietää raidan koon ja taulukossa olevien levyjen lukumäärän. Esimerkiksi, että tämä on raid5-taulukko, jonka raidan koko on 64 kt ja kuusi levyä (itse asiassa viisi, koska yhtä levyä käytetään pariteettina). Nämä suositukset perustuvat teoreettisiin oletuksiin, ja RAID-asiantuntijat ovat keränneet niitä useista blogeista/artikkeleista.
-> 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))Suurempien tiedostojen kohdalla voit harkita yllä olevien raitakokojen lisäämistä.
VAROITUS Kaikki edellä kuvattu on erittäin subjektiivista tietyntyyppisille sovelluksille. Tämä artikkeli ei takaa parannuksia ilman, että käyttäjä on ensin testannut vastaavia sovelluksia. Sitä tulisi käyttää vain, jos on tarvetta parantaa järjestelmän yleistä reagointikykyä tai jos se ratkaisee nykyiset ongelmat.
Lisämateriaalit:
Lue lisää
Lähde: will.com