Linux fájlrendszer cache működése?

Fórumok

Nemrég kellett egy szerver terhelésén csökkentenem. A szerver az esetek 95%-ban lemez olvasási műveletre várakozott. Fura, hogy bár a 16GB memóriából 8GB mindig szabadon volt, a fájlrendszer cache ebből mégis maximum csak 4GB-ot használt. Ráadásul ez a 4GB is volt, hogy visszaesett 3GB-ra.

Ezek után nem értem, hogyan működik a fájlrendszer cache.

Az eddig összeszedett információim alapján a linux minden fel nem használt szabad memóriát a fájlrendszer gyorsítására használ. Ez esetben azonban nem értem, hogy gyakran használt fájlok esetében miért várakozhat olvasásra a rendszer, ha még 4GB semmire sem használt szabad memória van?

Egy helyen azt írták, a fájlrendszer gyorsítás a page cache használatával történik. Ez azt jelenti, hogy swapoff esetén nincs fájlrendszer cache sem? Ez eléggé valószínűtlenül hangzik.

- Tudja valaki pontosan, hogyan működik a fájlrendszer cache a linuxban? Függ ez egyáltalán magától a fájlrendszertől? (Konkrétan most ext4-en kerültem szembe a problémával.) Ha igen, van ebben erős fájlrendszer?

- A fájlrendszer cache függetlenül működik a swap-től?

- Van olyan program linux alá, ami a fenti esetben a semmire sem használt 4GB memóriát felhasználva képes lett volna tovább csökkenteni az IO műveletek számát?

Hozzászólások

Egy helyen azt írták, a fájlrendszer gyorsítás a page cache használatával történik. Ez azt jelenti, hogy swapoff esetén nincs fájlrendszer cache sem? Ez eléggé valószínűtlenül hangzik.

BIztos, ugyanis VPSeinken nincsen swap viszont a FS cache meg fullon van. 

Bár ennyire nem értek az FS cachehez, de nem elképzelhető, hogy csak azzal a pár G vel dolgozik és ezért nem is töltődik fel az cache? pl ha másolsz magadnak fájlokat ide oda mondjuk annyi G méretben amekkora a ram, akkor azért illene feltöltődnie a cachenek. 

Pl.: vannak linux alapú network szerverek, ahol van 16G ram, de az fs cache jó ha 1-2G, gondolom ennyi a /var/log változása.

Fedora 31, Thinkpad x220

Ha zfs-t használsz, az az összes memóriát le fogja foglalni. :)

Szerkesztve: 2019. 12. 05., cs - 13:03

Kéne ide egy `dstat -pcmdv` kimenet 1 percre.

5 másodperces mintavétellel:

---procs--- ----total-cpu-usage---- ------memory-usage----- -dsk/total- ---procs--- ------memory-usage----- ---paging-- -dsk/total- ---system-- ----total-cpu-usage----
run blk new|usr sys idl wai hiq siq| used  buff  cach  free| read  writ|run blk new| used  buff  cach  free|  in   out | read  writ| int   csw |usr sys idl wai hiq siq
  0   0  11|  3   1  93   3   0   0|4163M  642M 1922M 9273M| 634k  274k|  0   0  11|4163M  642M 1922M 9273M|1845B 1982B| 634k  274k|1198  3358 |  3   1  93   3   0   0
