Pourquoi vider les caches dans Linux?

C'est vieux, et fait référence aux réponses les plus acceptées pour expliquer pourquoi ne pas le faire, mais il y a un endroit où j'ai vu cela comme une exigence à l'intérieur de l'invité : un fournisseur d'hébergement (nom non mentionné) qui propose des VM très bon marché, mais qui semble très surabonner, et utilise cela pour garder leurs systèmes "utilisables", c'est-à-dire que vous n'avez pas un accès très rapide au E/S tout le temps, et ils nettoient les caches pour ne pas faire des choses comme un pilote de mise en ballon. Cela signifie que la plupart des gens n'utilisent qu'une fraction de la RAM allouée, donc en nettoyant les caches (fréquemment) ils gardent l'utilisation réelle de la RAM dans les invités et donc sur l'hôte aussi basse que possible. C'est-à-dire plus de VM, moins de physiques, plus de revenus

Cela peut avoir du sens sur les systèmes NUMA (accès mémoire non uniforme), où, généralement, chaque CPU (socket) peut accéder à toute la mémoire de manière transparente, mais sa propre mémoire peut être accessible plus rapidement que la mémoire d'autres sockets, en association avec des applications HPC parallèles.

De nombreuses applications parallèles simples ont tendance à effectuer des E/S de fichiers à partir d'un seul processus, laissant ainsi, à la sortie, une grande partie de la mémoire sur un seul nœud NUMA allouée au cache de disque, tandis que sur l'autre nœud NUMA, la mémoire est principalement libre. Dans ces situations, puisque le processus de récupération de cache dans le noyau Linux, à ma connaissance, n'est toujours pas conscient de la NUMA, les processus s'exécutant sur le nœud NUMA qui a de la mémoire allouée au cache sont contraints d'allouer de la mémoire sur l'autre nœud NUMA, tant qu'il y a de la RAM libre sur l'autre nœud, tuant ainsi les performances.

Cependant, dans un système HPC, il serait plus sage de nettoyer le cache avant de commencer un nouveau travail d'utilisateur, et non à un moment spécifique avec cron.

Pour les applications non parallèles, ce problème est peu probable de se produire.

Lorsque votre cache de page est assez important (beaucoup plus grand que l'utilisation actuelle de votre swap), et que le swap in et le swap out se font tour à tour, c'est à ce moment-là que vous devez supprimer les caches. J'ai vu des cas où l'utilisation de la mémoire augmentait dans l'un de mes serveurs de base de données MariaDB sous Ubuntu 16.04LTS, et Linux a simplement choisi d'augmenter l'utilisation du swap au lieu de supprimer les caches de pages inutilisées. Les énormes pages transparentes sont déjà désactivées dans mon système car TokuDB l'exigeait. Quoi qu'il en soit, peut-être ce n'est pas un bug, mais le fait que Linux continue de se comporter ainsi est assez déconcertant pour moi. Diverses sources ont indiqué que Linux supprimerait le cache de pages lorsque l'application le demandait :

• https://www.linuxatemyram.com/
• https://www.thomas-krenn.com/en/wiki/Linux_Page_Cache_Basics

Mais la réalité n'est pas si simple. La solution de contournement est soit :

1. Exécuter la suppression du cache périodiquement
2. Exécuter la suppression du cache lorsque nécessaire (surveiller l'activité de swap avec vmstat 1)
3. Demander à Linux de supprimer certains fichiers du cache (comme les fichiers journaux d'apache) en utilisant des utilitaires tels que dd ou python-fadvise. Voir https://unix.stackexchange.com/questions/36907/drop-a-specific-file-from-the-linux-filesystem-cache

Exemple d'exécution de dd :

dd if=/var/log/apache2/access_log.1 iflag=nocache count=0

Exemple d'utilisation de python-fadvise :

pyadvise -d /var/log/apache2/access_log.1

J'ai une machine de bureau avec 16 Go de RAM fonctionnant sur un noyau PAE. Après une heure ou deux, les performances du disque se dégradent considérablement jusqu'à ce que je vide les caches, donc je l'ai simplement mis dans le cron. Je ne sais pas si c'est un problème avec le noyau PAE ou avec l'implémentation du cache qui est si lente s'il y a beaucoup de mémoire.