Le noyau Linux ne cesse d’être utilisé dans des applications professionnelles diverses grâce à sa souplesse et ses performances. Un de ses points forts, c’est sa capacité à exploiter toute la mémoire mise à disposition pour accélérer les IO et l’accès aux fichiers lorsque les applications ne consomment pas tout. Voici ce qu’il faut savoir sur le buffer et le cache.

Voir l’utilisation mémoire

Aperçu par htop

Le programme htop  est une amélioration de top , avec comme principal avantage une ergonomie améliorée et une meilleure lisibilité des ressources système. Sur le screenshot ci-dessous, on peut voire la charge processeur sur 24 cœurs, ainsi que l’utilisation mémoire (Mem) et de la partition d’échange (Swp).

L'utilisation mémoire vue par htop

L’utilisation mémoire vue par htop

  • En vert, nous avons la mémoire consommée par les processus lancés par le noyau et par les utilisateurs
  • En bleu, nous avons les buffers IO
  • En jaune, nous avons le cache de fichiers

La différence entre les buffers IO et le cache de fichiers n’est pas évidente à comprendre. Les buffers IO sont des fragments de données qui sont traitées par le noyau lors de l’utilisation de périphériques divers : disque dur, réseau, clé USB, lecteur cd-rom, etc. Le cache de fichiers consiste en des fichiers entiers qui sont souvent lus par le système, et que le noyau choisir de stocker en mémoire pour un accès plus rapide.

 

L’utilisation mémoire vue par free

La commande free permet d’afficher l’utilisation mémoire chiffrée. Voici la sortie qui correspond à la copie d’écran htop ci-dessus.

On retrouve 23213 Mo utilisés par les applications (colonne used), 197 Mo utilisés par les buffers et 23616 Mo de cache de fichiers.

 

Agir sur la mise en cache des fichiers

Savoir si un fichier est en cache

Lors d’opérations répétitives, il est courant qu’une tâche prenne plus de temps lors de son premier lancement, que pour les lancements suivants. Cela peut être du à la mise en cache des fichiers qui est opérée par le noyau dans le but d’accélérer tout ce qui est possible.

Vient alors une question naturelle : est-ce que le fichier X ou Y est mis en cache, et dois-je attendre un gain de performances par sa mise en cache ?

Je ne connais pas d’outil par défaut GNU/Linux qui donne cette information, mais il existe le projet linux-ftools dont le code source est hébergé chez Google Code. Une fois compilé, ce projet fournit les exécutables linux-fincore , linux-fadvise  et linux-fallocate .

Pour commencer, c’est avec linux-fincore que l’on peut savoir si un fichier a été mis en cache. Voici un exemple juste après la compilation de linux-ftools. On peut voir que les fichiers source ont bien été mis en cache pour accélérer cette compilation et la suivante, s’il devait y en avoir une (utilisez l’ascenseur horizontal pour voir les colonnes).

Le programme linux-fadvise permet de donner des indications au noyau sur la manière dont tel ou tel fichier va être utilisé. Enfin, linux-fallocate semble être un clone de fallocate qui permet de créer un fichier avec une taille donnée, même volumineuse, en un rien de temps.

 

Influencer la mise en cache des fichiers

Pour configurer un serveur « aux petits oignons », on peut vite être tenté d’influencer le noyau pour forcer la mise en cache d’un fichier. Pour cela, le programme linux-fadvise permet de donner des « conseils » au noyaux pour retirer un fichier du cache ou peser pour sa mise en cache.

Encore plus brutal, le programme vmtouch permet de mettre un fichier en mémoire tout restant en tâche de fond pour veiller à ce que le fichier reste verrouillé en mémoire.

Lorsqu’il est lancé sans options, vmtouch ressemble fort à linux-fincore. Voici la sortie écran de chacun de ses programmes sur un exécutable fraîchement compilé, c’est justement l’exécutable « vmtouch ».

On peux voir que 17 pages mémoires (68 Ko) sont consacrées à la mise en mémoire de cet exécutable.

