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

Cikk
09/02/2024

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.

Feljegyzé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. Számos alkalmazás hasonlóképpen kihasználja ezeknek a paramétereknek a finomhangolását.

`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 mint példa, a javaslat előzménye az volt, hogy vm.dirty_background 1/5 méretre 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 nincs öblítés, amíg a memória nyomása vagy 30 másodperc nem halad át. 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

Ha figyelembe veszi 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 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 várhatók egy nemtuned, írási nehéz, gyorsítótárazott Linux-géptől.

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_ratio vm.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

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