0.4 2.2  24|  4   2  72  22   0   0|4171M  643M 1937M 9249M|3236k  559k|0.6 2.4  24|4171M  643M 1937M 9249M|4096B    0 |3245k  559k|1801  3986 |  4   2  72  22   0   0
0.6 1.0 2.0|  5   1  84   9   0   0|4201M  644M 1944M 9211M|1508k  758k|0.6 1.0 2.0|4201M  644M 1944M 9211M|  18k    0 |1499k  758k|1525  3372 |  5   1  84   9   0   0
0.2 0.4 1.8|  2   1  93   5   0   0|4194M  644M 1947M 9214M| 747k  841k|0.2 0.4 1.8|4194M  644M 1947M 9214M|   0     0 | 747k  841k|1152  2529 |  2   1  93   5   0   0
0.2 0.2 1.6|  2   1  94   4   0   0|3940M  645M 1950M 9466M| 490k  446k|0.2 0.2 1.6|3940M  645M 1950M 9466M|4096B    0 | 490k  446k|1266  2250 |  2   1  94   4   0   0
0.4 0.4 2.4|  2   1  93   4   0   0|3942M  645M 1954M 9459M|1091k  293k|0.6 0.4 2.4|3942M  645M 1954M 9459M|9830B    0 |1106k  293k|1706  3542 |  2   1  93   4   0   0
0.2   0 3.2|  3   1  90   6   0   0|3953M  645M 1958M 9444M| 826k  369k|0.4   0 3.2|3953M  645M 1958M 9444M|  36k    0 | 817k  369k|1604  2876 |  3   1  90   6   0   0
0.2 1.4 9.8|  4   3  82  11   0   1|4073M  645M 1854M 9429M|1440k  634k|  0 1.6 9.8|4073M  645M 1854M 9429M|9830B 8192B|1435k  634k|2764  3963 |  4   3  82  11   0   1
0.2 2.2 3.8|  3   2  66  28   0   1|4059M  645M 1823M 9473M|2220k  546k|  0 2.2 3.8|4059M  645M 1823M 9473M|  76k 4096B|2220k  546k|2323  3794 |  3   2  66  28   0   1
0.8 3.0 2.4|  4   2  69  23   0   1|4044M  645M 1822M 9489M|2146k  564k|0.2 3.2 2.4|4044M  645M 1822M 9489M|  14k 3277B|2146k  564k|2198  4297 |  4   2  69  23   0   1
0.6 0.6 2.8|  2   1  89   7   0   0|3949M  646M 1828M 9577M|1310k 1066k|0.6 0.8 2.8|3949M  646M 1828M 9577M|2458B    0 |1310k 1066k|1561  3122 |  2   1  89   7   0   0
0.4 1.2 1.8|  1   1  93   4   0   0|3924M  646M 1832M 9599M| 790k  262k|0.4 1.2 1.8|3924M  646M 1832M 9599M|9011B    0 | 790k  262k|1273  2848 |  1   1  93   4   0   0
0.8 0.6 1.6|  3   1  88   8   0   0|3929M  647M 1838M 9585M|1605k  617k|0.2 0.6 1.6|3929M  647M 1838M 9585M|  11k    0 |1605k  617k|1765  4095 |  3   1  88   8   0   0

Ez esetben azonban nem értem, hogy gyakran használt fájlok esetében miért várakozhat olvasásra a rendszer, ha még 4GB semmire sem használt szabad memória van?

 

Várakozhat pl. azért is mert konkurens hozzáférés van és a file(ok) exkluziv lockot kapnak használatkor. Ilyenkor bután nézés van, amíg az előző használó be nem fejezi azt, amit csinál. Lehet tudni, mik várakoznak ilyenkor?

Általában ezek php-fpm processzek, de messze nem kizárólagosan. Inkább úgy tűnt, bármi lehet, ami gyakran fut. Például a háttérben percenként futó, minimális erőforrást használó perl script is, ami szintén csak olvas és ellenőriz. Ez sem lock-kol fájlokat. Érzetre olyan, hogy bármi, ami fájl olvasási műveletet igényel.

Baloon driver nem kavar be esetleg?

Újabb tapasztalat, ami után még kevésbé értem, hogyan is működik a fájlrendszer cache.

Egy frissen konfigurált webkiszolgálón 16GB memóriából kb 14GB a fájlrendszer cache, és a szabad memória 200MB körüli.

Azonban ahogy egyre több kiszolgálandó domain kerül a szerverre, egyre nő a szabad memória értéke. Kb 80 domain után a szabad memória ezen a szerveren is elérte a 9GB-ot, és a fájlrendszer cache mérete 14GB-ról visszaesett 4-5GB-ra.

???