wikiPodstawowe informacje o Page Cache w Linuksie
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
- ↑ 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
- ↑ Linux 2.6. – 32 Per-backing-device based writeback (kernelnewbies.org)
- ↑ Clearing The Linux Buffer Cache (blog.straylightrun.net, 03.12.2009)
- ↑ Improving Linux performance by preserving Buffer Cache State (insights.oetiker.ch)
Dalsze informacje
- Page Cache, the Affair Between Memory and Files (Blog)
- Linux buffer cache state (Blog)
- The Linux Page Cache and pdflush: Theory of Operation and Tuning for Write-Heavy Loads (Last update 8/08/2007)
- drop_caches (linuxinsight.com)
- Examining Linux 2.6 Page-Cache Performance (linuxinsight.com)
- Page cache (en.wikipedia.org)