Pour le faire tourner en tant que daemon qui verrouille un fichier en mémoire, voici la commande. Un possibilité tout à fait intéressante est de spécifier à vmtouch un répertoire complet.

Ces deux outils sont polyvalents, il permettent de mettre en mémoire n’importe quel fichier, quel que soit son type.

Vidage du cache de fichiers

Une petite commande concise comme on les aime pour vider le cache de fichiers. Après cela, plus de zone jaune dans l’occupation mémoire vue par htop.

Cette commande n’aura pour effet que de dégrader les performances de lecture des fichiers qui étaient en cache. Cela sera utile notamment pour benchmarker des processus (comme une compilation) de manière répétable, sans que le cache ne vienne perturber les résultats.

Augmentation du cache de fichiers

Pour augmenter la proportion de cache des fichiers par rapport à l’utilisation mémoire par les processus, il suffit de s’abstenir de lancer des processus consommateurs. Dans htop cela se traduira par une barre jaune qui tend vers 100%. C’est une situation couramment rencontrée sur les serveurs de fichiers.

Il existe également un levier pour diminuer sa consommation mémoire en compressant les pages mémoire, voir mon article sur les optimisations mémoire sous Linux.

Les services d’accélération d’exécutables

Nous rentrons là dans une autre catégorie d’outils, les logiciels qui sont prévus pour mettre des fichiers binaires (ou des librairies partagées) en mémoire dans le but d’accélérer leur lancement. Bien entendu, linux-fadvise et vmtouch peuvent être utilisés dans ce sens mais il existe des outils moins minimalistes et plus adaptés à cette tâche.

memlockd

Le service memlockd a une action ciblée sur trois types de fichiers : les exécutables, leurs librairies linkées, et les fichiers de configuration. Le but est d’accélérer la réactivité de certaines applications.

Le fichier de configuration se situe dans /etc/memlockd.cfg et sa syntaxe est plutôt simple.

  • Le préfixe + signifie : l’exécutable et ses librairies dynamiques.
  • Le préfixe ? signifie : si ce fichier existe, et ne pas râler si ce n’est pas le cas.
  • Le préfixe % signifie : inclure un fichier quelconque ou un répertoire complet (un seul niveau de récursion). Prévu à l’origine pour les fichiers de configuration.

Selon son développeur, memlockd permettrait d’améliorer le comportement des machines aux attaques DDos en incluant les fichiers nécessaires au login en mémoire. Le fichier de configuration par défaut vise en effet à rendre le login plus réactif.

preload

Preload est un service qui se veut intelligent, il analyse le comportement de l’utilisateur pour comprendre tout seul les fichiers qui ont intérêt à être mis en mémoire. L’idée est bonne, essentiellement pour les postes de travail qui se verront optimisés en fonction de l’utilisation du moment.

ureadahead

Ce service est un peut particulier, ureadahead ne sert qu’à accélérer la phase de démarrage de l’ordinateur en mettant en mémoire les fichiers avant que la procédure de démarrage ne les demande. On appelle cela le « cache warmup », littéralement « préchauffage du cache ».

Cela est à différentier de readahead, qui est un paramètre que l’on retrouve sur les systèmes de fichiers, et qui permet de lire depuis le disque dur des portions du fichier en avance sur la zone requise à l’instant, afin d’améliorer les performances globales.

Conclusion

Tout cela est passionnant, mais s’il y a bien une chose que j’ai apprise à l’usage, c’est qu’il ne sert à rien de vouloir forcer le noyau à mettre des fichiers en cache. En effet, il est tellement bien conçu que la plupart du temps, les fichiers auxquels vous pensez sont déjà en mémoire, et le reste du temps c’est probablement vous qui avez tort de mettre tel ou tel fichier en cache.

Néanmoins, ce sont des éléments que tout administrateur système devrait connaître pour mieux comprendre et anticiper le comportement de l’OS, notamment lorsqu’on fait face à des écarts de performances entre deux exécutions d’une même action.