Principes de base du cache de page Linux

Sous Linux, le cache de page accélère de nombreux accès aux fichiers sur un stockage non volatile. Cela se produit parce que, lorsqu’il lit ou écrit pour la première fois sur des supports de données comme les disques durs, Linux stocke également des données dans des zones inutilisées de la mémoire, ce qui agit comme un cache. Si ces données sont relues ultérieurement, elles peuvent être lues rapidement à partir de ce cache en mémoire. Cet article fournira des informations de base précieuses sur ce cache de page.

Cache de page ou cache tampon

Le terme, cache tampon, est souvent utilisé pour le cache de page. Les noyaux Linux jusqu’à la version 2.2 disposaient à la fois d’un cache de page et d’un cache tampon. À partir du noyau 2.4, ces deux caches ont été combinés. Aujourd’hui, il n’y a qu’un seul cache, le Page Cache.

Approche fonctionnelle

Utilisation de la mémoire

Sous Linux, le nombre de mégaoctets de mémoire principale actuellement utilisés pour le cache de page est indiqué dans la colonne Cached du rapport produit par la commande free -m.

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

Ecriture

Si des données sont écrites, elles sont d’abord écrites dans le cache de page et gérées comme l’une de ses pages sales. Sale signifie que les données sont stockées dans le Page Cache, mais qu’elles doivent d’abord être écrites sur le périphérique de stockage sous-jacent. Le contenu de ces pages sales est transféré périodiquement (ainsi qu’avec les appels système sync ou fsync) vers le périphérique de stockage sous-jacent. Le système peut, dans ce dernier cas, être un contrôleur RAID ou le disque dur directement.

L’exemple suivant montrera la création d’un fichier de 10 mégaoctets, qui sera d’abord écrit dans le cache de pages. Le nombre de pages sales sera augmenté en procédant ainsi, jusqu’à ce qu’elles aient été écrites sur le lecteur à semi-conducteurs (SSD) sous-jacent, dans ce cas manuellement en réponse à la commande sync.

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

Jusqu’à la version 2.6.31 du noyau : pdflush

Jusqu’à la version 2.6.31 du noyau Linux, les threads pdflush garantissaient que les pages sales étaient périodiquement écrites sur le périphérique de stockage sous-jacent.

A partir de la version 2.6.32 : writeback basé sur chaque périphérique de stockage

Puisque pdflush présentait plusieurs inconvénients en termes de performances, Jens Axboe a développé un nouveau mécanisme de writeback plus efficace pour la version 2.6.32 du noyau Linux.

Cette approche prévoit des threads pour chaque périphérique, comme le montre l’exemple suivant d’un ordinateur avec un SSD (/dev/sda) et un disque dur (/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 

Lecture

Les blocs de fichiers sont écrits dans le cache de page non seulement pendant l’écriture, mais aussi pendant la lecture des fichiers. Par exemple, lorsque vous lisez un fichier de 100 mégaoctets deux fois, l’une après l’autre, le deuxième accès sera plus rapide, car les blocs de fichiers proviennent directement du Page Cache en mémoire et ne doivent pas être lus à nouveau sur le disque dur. L’exemple suivant montre que la taille du Page Cache a augmenté après la lecture d’une bonne vidéo de 200 mégaoctets.

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

Si Linux a besoin de plus de mémoire pour les applications normales que ce qui est actuellement disponible, les zones du Page Cache qui ne sont plus utilisées seront automatiquement supprimées.

Optimisation du Page Cache

Le stockage automatique de blocs de fichiers dans le Page Cache est généralement assez avantageux. Certaines données, comme les fichiers journaux ou les fichiers de vidage MySQL, ne sont souvent plus nécessaires une fois qu’elles ont été écrites. Par conséquent, ces blocs de fichiers utilisent souvent inutilement de l’espace dans le cache de la page. D’autres blocs de fichiers, dont le stockage serait plus avantageux, pourraient être supprimés prématurément du Cache de la page par des fichiers journaux ou MySQL plus récents.

L’exécution périodique de logrotate avec la compression gzip peut aider les fichiers journaux, quelque peu. Lorsqu’un fichier journal de 500 mégaoctets est compressé en 10 mégaoctets par logrotate et gzip, le fichier journal d’origine devient invalide ainsi que son espace de cache. Ce faisant, 490 mégaoctets dans le cache de la page deviennent disponibles. Le danger qu’un fichier journal en croissance continue déplace des blocs de fichiers plus utiles du Cache de la page est ainsi réduit.

C’est pourquoi il est tout à fait raisonnable, si certaines applications ne stockent normalement pas certains fichiers et blocs de fichiers dans le cache. Il existe déjà un tel correctif disponible pour rsync.

Informations complémentaires

• Cache de page, l’affaire entre la mémoire et les fichiers (Blog)
• État du cache tampon de Linux (Blog)
• Le cache de page Linux et 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)