Podstawowe informacje o Page Cache w Linuksie

Z Thomas-Krenn-Wiki
Przejdź do nawigacji Przejdź do wyszukiwania

Page Cache w Linuksie przyspiesza odczyt plików. Realizowane jest to przez Linux, który buforuje przy pierwszym odczycie lub zapisie na urządzenia magazynujące, takie jak HDD, dane dodatkowo w niewykorzystywanym obszarze pamięci RAM. Jeśli dane te są później ponownie czytane to może to zostać szybko przeprowadzone z RAM-u. Artykuł ten zawiera ważne podstawowe informacje o Page Cache.

Page Cache lub Buffer Cache

Często wykorzystywane jest dla Page Cache również pojęcie Buffer Cache. W jądrze Linuksa do wersji 2.2 dostępny był zarówno Page Cache jak i Buffer Cache. Z jądrem 2.4 oba cache zostały połączone. Dzisiaj dostępny jest tylko jeden cache, Page Cache.[1]

Sposób funkcjonowania

Wykorzystanie

W Linuksie polecenie free -m podaje w kolumnie cached ile MB pamięci RAM jest aktualnie wykorzystywane przez Page Cache:

[root@testserver ~]# free -m
             total       used       free     shared    buffers     cached
Mem:         15976      15195        781          0        167       9153
-/+ buffers/cache:       5874      10102
Swap:         2000          0       1999
[root@testserver ~]#

Zapis

Jeżeli dane są zapisywane to najpierw trafiają one do Page Cache i są przechowywane jako Dirty Pages. Dirty, ponieważ te dane znajdują się w Page Cache i muszą jeszcze zostać zapisane na urządzeniu magazynującym. Zawartość Dirty Pages jest regularnie (lub poleceniem systemowym jak sync i fsync) zapisywana na urządzeniu magazynującym. Może to być kontroler RAID lub bezpośrednio dysk.

Następujący przykład pokazuje utworzenie pliku o wielkości 10 MByte, który jest najpierw zapisywany w Page Cache. Objętość Dirty Pages rośnie przez to, aż jak w tym przypadku poleceniem sync zostanie zapisany na SSD:

wfischer@pc:~$ dd if=/dev/zero of=testfile.txt bs=1M count=10
10+0 records in
10+0 records out
10485760 bytes (10 MB) copied, 0,0121043 s, 866 MB/s
wfischer@pc:~$ cat /proc/meminfo | grep Dirty
Dirty:             10260 kB
wfischer@pc:~$ sync
wfischer@pc:~$ cat /proc/meminfo | grep Dirty
Dirty:                 0 kB

do jądra 2.6.31: pdflush

Do włącznie jądra Linuksa 2.6.31 wątki pdflush zapewniały, że Dirty Pages były regularnie zapisywane na urządzeniu magazynującym.

od jądra 2.6.32: Per-backing-device based writeback

Ponieważ pdflush miał pewne wady wydajnościowe Jens Axboe opracował dla jądra Linuksa 2.6.32 nowy efektywniejszy mechanizm writeback.[2]

Dostępne są przy tym wątki dla każdego urządzenia, jak jest to pokazane w następującym przykładzie komputera z jednym dyskiem SSD (/dev/sda) i jednym HDD (/dev/sdb):

root@pc:~# ls -l /dev/sda
brw-rw---- 1 root disk 8, 0 2011-09-01 10:36 /dev/sda
root@pc:~# ls -l /dev/sdb
brw-rw---- 1 root disk 8, 16 2011-09-01 10:36 /dev/sdb
root@pc:~# ps -eaf | grep -i flush
root       935     2  0 10:36 ?        00:00:00 [flush-8:0]
root       936     2  0 10:36 ?        00:00:00 [flush-8:16]

Odczyt

Nie tylko przy zapisie, również przy odczycie dane trafiają najpierw do Page Cache. Jeżeli np. plik o wielkości 100 MB jest dwukrotnie czytany to drugi odczyt jest szybszy, ponieważ jest przeprowadzany bezpośrednio z Page Cache w pamięci RAM i nie musi być czytany z dysku. Następujący przykład pokazuje, że po odtworzeniu filmu o wielkości 200MB wielkość Page Cache'u wzrosła:

user@adminpc:~$ free -m
             total       used       free     shared    buffers     cached
Mem:          3884       1812       2071          0         60       1328
-/+ buffers/cache:        424       3459
Swap:         1956          0       1956
user@adminpc:~$ vlc video.avi
[...]
user@adminpc:~$ free -m
             total       used       free     shared    buffers     cached
Mem:          3884       2056       1827          0         60       1566
-/+ buffers/cache:        429       3454
Swap:         1956          0       1956
user@adminpc:~$

Jeśli Linux potrzebuje więcej RAM-u dla normalnych aplikacji niż obecnie jest dostępnych, to dłużej niewykorzystywane obszary Page Cache'u są automatycznie kasowane.

Optymalizacja Page Cache

Automatyczne buforowanie bloków plików w Page Cache jest często korzystne. Niektóre dane (jak logi lub MySQL-Dumps) często po zapisie nie są więcej potrzebne i zajmują często niepotrzebnie miejsce w Page Cache. Inne dane, których buforowanie przyniosłoby większe korzyści nie mogą przez to zostać zapisane w Page Cache'u.[3]

W przypadku logów pomocnym jest np. regularny Logrotate z kompresją gzip. Jeżeli log o wielkości np. 500 MB przez logrotate i gzip zostanie skompresowany do 10 MB, to wyjściowy log i przez to jego cache'owana kopia stają się nieważne. 490 MB w Page Cache staje się przez to wolne. Zagrożenie, że przez ciągle rosnące logi zostaną "wypchnięte" z Page Cache'u bardziej przydatne dane w ten sposób maleje.

Rozsądnym jest dlatego, aby niektóre aplikacje nie buforowały określonych plików/ bloków plików. Dla rsync-u dostępny jest aktualnie patch. [4]

Odnośniki

  1. Der Buffer-Cache (Kapitel 15.3) Seite 348, Linux-Kernel Handbuch: Leitfaden zu Design und Implementierung von Kernel 2.6, Robert Love, Addison-Wesley, 2005
  2. Linux 2.6. – 32 Per-backing-device based writeback (kernelnewbies.org)
  3. Clearing The Linux Buffer Cache (blog.straylightrun.net, 03.12.2009)
  4. Improving Linux performance by preserving Buffer Cache State (insights.oetiker.ch)

Dalsze informacje

Powiązane artykuły

Odczyt numeru seryjnego serwera Thomas-Krenn w systemie Windows lub Linuksie
Określenie zużycia miejsca z konsoli przez df i du na zamontowanych partycjach w Linuksie
Przywracanie obrazu (ISO) Clonezilli