Pod Linuksem, Pamięć Podręczna Strony przyspiesza wiele dostępów do plików na nieulotnej pamięci. Dzieje się tak, ponieważ podczas pierwszego odczytu lub zapisu na nośnikach danych takich jak dyski twarde, Linux przechowuje również dane w nieużywanych obszarach pamięci, co działa jak pamięć podręczna. Jeśli te dane są ponownie odczytywane później, mogą być szybko odczytane z tej pamięci podręcznej. Ten artykuł dostarczy cennych informacji o pamięci podręcznej strony.
Page Cache lub Buffer Cache
Termin, Buffer Cache, jest często używany dla Page Cache. Jądra Linuksa do wersji 2.2 posiadały zarówno Page Cache jak i Buffer Cache. Począwszy od jądra 2.4, te dwie pamięci podręczne zostały połączone. Obecnie istnieje tylko jedna pamięć podręczna, Page Cache.
Podejście funkcjonalne
Użycie pamięci
Pod Linuksem, liczba megabajtów pamięci głównej obecnie używanej dla pamięci podręcznej strony jest wskazana w kolumnie Cached w raporcie utworzonym przez polecenie free -m.
# free -m total used free shared buffers cachedMem: 15976 15195 781 0 167 9153-/+ buffers/cache: 5874 10102Swap: 2000 0 1999#
Pisanie
Jeśli dane są pisane, to najpierw są zapisywane do Page Cache i zarządzane jako jedna z jego brudnych stron. Brudne oznacza, że dane są przechowywane w Page Cache, ale muszą być najpierw zapisane na bazowym urządzeniu pamięci masowej. Zawartość tych brudnych stron jest okresowo przekazywana (jak również za pomocą wywołań systemowych sync lub fsync) do bazowego urządzenia pamięci masowej. W tym ostatnim przypadku może to być kontroler RAID lub bezpośrednio dysk twardy.
Następujący przykład pokaże utworzenie 10-megabajtowego pliku, który najpierw zostanie zapisany w Page Cache. Liczba brudnych stron będzie się zwiększać w ten sposób, dopóki nie zostaną one zapisane na bazowym dysku półprzewodnikowym (SSD), w tym przypadku ręcznie w odpowiedzi na polecenie synchronizacji.
wfischer@pc:~$ dd if=/dev/zero of=testfile.txt bs=1M count=1010+0 records in10+0 records out10485760 bytes (10 MB) copied, 0,0121043 s, 866 MB/swfischer@pc:~$ cat /proc/meminfo | grep DirtyDirty: 10260 kBwfischer@pc:~$ syncwfischer@pc:~$ cat /proc/meminfo | grep DirtyDirty: 0 kB
Do wersji 2.6.31 jądra: pdflush
Do wersji 2.6.31 wersji jądra Linuksa, wątki pdflush zapewniały, że brudne strony były okresowo zapisywane na bazowe urządzenie magazynujące.
Od wersji 2.6.32: per-backing-device based writeback
Ponieważ pdflush miał kilka wad wydajnościowych, Jens Axboe opracował nowy, bardziej efektywny mechanizm zapisu zwrotnego dla jądra Linuksa w wersji 2.6.32.
To podejście zapewnia wątki dla każdego urządzenia, jak pokazuje poniższy przykład komputera z dyskiem SSD (/dev/sda) i dyskiem twardym (/dev/sdb).
root@pc:~# ls -l /dev/sdabrw-rw---- 1 root disk 8, 0 2011-09-01 10:36 /dev/sdaroot@pc:~# ls -l /dev/sdbbrw-rw---- 1 root disk 8, 16 2011-09-01 10:36 /dev/sdbroot@pc:~# ps -eaf | grep -i flushroot 935 2 0 10:36 ? 00:00:00 root 936 2 0 10:36 ? 00:00:00
Odczytywanie
Bloki plików są zapisywane do Page Cache nie tylko podczas pisania, ale także podczas odczytywania plików. Na przykład, gdy czytasz 100-megabajtowy plik dwa razy, jeden po drugim, drugi dostęp będzie szybszy, ponieważ bloki pliku pochodzą bezpośrednio z Page Cache w pamięci i nie muszą być ponownie odczytywane z dysku twardego. Poniższy przykład pokazuje, że rozmiar Page Cache zwiększył się po odtworzeniu dobrego, 200-megabajtowego filmu.
user@adminpc:~$ free -m total used free shared buffers cachedMem: 3884 1812 2071 0 60 1328-/+ buffers/cache: 424 3459Swap: 1956 0 1956user@adminpc:~$ vlc video.aviuser@adminpc:~$ free -m total used free shared buffers cachedMem: 3884 2056 1827 0 60 1566-/+ buffers/cache: 429 3454Swap: 1956 0 1956user@adminpc:~$
Jeśli Linux potrzebuje więcej pamięci dla normalnych aplikacji, niż jest aktualnie dostępne, obszary Page Cache, które nie są już używane, zostaną automatycznie usunięte.
Optymalizacja Page Cache
Automatyczne przechowywanie bloków plików w Page Cache jest generalnie dość korzystne. Niektóre dane, takie jak pliki dziennika lub pliki zrzutu MySQL, często nie są już potrzebne po ich zapisaniu. Dlatego takie bloki plików często niepotrzebnie wykorzystują miejsce w Page Cache. Inne bloki plików, których przechowywanie byłoby bardziej korzystne, mogą być przedwcześnie usunięte z Page Cache przez nowsze pliki logów lub MySQL.
Okresowe wykonywanie logrotate z kompresją gzip może nieco pomóc z plikami logów. Kiedy 500-megabajtowy plik dziennika jest skompresowany do 10 megabajtów przez logrotate i gzip, oryginalny plik dziennika staje się nieważny wraz z jego przestrzenią w pamięci podręcznej. 490 megabajtów w Page Cache stanie się przez to dostępne. Niebezpieczeństwo, że ciągle rosnący plik dziennika wyprze bardziej użyteczne bloki plików z Page Cache jest w ten sposób zredukowane.
Dlatego jest całkowicie rozsądne, jeśli niektóre aplikacje normalnie nie przechowywałyby pewnych plików i bloków plików w cache. Jest już dostępna taka poprawka dla rsync.
- The Buffer Cache (Section 15.3) strona 348, Linux-Kernel Manual: Guidelines for the Design and Implementation of 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)
- Poprawa wydajności Linuksa poprzez zachowanie stanu bufora pamięci podręcznej (insights.oetiker.ch)
Dodatkowe informacje
- Page Cache, the Affair Between Memory and Files (Blog)
- Stan bufora pamięci podręcznej Linuksa (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)