Pourquoi vider les caches dans Linux?

Linux/m68k a en fait un bug de kernel qui fait que kswapd devient fou et utilise 100% du CPU (50% s'il y a une autre tâche gourmande en CPU, comme un autobuilder de paquets binaires Debian - vulgo buildd - déjà en cours), ce qui peut (la plupart du temps; pas toujours) être atténué en exécutant cette commande particulière toutes les quelques heures.

Cela étant dit... votre serveur n'est probablement pas un système m68k (Atari, Amiga, Macintosh classique, VME, Q40/Q60, Sun3) ;-)

Dans ce cas, la personne qui a inséré ces lignes a suivi des conseils douteux ou, au mieux, obsolètes, ou a mal compris comment la RAM devrait être utilisée (aujourd'hui, on dit en effet que "la RAM libre est une RAM gaspillée" et suggère la mise en cache), ou a "découvert" que cela "corrige" [sic!] un autre problème ailleurs (et a été trop paresseuse pour chercher une solution appropriée).

Je peux penser à une raison plausible de faire cela dans une tâche cron nocturne.

Sur un grand système, il peut être utile de vider périodiquement les caches afin de supprimer la fragmentation de la mémoire.

Le support transparent des énormes pages du noyau effectue un balayage périodique de la mémoire pour regrouper de petites pages en énormes pages. Dans des conditions dégénérées, cela peut entraîner des pauses du système d'une minute ou deux (j'ai vécu cela sous RHEL6 ; espérons que cela s'est amélioré). Vider les caches peut permettre au balayeur d'énormes pages d'avoir de la place pour travailler.

Vous pourriez faire valoir que c'est une bonne raison de désactiver les énormes pages transparentes ; d'un autre côté, vous pouvez estimer que l'amélioration globale des performances des énormes pages transparentes vaut la peine d'accepter de perdre vos caches une fois par jour.

J'ai pensé à une autre raison pour laquelle vous voudriez le faire, bien que pas dans une tâche cron. Juste avant qu'un système de virtualisation ne migre une machine virtuelle vers un nouveau hardware serait un très bon moment pour le faire. Moins de contenu de mémoire à copier vers le nouvel hôte. Vous devrez éventuellement lire à partir du stockage, bien sûr, mais je prendrais probablement ce compromis.

Je ne sais pas si l'un des logiciels de virtualisation le fait réellement.

Une raison pourrait être que le site exécute une sorte de surveillance, qui vérifie la quantité de RAM libre et envoie un avertissement aux administrateurs lorsque la RAM libre tombe en dessous d'un certain pourcentage. Si cet outil de surveillance est assez stupide pour ne pas inclure le cache dans le calcul de la RAM libre, il pourrait envoyer de faux avertissements ; vider régulièrement le cache pourrait supprimer ces avertissements tout en permettant à l'outil de remarquer quand la RAM "réelle" devient faible.

Bien sûr, dans ce genre de situation, la vraie solution est de modifier l'outil de surveillance pour inclure le cache dans le calcul de la RAM libre ; nettoyer le cache n'est qu'une solution temporaire, et une mauvaise en plus, car le cache se remplira rapidement lorsque les processus accèdent au disque.

Donc même si mon hypothèse est correcte, le nettoyage du cache n'a pas de sens, c'est plutôt une solution temporaire par quelqu'un qui n'est pas assez compétent pour résoudre le problème principal.

Juste pour ajouter mon grain de sel : Le système sait très bien que ces pages mémoire sont des caches, et supprimera autant que nécessaire lorsque une application demande de la mémoire.

Un paramètre pertinent est /proc/sys/vm/swappiness, qui indique au noyau lors des nouvelles allocations de mémoire de préférer supprimer les caches mémoire ou d'échanger les pages de mémoire allouées "inactives".

La question date de 2014, mais comme le problème persiste à ce jour sur certains backends centos 6.8 cachés, il peut toujours être utile pour quelqu'un.

https://github.com/zfsonlinux/zfs/issues/1548 décrit un problème avec zfs. Là, l'espace disque n'est pas libéré pour les fichiers supprimés car si nfs est utilisé par-dessus zfs, les inodes des fichiers ne sont pas supprimés du cache d'inodes du noyau.

Pour citer du fil de discussion sur le bug, behlendorf, le 6 janvier 2015, a écrit :

La spéculation actuelle est que, pour une raison quelconque, le serveur NFS garde une version mise en cache du handle du fichier. Jusqu'à ce que le serveur NFS supprime ce handle de fichier, ZFS ne peut pas supprimer ce fichier. Des tests légers ont montré que le fait de vider les caches sur le serveur entraînera la suppression de cette référence (comme le handle de fichier NFS), à quel moment l'espace est correctement libéré. La pression mémoire peut également entraîner sa suppression.

c'est-à-dire qu'un echo 3 > /proc/sys/vm/drop_caches nocturne est le correctif le plus simple pour ce bug si vous ne souhaitez pas avoir d'arrêt pour restructurer votre zfs.

Donc peut-être pas de gestion administrateur aveugle, mais un assez bon débogage était la raison.