Megosztás a következőn keresztül:

Ajánlott eljárások linuxos fájlrendszer-gyorsítótárazáshoz az Azure NetApp Fileshoz

  • Cikk

Ez a cikk az Azure NetApp Files fájlrendszer-gyorsítótárának ajánlott eljárásait ismerteti.

Fájlrendszer-gyorsítótárak

A fájlrendszer gyorsítótárazásával kapcsolatos alábbi tényezőket kell megértenie:

  • A piszkos puffer kiürítése tiszta állapotban hagyja az adatokat a jövőbeli olvasásokhoz, amíg a memóriaterhelés ki nem ürítéshez nem vezet.
  • Az aszinkron kiürítési művelethez három eseményindító van:
    • Időalapú: Amikor egy puffer eléri a 2000-ben meghatározott kort, tisztításra (azaz öblítésre vagy tárolóba írásra) kell megjelölni.
    • Memóriaterhelés: Lásd vm.dirty_ratio | vm.dirty_bytes a részleteket.
    • Bezárás: Egy fájlfogópont bezárásakor a rendszer az összes piszkos puffert aszinkron módon kiüríti a tárolóba.

Ezeket a tényezőket négy horgászat szabályozza. Minden hangolható hangolható dinamikusan és tartósan használatával tuned vagy sysctl a /etc/sysctl.conf fájlban. Ezeknek a változóknak a finomhangolása javítja az alkalmazások teljesítményét.

Megjegyzés:

A cikkben tárgyalt információk a SAS GRID és a SAS Viya ellenőrzési gyakorlatok során derültek ki. Ennek megfelelően a hibák az érvényesítési gyakorlatokból levont tanulságokon alapulnak. Sok alkalmazás hasonló előnyökkel jár ezeknek a paramétereknek a finomhangolásában.

vm.dirty_ratio | vm.dirty_bytes

Ez a két hangolható érték határozza meg, hogy mennyi RAM használható a módosított, de még nem stabil tárterületre írt adatokhoz. Bármelyik is van beállítva, a másikat automatikusan nullára állítja; A RedHat azt tanácsolja, hogy manuálisan állítsa a két tonhalat nullára. A beállítást vm.dirty_ratio (a kettő alapértelmezett értéke) Redhat az operációs rendszertől függően a fizikai memória 20%-ára vagy 30%-ára állítja be, ami jelentős összeg a modern rendszerek memóriaigényét figyelembe véve. A memória méretétől függetlenül a konzisztensebb élmény helyett vm.dirty_ratio érdemes megfontolni a beállítástvm.dirty_bytes. A SAS GRID-szel végzett folyamatos munka például 30 MiB-et határozott meg a legjobb általános vegyes számítási feladatok teljesítményének megfelelő beállításként.

vm.dirty_background_ratio | vm.dirty_background_bytes

Ezek a hibák határozzák meg azt a kiindulópontot, ahol a Linux visszaírási mechanizmus elkezdi kiüríteni a piszkos blokkokat a stabil tárolóba. A redhat alapértelmezés szerint a fizikai memória 10%-a, ami egy nagy memóriarendszerben jelentős mennyiségű adat a kiürítés megkezdéséhez. A SAS GRID használata például korábban az volt, hogy vm.dirty_background a javaslat 1/5 méretű vm.dirty_ratio vagy vm.dirty_bytes. Figyelembe véve, hogy milyen agresszíven van beállítva a beállítás a vm.dirty_bytes SAS GRID-hez, itt nincs konkrét érték beállítva.

vm.dirty_expire_centisecs

Ez a halhatatlanság határozza meg, hogy egy piszkos puffer hány éves lehet, mielőtt aszinkron módon fel kell címkézni. Vegyük például a SAS Viya CAS-számítási feladatát. Egy rövid élettartamú írási-domináns számítási feladat megállapította, hogy ez az érték 300 centiseconds (3 másodperc) értékre való beállítása optimális volt, az alapértelmezett érték 3000 centiseconds (30 másodperc).

