Linux Page Cache Basics

Onder Linux versnelt de Page Cache de toegang tot bestanden op niet-vluchtige opslagmedia. Dit gebeurt omdat, wanneer het voor het eerst leest van of schrijft naar data media zoals harde schijven, Linux ook data opslaat in ongebruikte delen van het geheugen, die fungeert als een cache. Als deze gegevens later opnieuw worden gelezen, kunnen ze snel uit deze cache in het geheugen worden gelezen. Dit artikel geeft waardevolle achtergrondinformatie over deze page cache.

Page Cache or Buffer Cache

De term, Buffer Cache, wordt vaak gebruikt voor de Page Cache. Linux kernels tot en met versie 2.2 hadden zowel een Page Cache als een Buffer Cache. Vanaf kernel 2.4 zijn deze twee geheugens samengevoegd.

Functionele aanpak

Geheugengebruik

Onder Linux wordt het aantal megabytes van het hoofdgeheugen dat momenteel wordt gebruikt voor de paginacache aangegeven in de kolom Cached van het rapport dat wordt geproduceerd door het free -m commando.

# free -m total used free shared buffers cachedMem: 15976 15195 781 0 167 9153-/+ buffers/cache: 5874 10102Swap: 2000 0 1999# 

Schrijven

Als gegevens worden geschreven, worden ze eerst naar de Page Cache geschreven en als een van de vuile pagina’s beheerd. Dirty betekent dat de gegevens in de Page Cache zijn opgeslagen, maar eerst naar het onderliggende opslagapparaat moeten worden geschreven. De inhoud van deze “dirty pages” wordt periodiek (en ook met de systeemaanroepen sync of fsync) naar het onderliggende opslagapparaat overgebracht. Het systeem kan in dit laatste geval een RAID controller zijn of de harde schijf direct.

Het volgende voorbeeld toont de creatie van een 10-megabyte bestand, dat eerst naar de Page Cache zal worden geschreven. Al doende zal het aantal vuile pagina’s worden verhoogd, totdat ze naar de onderliggende solid-state drive (SSD) zijn geschreven, in dit geval handmatig als antwoord op het sync commando.

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

Tot en met versie 2.6.31 van de Kernel: pdflush

Tot en met de 2.6.31 versie van de Linux kernel zorgden de pdflush threads ervoor dat vuile pagina’s periodiek naar het onderliggende opslagapparaat werden geschreven.

Vanaf versie 2.6.32: per-backing-device gebaseerde writeback

Omdat pdflush diverse prestatienadelen had, ontwikkelde Jens Axboe een nieuw, effectiever writeback mechanisme voor Linux Kernel versie 2.6.32.

Deze aanpak biedt threads voor elk apparaat, zoals het volgende voorbeeld van een computer met een SSD (/dev/sda) en een harde schijf (/dev/sdb) laat zien.

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 

Lezen

Bestandsblokken worden niet alleen tijdens het schrijven naar de Page Cache geschreven, maar ook tijdens het lezen van bestanden. Wanneer u bijvoorbeeld een bestand van 100 megabyte twee keer leest, de ene keer na de andere, zal de tweede toegang sneller zijn, omdat de bestandsblokken direct uit de Page Cache in het geheugen komen en niet opnieuw van de harde schijf hoeven te worden gelezen. Het volgende voorbeeld laat zien dat de omvang van de Page Cache is toegenomen nadat een goede, 200-megabyte video is afgespeeld.

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

Als Linux meer geheugen nodig heeft voor normale toepassingen dan er op dit moment beschikbaar is, worden delen van de Page Cache die niet langer in gebruik zijn automatisch verwijderd.

Optimaliseren van de Page Cache

Het automatisch opslaan van bestandsblokken in de Page Cache is over het algemeen heel voordelig. Sommige gegevens, zoals logbestanden of MySQL dump-bestanden, zijn vaak niet meer nodig als ze eenmaal zijn geschreven. Daarom gebruiken zulke bestandsblokken vaak onnodig ruimte in de Page Cache. Andere blokken, waarvan de opslag voordeliger zou zijn, kunnen voortijdig uit de Page Cache worden verwijderd door nieuwere log-bestanden of MySQL.

Periodieke uitvoering van logrotate met gzip compressie kan helpen met log-bestanden, enigszins. Wanneer een logbestand van 500 megabyte wordt gecomprimeerd tot 10 megabyte door logrotate en gzip, wordt het oorspronkelijke logbestand ongeldig, samen met zijn cache-ruimte. 490 megabytes in de Page Cache komen dan beschikbaar door dit te doen. Het gevaar dat een alsmaar groeiend logbestand meer bruikbare bestandsblokken uit de Page Cache verdringt, wordt daardoor kleiner.

Het is dus volkomen redelijk, als sommige applicaties bepaalde bestanden en bestandsblokken normaal gesproken niet in de cache opslaan. Er is al een dergelijke patch beschikbaar voor rsync.

Aanvullende informatie

• Page Cache, de affaire tussen geheugen en bestanden (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)