Linux Page Cache Basics

Under Linux påskyndar Page Cache många åtkomster till filer på icke-flyktig lagring. Detta sker eftersom Linux, när det först läser från eller skriver till datamedier som hårddiskar, också lagrar data i oanvända områden i minnet, vilket fungerar som en cache. Om dessa data läses igen senare kan de snabbt läsas från denna cache i minnet. Den här artikeln kommer att ge värdefull bakgrundsinformation om denna sidcache.

Sidcache eller buffertcache

Termen buffertcache används ofta för sidcache. Linuxkärnor fram till version 2.2 hade både en Page Cache och en Buffer Cache. Från och med kärnan i version 2.4 har dessa två cacher kombinerats. Idag finns det bara en cache, Page Cache.

Funktionellt tillvägagångssätt

Minnesanvändning

Under Linux anges antalet megabyte huvudminne som för närvarande används för Page Cache i kolumnen Cached i den rapport som produceras av kommandot free -m.

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

Skrivning

Om data skrivs skrivs de först till Page Cache och hanteras som en av dess smutsiga sidor. Dirty innebär att data lagras i Page Cache, men måste först skrivas till den underliggande lagringsenheten. Innehållet i dessa smutsiga sidor överförs regelbundet (liksom med systemanropen sync eller fsync) till den underliggande lagringsenheten. Systemet kan i detta sista fall vara en RAID-kontroller eller hårddisken direkt.

Nedan följer ett exempel som visar skapandet av en fil på 10 megabyte, som först skrivs till Page Cache. Antalet smutsiga sidor kommer att öka genom att göra så, tills de har skrivits till den underliggande SSD-enheten (Solid State Drive), i detta fall manuellt som svar på sync-kommandot.

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

Till och med version 2.6.31 av kärnan: pdflush

Till och med version 2.6.31-versionen av Linuxkärnan såg pdflush-trådarna till att smutsiga sidor periodiskt skrevs till den underliggande lagringsenheten.

Från och med version 2.6.32: per-backing-device-baserad writeback

Då pdflush hade flera prestandanackdelar, utvecklade Jens Axboe en ny, effektivare writeback-mekanism för Linuxkärnans version 2.6.32.

Detta tillvägagångssätt ger trådar för varje enhet, vilket följande exempel på en dator med en SSD (/dev/sda) och en hårddisk (/dev/sdb) visar.

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 

Läsning

Filblock skrivs till Page Cache inte bara vid skrivning, utan även vid läsning av filer. När du till exempel läser en fil på 100 megabyte två gånger, den ena efter den andra, kommer den andra åtkomsten att vara snabbare, eftersom filblocken kommer direkt från Page Cache i minnet och inte behöver läsas från hårddisken igen. Följande exempel visar att storleken på Page Cache har ökat efter att en bra video på 200 megabyte har spelats upp.

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

Om Linux behöver mer minne för normala tillämpningar än vad som för närvarande finns tillgängligt, raderas områden i Page Cache som inte längre används automatiskt.

Optimering av Page Cache

Automatiskt lagring av filblock i Page Cache är generellt sett ganska fördelaktigt. Vissa data, till exempel loggfiler eller MySQL-dumpfiler, behövs ofta inte längre när de väl har skrivits. Därför använder sådana filblock ofta utrymme i Page Cache i onödan. Andra filblock, vars lagring skulle vara mer fördelaktig, kan raderas i förtid från Page Cache av nyare loggfiler eller MySQL.

Periodiskt utförande av logrotate med gzip-komprimering kan hjälpa till med loggfiler, något. När en loggfil på 500 megabyte komprimeras till 10 megabyte av logrotate och gzip blir den ursprungliga loggfilen ogiltig tillsammans med dess cacheutrymme. 490 megabyte i Page Cache blir då tillgängliga genom att göra detta. Risken för att en ständigt växande loggfil ska tränga undan mer användbara filblock från Page Cache minskar därmed.

Det är därför helt rimligt att vissa program normalt inte lagrar vissa filer och filblock i cacheminnet. Det finns redan en sådan patch tillgänglig för rsync.

Tillkommande information

• 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)