A SAS Viya a CAS-adatokat több, egyenként néhány megabájtból álló kis adattömbbe osztja meg. Ahelyett, hogy bezárja ezeket a fájlfogantyúkat, miután adatokat írt az egyes szegmensekre, a fogópontok nyitva maradnak, a benne lévő pufferek pedig az alkalmazás által leképezett memóriát képeznek le. Bezárás nélkül nem lesz kipirulás, amíg a memória nyomása vagy 30 másodperc el nem telik. A memóriaterhelésre való várakozás nem bizonyult optimálisnak, mint a hosszú időzítő lejáratára várva. A SAS GRID-szel ellentétben, amely a legjobb általános átviteli sebességet kereste, a SAS Viya optimalizálni kívánta az írási sávszélességet.

vm.dirty_writeback_centisecs

A kernel öblítőszál felelős a piszkos pufferek aszinkron öblítéséért az egyes öblítési szálak alvó állapotai között. Ez a öblítések között alvással töltött összeget határozza meg. Figyelembe véve a SAS Viya által használt 3 másodperces vm.dirty_expire_centisecs értéket, az SAS ezt 100 centiseconds (1 másodperc) értékre állítja, nem pedig az 500 centiseconds (5 másodperc) alapértelmezett értékre, hogy megtalálja a legjobb általános teljesítményt.

A nemtuned fájlrendszergyorsítótár hatása

Figyelembe véve az alapértelmezett virtuális memóriát és a ram mennyiségét a modern rendszerekben, a visszaírás potenciálisan lelassítja a tárterülethez kötött egyéb műveleteket az adott ügyfél szempontjából, amely ezt a vegyes számítási feladatot hajtja végre. A következő tünetek egy nemtuned, írási nehéz, gyorsítótárazott Linux-géptől várhatók.

  • A címtárlisták ls elég ideig tarthatnak, amíg nem válaszolnak.
  • A fájlrendszer olvasási átviteli sebessége jelentősen csökken az írási átviteli sebességhez képest.
  • nfsiostat a jelentések másodpercek alatt vagy annál nagyobb késéseket írnak.

Ezt a viselkedést csak a vegyes írási terhelésű számítási feladatot végző Linux-gép tapasztalhatja. Emellett a felhasználói élmény csökken az egyetlen tárolási végponthoz csatlakoztatott összes NFS-kötet esetében. Ha a csatlakoztatások két vagy több végpontról származnak, csak a végpontot megosztó kötetek mutatják ezt a viselkedést.

Az ebben a szakaszban ismertetett fájlrendszer-gyorsítótárparaméterek beállítása a problémák megoldásához jelenik meg.

Virtuális memória figyelése

A virtuális memóriával és a visszaírással kapcsolatos teendők megértéséhez vegye figyelembe a következő kódrészletet és kimenetet. A Dirty a rendszerben lévő piszkos memória mennyiségét jelöli, a visszaírás pedig a tárolóba aktívan írt memória mennyiségét jelöli.

# while true; do echo "###" ;date ; egrep "^Cached:|^Dirty:|^Writeback:|file" /proc/meminfo; sleep 5; done

A következő kimenet egy kísérletből származik, ahol a vm.dirty_ratiovm.dirty_background fizikai memória 2%-ának, illetve 1%-ának megfelelő arányt állítottunk be. Ebben az esetben a kiürítés 3,8 GiB-vel kezdődött, amely a 384-GiB memóriarendszer 1%-a. A visszaírás nagyon hasonlított az NFS írási sebességére.

Cons
Dirty:                                    1174836 kB
Writeback:                         4 kB
###
Dirty:                                    3319540 kB
Writeback:                         4 kB
###
Dirty:                                    3902916 kB        <-- Writes to stable storage begins here
Writeback:                         72232 kB   
###
Dirty:                                    3131480 kB
Writeback:                         1298772 kB

Következő lépések