# Linux Page Cache

<div class="vector-body" id="bkmrk-hauptseite%C2%A0%3E%C2%A0server-"><div id="bkmrk-hauptseite%C2%A0%3E%C2%A0server--1"><div id="bkmrk-hauptseite%C2%A0%3E%C2%A0server--2"><div class="subpages"><div id="bkmrk-hauptseite%C2%A0%3E%C2%A0server--3">[Hauptseite](https://www.thomas-krenn.com/de/wiki/Hauptseite "Hauptseite") &gt; [Server-Software](https://www.thomas-krenn.com/de/wiki/Kategorie:Server-Software "Kategorie:Server-Software") &gt; [Linux](https://www.thomas-krenn.com/de/wiki/Kategorie:Linux "Kategorie:Linux") &gt; [Linux-Grundlagen](https://www.thomas-krenn.com/de/wiki/Kategorie:Linux-Grundlagen "Kategorie:Linux-Grundlagen")</div></div></div></div><div id="bkmrk-"></div><div class="mw-body-content"><div class="mw-content-ltr mw-parser-output" dir="ltr" lang="de-x-formal">  
</div></div></div>Der **Page Cache** unter Linux beschleunigt zahlreiche Lese-Zugriffe von Dateien. Dies geschieht, indem Linux Daten beim erstmaligen Lesen von oder Schreiben auf Datenträgern wie Festplatten zusätzlich in **ungenutzten Bereichen des Arbeitsspeichers** cacht. Werden diese Daten später erneut gelesen, können diese schnell aus dem Arbeitsspeicher gelesen werden. Dieser Artikel liefert wertvolle Hintergrundinformationen zum Page Cache.<label class="toctogglelabel" for="toctogglecheckbox"></label>

## <span class="mw-headline" id="bkmrk-page-cache-oder-buff-1">Page Cache oder Buffer Cache</span>

Oft wird für den Page Cache noch der Begriff Buffer Cache verwendet. Bei Linux Kerneln bis Version 2.2 gab es sowohl einen Page Cache, als auch einen Buffer Cache. Mit Kernel 2.4 wurden diese beiden Caches vereint. Heute gibt es nur noch einen Cache, den Page Cache.<sup class="reference" id="bkmrk-%5B1%5D">[<span class="cite-bracket">\[</span>1<span class="cite-bracket">\]</span>](https://www.thomas-krenn.com/de/wiki/Linux_Page_Cache#cite_note-1)</sup>

## <span class="mw-headline" id="bkmrk-funktionsweise-1">Funktionsweise</span>

### <span class="mw-headline" id="bkmrk-auslastung-1">Auslastung</span>

Unter Linux gibt das Kommando `free -m` in der Spalte **cached** an, wieviel MB des Arbeitsspeichers momentan für den Page Cache verwendet werden:

```
[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 ~]# 
```

### <span class="mw-headline" id="bkmrk-schreiben-1">Schreiben</span>

Wenn Daten geschrieben werden, kommen diese zuerst in den Page Cache und werden dort als *Dirty Pages* verwaltet. *Dirty* deshalb, weil diese Daten zwar im Page Cache liegen, aber erst auf das darunterliegende Speichergerät geschrieben werden müssen. Der Inhalt dieser *Dirty Pages* wird regelmäßig (bzw. auch beim Aufruf von Systemcalls wie sync oder fsync) auf das darunterliegende Speichergerät weitergegeben. Dies kann in letzter Instanz etwa ein RAID-Controller oder direkt eine Festplatte sein.

Das folgende Beispiel zeigt die Erstellung einer 10 MByte großen Datei, die zuerst in den Page Cache geschrieben wird. Der Umfang der Dirty Pages steigt dadurch, bis diese in diesem Fall manuell per sync Kommando auf die darunterliegende SSD geschrieben werden:

```
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
```

#### <span class="mw-headline" id="bkmrk-bis-kernel-2.6.31%3A-p-1">bis Kernel 2.6.31: pdflush</span>

Bis inklusive Linux Kernel 2.6.31 sorgten die pdflush Threads dafür, dass Dirty Pages regelmäßig auf die darunterliegenden Speichergeräte geschrieben wurden.

#### <span class="mw-headline" id="bkmrk-ab-kernel-2.6.32%3A-pe-1">ab Kernel 2.6.32: Per-backing-device based writeback</span>

Da pdflush einige Performance-Nachteile hatte, entwickelte Jens Axboe für den [Linux Kernel 2.6.32](https://www.thomas-krenn.com/de/wiki/Neuerungen_im_Linux_Kernel#Kernel_2.6.32 "Neuerungen im Linux Kernel") einen neuen effektiveren writeback Mechanismus.<sup class="reference" id="bkmrk-%5B2%5D">[<span class="cite-bracket">\[</span>2<span class="cite-bracket">\]</span>](https://www.thomas-krenn.com/de/wiki/Linux_Page_Cache#cite_note-2)</sup>

Dabei gibt es nun Threads für jedes Gerät, wie folgendes Beispiel eines Rechners mit einer SSD (/dev/sda) und einer Festplatte (/dev/sdb) zeigt:

```
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]
```

### <span class="mw-headline" id="bkmrk-lesen-1">Lesen</span>

Nicht nur beim Schreiben, auch beim Lesen von Dateien kommen Dateiblöcke in den Page Cache. Wenn Sie z.B. eine 100 MB Datei zweimal hintereinander lesen, so wird der zweite Zugriff schneller sein, da die Dateiblöcke direkt aus dem Page Cache im Arbeitsspeicher kommen und nicht mehr erneut von der Festplatte gelesen werden müssen. Das folgende Beispiel zeigt, dass nach der Wiedergabe eines gut 200 MB großen Videos die Größe des Page Caches angestiegen ist:

```
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:~$
```

Benötigt Linux mehr Arbeitsspeicher für normale Applikationen als aktuell frei ist, werden bereits länger nicht mehr genutzte Bereiche des Page Caches automatisch gelöscht.

## <span class="mw-headline" id="bkmrk-page-cache-optimiere-1">Page Cache optimieren</span>

Das automatische Caching von Dateiblöcken im Page Cache ist meistens sehr vorteilhaft. Manche Daten (etwa Logfiles oder MySQL-Dumps) werden aber oft nach dem Schreiben nicht mehr benötigt. Solche Dateiblöcke belegen also oft unnötig Platz im Page Cache. Andere Dateiblöcke, deren Caching mehr Vorteile bringen würde, fliegen durch die neuen Logfiles oder MySQL aus dem Page Cache hinaus.<sup class="reference" id="bkmrk-%5B3%5D">[<span class="cite-bracket">\[</span>3<span class="cite-bracket">\]</span>](https://www.thomas-krenn.com/de/wiki/Linux_Page_Cache#cite_note-3)</sup>

Bei Logdateien hilft Ihnen hier etwa ein regelmäßiges Logrotate mit gzip Kompromierung. Wenn eine Logdatei mit beispielsweise 500 MB durch logrotate und gzip auf 10 MB komprimiert wird, wird die ursprüngliche Logdatei und somit auch deren Cache ungültig. 490 MB im Page Cache werden dadurch frei. Die Gefahr, dass eine kontinuierlich wachsenende Logdatei dadurch sinnvollere Dateiblöcke aus dem Page Cache "hinausschiebt" sinkt somit.

Es macht also durchaus Sinn, wenn manche Anwendungen bestimmte Dateien/Dateiblöcke gar nicht cachen würden. Für rsync gibt es dazu auch bereits einen Patch.<sup class="reference" id="bkmrk-%5B4%5D">[<span class="cite-bracket">\[</span>4<span class="cite-bracket">\]</span>](https://www.thomas-krenn.com/de/wiki/Linux_Page_Cache#cite_note-4)</sup>