Unter Linux beschleunigt der Page Cache viele Dateizugriffe auf nichtflüchtigen Speicher. Das liegt daran, dass Linux beim ersten Lesen oder Schreiben von Datenträgern wie Festplatten auch Daten in ungenutzte Bereiche des Speichers ablegt, die als Cache fungieren. Wenn diese Daten später wieder gelesen werden, können sie schnell aus diesem Cache im Speicher gelesen werden. Dieser Artikel liefert wertvolle Hintergrundinformationen zu diesem Seiten-Cache.
Page Cache oder Buffer Cache
Der Begriff Buffer Cache wird oft für den Page Cache verwendet. Linux-Kernel bis zur Version 2.2 hatten sowohl einen Page Cache als auch einen Buffer Cache. Ab dem Kernel 2.4 wurden diese beiden Caches zusammengelegt. Heute gibt es nur noch einen Cache, den Page Cache.
Funktionaler Ansatz
Speicherverbrauch
Unter Linux wird die Anzahl der Megabytes des Hauptspeichers, die derzeit für den Page Cache verwendet werden, in der Spalte Cached des Berichts angezeigt, der mit dem free -m Befehl erstellt wird.
# free -m total used free shared buffers cachedMem: 15976 15195 781 0 167 9153-/+ buffers/cache: 5874 10102Swap: 2000 0 1999#
Schreiben
Wenn Daten geschrieben werden, werden sie zunächst in den Seiten-Cache geschrieben und als eine der Dirty Pages verwaltet. Dirty bedeutet, dass die Daten im Page Cache gespeichert sind, aber zuerst auf das darunter liegende Speichergerät geschrieben werden müssen. Der Inhalt dieser Dirty Pages wird in regelmäßigen Abständen (auch mit den Systemaufrufen sync oder fsync) an das zugrunde liegende Speichergerät übertragen. Das System kann in diesem letzten Fall ein RAID-Controller oder die Festplatte direkt sein.
Das folgende Beispiel zeigt die Erstellung einer 10-Megabyte-Datei, die zunächst in den Page Cache geschrieben wird. Die Anzahl der Dirty Pages wird dadurch erhöht, bis sie auf das darunterliegende Solid-State-Laufwerk (SSD) geschrieben werden, in diesem Fall manuell als Antwort auf den sync-Befehl.
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
Bis zur Version 2.6.31 des Kernels: pdflush
Bis einschließlich der 2.6.31 des Linux-Kernels sorgten die pdflush-Threads dafür, dass schmutzige Seiten periodisch auf das darunter liegende Speichergerät geschrieben wurden.
Ab Version 2.6.32: Rückschreiben pro Speichergerät
Da pdflush einige Leistungsnachteile hatte, entwickelte Jens Axboe für die Linux-Kernel-Version 2.6.32 einen neuen, effektiveren Rückschreibmechanismus.
Dieser Ansatz bietet Threads für jedes Gerät, wie das folgende Beispiel eines Computers mit einer SSD (/dev/sda) und einer Festplatte (/dev/sdb) zeigt.
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
Lesen
Dateiblöcke werden nicht nur beim Schreiben, sondern auch beim Lesen von Dateien in den Page Cache geschrieben. Wenn Sie zum Beispiel eine 100-Megabyte-Datei zweimal hintereinander lesen, ist der zweite Zugriff schneller, weil die Dateiblöcke direkt aus dem Page Cache in den Speicher kommen und nicht noch einmal von der Festplatte gelesen werden müssen. Das folgende Beispiel zeigt, dass sich die Größe des Page Cache nach dem Abspielen eines guten, 200 Megabyte großen Videos vergrößert hat.
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:~$
Wenn Linux für normale Anwendungen mehr Speicher benötigt, als gerade zur Verfügung steht, werden nicht mehr benötigte Bereiche des Page Cache automatisch gelöscht.
Optimierung des Page Cache
Das automatische Speichern von Dateiblöcken im Page Cache ist in der Regel recht vorteilhaft. Einige Daten, wie Log-Dateien oder MySQL-Dump-Dateien, werden oft nicht mehr benötigt, wenn sie einmal geschrieben wurden. Daher verbrauchen solche Dateiblöcke oft unnötig Platz im Page Cache. Andere Dateiblöcke, deren Speicherung vorteilhafter wäre, können durch neuere Logdateien oder MySQL vorzeitig aus dem Page Cache gelöscht werden.
Die regelmäßige Ausführung von logrotate mit gzip-Kompression kann bei Logdateien etwas helfen. Wenn eine 500 Megabyte große Logdatei durch logrotate und gzip auf 10 Megabyte komprimiert wird, wird die ursprüngliche Logdatei mitsamt ihrem Cache-Speicherplatz ungültig. Dadurch werden 490 Megabyte im Page Cache frei. Die Gefahr, dass eine ständig wachsende Logdatei sinnvollere Dateiblöcke aus dem Page Cache verdrängt, wird dadurch verringert.
Daher ist es durchaus sinnvoll, wenn manche Anwendungen bestimmte Dateien und Dateiblöcke normalerweise nicht im Cache ablegen würden. Für rsync gibt es bereits einen solchen Patch.
- Der Buffer Cache (Abschnitt 15.3) Seite 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)
- Verbesserung der Linux-Performance durch Erhaltung des Buffer-Cache-Status (insights.oetiker.ch)
Zusätzliche Informationen
- Page Cache, the Affair Between Memory and Files (Blog)
- Linux buffer cache state (Blog)
- Der Linux Page Cache und 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)