Pourquoi Linux purge-t-il le cache mémoire lorsqu'il est presque plein?

Voici à quoi ressemble le graphique de la mémoire sur un VPS exécutant CentOS avec 512 Mo de RAM et nginx / php-fpm / mysqld servant du contenu (principalement statique) à quelques milliers de visiteurs par jour.

Graphique de mémoire hebdomadaire

(ce sont des jours sur l'axe des x)

Comme vous pouvez le voir, c'est assez agité dans le cache et la zone tampon. Le cache mémoire est purgé à intervalles irréguliers (excluant un travail cron responsable). Il est généralement, mais pas toujours, purgé au point où il ne peut plus grossir. Parfois, il s'efface presque entièrement, à d'autres moments seulement à mi-chemin.

J'essaie de comprendre la logique derrière ces purges. Je m'attendrais à ce que les données de fichiers soient mises en cache beaucoup plus longtemps et je ne vois aucun autre programme utilisant plus de mémoire que d'habitude lorsque le cache de mémoire est effacé.

Est-ce un comportement normal ou manque-t-il quelque chose?

MISE À JOUR: Une mise à niveau de la mémoire semble avoir stabilisé le graphique. Toujours de petites baisses, mais nulle part aussi importantes qu'elles ne l'étaient avant la mise à niveau.

Après la mise à niveau de la mémoire

linux memory cache

— redburn
source

S'agit-il d'un conteneur OpenVZ / Virtuozzo ou d'une vraie VM telle que XEN ou KVM?

— jordanm

Je ne peux pas expliquer ce qu'ils sont, mais j'ai un VPS qui affiche le même comportement. dl.dropbox.com/u/1578899/memory-week.png

— EightBitTony

@jordanm C'est une machine virtuelle basée sur Xen.

— redburn

@EightBitTony Merci pour le partage. Le vôtre semble un peu plus «naturel», mais je vois clairement un modèle similaire (mais peut-être plus prévisible) de gouttes dans le cache mémoire.

— redburn

Je me demandais si Munin 2 représentait / collectait les données suffisamment différemment pour entraîner certaines différences (graphique plus fluide sur le vôtre), mais même le mien montre une baisse au milieu d'un cycle plutôt que quotidiennement. C'est bizarre, c'est sûr.

— EightBitTony

Réponses:

Ça pourrait être beaucoup de choses. Peut-être que l'un des programmes que vous utilisez utilise occasionnellement et brièvement beaucoup de RAM. Si c'est vraiment des semaines sur l'axe des x, vous devez échantillonner à une résolution beaucoup plus élevée (par exemple, une fois par minute ou même une seconde) pour obtenir plus d'informations sur ce qui se passe, ce qui entraîne la suppression du cache. pset la topsortie (y compris la charge moyenne) pendant ce temps serait également utile.

— Jim Paris
source

Oui, je suppose que nous pourrions théoriser qu'un éclatement très court et soudain de l'utilisation de la mémoire qui se produit en une minute environ et qui n'est pas repéré par Munin pourrait vider le cache, qui bien sûr, est repéré parce qu'il persiste.

— EightBitTony

L'en-tête est un peu déroutant, car il affiche en fait une semaine de données, donc ce sont des jours sur le x-as, pas des semaines. Quant à la fréquence des sondages: Munin récupère les données toutes les 5 minutes, et je ne pense pas que cette fréquence puisse être modifiée. J'utilise uniquement nginx, mysql, php-fpm et munin-node. Peut-il avoir quelque chose à voir avec le cache mysql, peut-être?

— redburn

J'avais top (trié par utilisation de la mémoire) écrire sa sortie dans un fichier toutes les 5 secondes, puis j'ai analysé ce fichier et trouvé aucun processus montrant un comportement inhabituel au point où la mémoire cache a soudainement chuté. À moins qu'un processus ne puisse utiliser autant de mémoire et échapper à cette fenêtre de 5 secondes, je ne suis pas convaincu que cela puisse être la cause. Mais s'il n'y a pas de processus en cours d'exécution, quel pourrait-il être?

— redburn

Ce fil est un peu vicié, mais une observation rapide sur la méthodologie: combien un processus contribue au cache de la mémoire système ne sera pas (facilement) reflété en haut , car un processus très actif peut empiler des trucs dans le cache très rapidement sans le sien la mémoire allouée augmente beaucoup. Par exemple, lire un fichier très volumineux en petits morceaux pour la transmission - alors que le processus peut ne jamais utiliser plus de quelques Mo alloués , ces quelques Mo changeront constamment et accumuleront des références dans le cache. Donc, la chose à regarder dans la sortie supérieure serait une accumulation soudaine de temps CPU.

— goldilocks

Cela pourrait également vous intéresser: cognitivedissonance.ca/cogware/plog

— goldilocks

Une raison possible serait qu'un fichier en croissance, comme un journal par exemple, soit supprimé, compressé ou envoyé ailleurs lorsqu'il atteint une taille donnée.

Dans les deux cas, sa taille en cache, éventuellement la totalité s'il n'y a pas de pression mémoire dans votre système d'exploitation, serait libérée du cache dès que le fichier d'origine est supprimé.

— jlliagre
source

Une idée intéressante, mais les fichiers journaux les plus actifs dépassent rarement une taille de fichier de 25 Mo avant leur rotation, et l'utilisation du cache / tampon a tendance à baisser d'environ 200 Mo.

— redburn