Pourquoi déposer des caches sous Linux?


84

Dans nos serveurs, nous avons l'habitude de jeter des caches à minuit.

sync; echo 3 > /proc/sys/vm/drop_caches

Lorsque je lance le code, il semble libérer beaucoup de mémoire vive, mais est-ce vraiment nécessaire? La RAM libre n'est-elle pas une perte?


62
Trouvez la personne qui a mis cela et demandez-lui pourquoi il l'a fait. Comme vous l'avez bien deviné, il n'y a pas de bonne raison à cela.
Michael Hampton

10
Déboguer le noyau. C'est à peu près ça. Cela ne libère en fait aucune mémoire vive; il supprime les caches, comme son nom l'indique, et réduit donc les performances.
Michael Hampton

28
@ivcode Ensuite, vous devriez rechercher et résoudre le problème avec ce serveur plutôt que d'essayer d'éviter les conditions qui le provoquent. Si ma voiture a calé à chaque fois que j'ai fait un virage serré à droite, éviter les virages serrés à droite est une solution médiocre.
David Schwartz

7
En relation thedailywtf.com/Articles/Modern-Memory-Management.aspx Argumenter fortement c'est une mauvaise idée.
Drunix

7
En relation, et une description utile du "problème": linuxatemyram.com
Bill Weiss

Réponses:


87

Vous êtes 100% correct. Ce n'est pas une bonne pratique pour libérer de la RAM. C’est probablement un exemple d’administration du système culte du fret.


9
+1 pour avoir mentionné Cargo Cult System Administration. Tout administrateur système qui ne connaît pas ce terme et ce qu’il signifie doit être renvoyé.
Tonny

8
@Tonny: Nous serions laissés sans département sysadmin alors :(
PlasmaHH

2
Comme la plupart des êtres humains, j'aime les affirmations concises et assoiffées avec beaucoup d'approbation, mais une citation ou un raisonnement gagnerait le +1 de mon surmoi.
Aaron Hall

2
Expliquez le culte de la cargaison, ainsi que ce qui précède, si cela ne vous dérange pas. Peut-être dans une édition ultérieure? Je retiens toujours mon +1 ...: P
Aaron Hall

2
"Il est possible que si votre application n'utilise pas cette RAM, mais que Linux mette en cache de manière agressive dans sa mémoire et même si l'application a besoin de mémoire, elle ne libère pas une partie de ce cache mais commence plutôt à la permutation." Pas très spécifique. En pratique, la gestion de la mémoire n’est pas parfaite et il est bon d’avoir un bouton à tourner lorsque cette imperfection se manifeste.
Dan Pritts

62

Oui, l'effacement du cache libère de la mémoire RAM, mais le noyau recherche des fichiers sur le disque plutôt que dans le cache, ce qui peut entraîner des problèmes de performances.

Normalement, le noyau efface le cache lorsque la RAM disponible est épuisée. Il écrit fréquemment le contenu sur le disque à l’aide de pdflush.


20
+1 pour expliquer pourquoi c'est une mauvaise idée.
Ogre Psaume 33

35

La raison pour laquelle les caches de ce type sont supprimées est l’analyse comparative des performances de disque, et c’est la seule raison pour laquelle elle existe.

Lorsque vous exécutez un test d'évaluation intensif en E / S, vous voulez vous assurer que les différents paramètres que vous essayez d'essayer sont réellement des E / S sur disque. Linux vous permet donc de supprimer des caches plutôt que de procéder à un redémarrage complet.

Pour citer la documentation :

Ce fichier n'est pas un moyen de contrôler la croissance des différents caches du noyau (inodes, dentries, pagecache, etc.). Ces objets sont automatiquement récupérés par le noyau lorsque la mémoire est nécessaire ailleurs sur le système.

L'utilisation de ce fichier peut entraîner des problèmes de performances. Dans la mesure où il rejette les objets mis en cache, la recréation des objets supprimés peut coûter une quantité importante d'E / S et d'UC, en particulier s'ils étaient fortement utilisés. De ce fait, l'utilisation en dehors d'un environnement de test ou de débogage n'est pas recommandée.


Bien entendu, selon ce que vous essayez de faire, même un redémarrage complet risque de ne pas vider suffisamment le cache du disque.
un CVn

1
"ces objets sont automatiquement récupérés par le noyau lorsque la mémoire est nécessaire", tel est l'objectif de la conception, mais il se peut que ce ne soit pas toujours le comportement réel.
Dan Pritts

@DanPritts Qu'est-ce qui vous fait penser que ce n'est pas le cas?
Joe

2
Le cas évident est lorsque vous souhaitez vider la RAM pour permettre l’allocation de plus d’immenses pages (non transparentes); un autre cas est celui des bugs transparents de la collecte des ordures énormes par énorme page (voir ma réponse / mes commentaires ailleurs sur cette question). Mais mon commentaire était destiné au cas général. Parfois, les utilisateurs du système en savent plus que ceux qui l'ont conçu / mis en œuvre. Souvent, non - c'est ce que leur commentaire essaie de protéger contre. Je suis juste heureux que le
Dan Pritts

26

L'idée de base ici n'est probablement pas si mauvaise (juste très naïve et trompeuse): Il est possible que certains fichiers soient mis en cache, il est très peu probable qu'ils soient accessibles dans un avenir proche, par exemple les fichiers journaux. Ces béliers "dévoreurs", qui devront être libérés ultérieurement si nécessaire par le système d'exploitation, d'une manière ou d'une autre.

En fonction de vos paramètres de swappiness, de modèle d’accès aux fichiers, de modèle d’allocation de mémoire et de nombreuses autres choses imprévisibles, il peut arriver que lorsque vous ne libérez pas ces caches, ils seront ensuite forcés d’être réutilisés, ce qui prend un peu plus de temps que nécessaire. allouer de la mémoire à partir du pool de mémoire inutilisée. Dans le pire des cas, les paramètres swappiness de linux entraîneront l’échange de mémoire programme, car linux pense que ces fichiers risquent davantage d’être utilisés dans un avenir proche que la mémoire programme.

Dans mon environnement, Linux suppose assez souvent que c'est faux, et au début de la plupart des bourses européennes (vers 9 heures, heure locale), les serveurs commenceront à faire des choses qu'ils ne font qu'une fois par jour, en ayant besoin d'échanger de la mémoire qui était auparavant remplacée, car l'écriture Les fichiers journaux, les compresser, les copier, etc. remplissaient le cache au point d’échanger des éléments.

Mais laisser tomber les caches est-il la solution à ce problème? certainement pas. La solution serait de dire à Linux ce qu’il ne sait pas: ces fichiers ne seront probablement plus utilisés. Cela peut être fait par l'application d'écriture en utilisant des éléments tels que posix_fadvise()ou en utilisant un outil de ligne de commande tel que vmtouch(qui peut également être utilisé pour examiner des éléments ainsi que des fichiers en cache).

De cette façon, vous pouvez supprimer des caches les données dont vous n'avez plus besoin et conserver les éléments qui doivent être mis en cache, car lorsque vous supprimez tous les caches, de nombreux éléments doivent être relus à partir du disque. Et cela au pire moment possible: quand il est nécessaire; provoquant des retards dans votre demande qui sont perceptibles et souvent inacceptables.

Ce que vous devriez mettre en place est un système qui surveille vos habitudes d'utilisation de la mémoire (par exemple, si quelque chose est en train de permuter), puis analysez en conséquence et agissez en conséquence. La solution pourrait consister à expulser de gros fichiers en fin de journée à l’aide de vtouch; il pourrait également s'agir d'ajouter plus de RAM, car l'utilisation maximale quotidienne du serveur correspond à cela.


Toutes les applications sur mon serveur fonctionnent sur nohup. Peut-être que nohup.out est en cache et consomme de la mémoire?
ivcode

@ivcode: Cela pourrait être une raison, vérifiez la taille de nohup.out. Utilisez peut-être vmtouch pour déterminer la quantité de données en cache.
PlasmaHH

J'ai un travail cron à cat /dev/null > path/nohup.outtoutes les 15 minutes car nohup.out se développe rapidement. Peut-être que linux est en train de mettre en cache nohup.out même si je l’
efface

5
@ivcode Si vous n'avez pas besoin de la sortie, nohupvous devriez la rediriger vers /dev/null. Il semble que des administrateurs système très inexpérimentés travaillent sur vos systèmes à un moment donné. Voir stackoverflow.com/questions/10408816/… pour savoir comment diriger nohupla sortie vers/dev/null
David Wilkins.

bien que nohup.out soit effacé toutes les 15 minutes, si le processus d'applications est tué pour une raison quelconque, nohup.out sera automatiquement sauvegardé à partir d'un autre script. j'ai essayé vmtouch. c'est un très bon outil
ivcode

16

J'ai constaté que les caches de dépôt étaient utiles lors du démarrage de plusieurs machines virtuelles. Ou tout ce qui utilise de grandes pages, tels que des serveurs de bases de données.

Les grandes pages sous Linux ont souvent besoin de défragmenter la RAM pour trouver 2 Mo de RAM physique contiguë à mettre dans une page. La libération de tout le cache de fichiers rend ce processus très facile.

Mais je suis d'accord avec la plupart des autres réponses en ce qu'il n'y a généralement pas de bonne raison de supprimer le cache de fichiers tous les soirs.


1
J'ai voté pour avoir souligné les préjugés du deuxième ordre concernant les réponses aux caches de dépôt.
Noah Spurrier

1
De plus, dans les applications HPC sur des nœuds à grande mémoire (1 To), la lecture de quelques fichiers volumineux entraîne une grande quantité de mémoire mise en cache. Étant donné que de nombreuses applications HPC exécutent des mallocs de plusieurs centaines de Go, le système peut rester bloqué pendant des heures car les processus de migration déplacent inutilement de minuscules morceaux de mémoire fragmentée sur les nœuds NUMA une fois que le système a atteint la "limite" de mémoire en cache. Pire, rien ne peut être fait en mode utilisateur pour libérer les caches, à moins de tromper le système en allouant tous les minuscules blocs de 2 Mo qu’il peut libérer en même temps, puis en les libérant, ce qui permet à hugepaged defrag et aux applications de fonctionner normalement.
user1649948

+1 La commande pour créer de grandes pages ( sysctl -w vm.nr_hugepages=...) refuse même de fonctionner sauf si je supprime d'abord les caches (Arch linux).
Aleksandr Dubinsky

8

Il est possible que cela ait été institué comme moyen de stabiliser le système alors que personne ne possédait les compétences ou l'expérience nécessaires pour trouver le problème.

Libérer des ressources

Si vous supprimez des caches, certaines ressources seront libérées, mais cela aura pour effet secondaire de forcer le système à travailler plus dur que nécessaire. Si le système est en train de permuter (essayer de lire et d'écrire à partir d'une partition de permutation de disque plus rapidement que ce qu'il est réellement capable de faire), la suppression périodique des caches peut atténuer le symptôme , mais ne fait rien pour remédier à la cause .

Qu'est-ce que manger de la mémoire?

Vous devez déterminer la cause de la consommation de mémoire qui fait que la suppression de caches semble fonctionner. Cela peut être dû à un nombre quelconque de processus serveur mal configurés ou tout simplement mal utilisés. Par exemple, sur un serveur, j'ai constaté une utilisation maximale de la mémoire lorsqu'un site Web de Magento atteignait un certain nombre de visiteurs dans un intervalle de 15 minutes. Cela a été causé par la configuration d'Apache pour permettre à trop de processus de s'exécuter simultanément. Trop de processus, utilisant beaucoup de mémoire (Magento est parfois une bête) = permuter.

Ligne de fond

Ne présumez pas que c'est quelque chose qui est nécessaire. Soyez proactif en découvrant pourquoi il existe, ayez le courage de le désactiver si d’autres le suggèrent, et observez le système - découvrez le véritable problème et corrigez-le.


4

Linux / m68k a en fait un bogue dans le noyau qui rend fou kswapd et consomme 100% de la CPU (50% s’il existe une autre tâche liée à la CPU, comme un paquetage binaire Debian, autobuilder - vulgo buildd - en cours d’exécution), qui peut pas toujours) être atténué en exécutant cette commande particulière toutes les quelques heures.

Ceci é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 mis les lignes a suivi un conseil discutable ou, au mieux, obsolète, ou a eu l’idée de la mauvaise utilisation de la RAM (la pensée moderne dit en effet que «la RAM libre est un gaspillage de RAM» et suggère la mise en cache). , ou "découvert" que cela "corrige" [sic!] un autre problème ailleurs (et était trop paresseux pour rechercher une solution adéquate).


"Un bogue dans le noyau qui rend fou kswapd" - Quel bogue s'agit-il?
Ben

@Ben voir ce fil de discussion (ce message et quelques suivis, dont un qui suppose de deviner d'où il pourrait provenir)
mirabilos

1
Je rencontre un problème similaire (bien que ce soit x86_64) et la seule solution en ce moment consiste à supprimer les caches serverfault.com/questions/740790/…
Fernando

2
@Fernando J'ai aussi un cronjob "drop caches" sur la boîte m68k ☹
mirabilos

3

Une des raisons pourrait être que le site exécute une sorte de surveillance, qui vérifie la quantité de mémoire RAM libre et envoie un avertissement aux administrateurs lorsque la quantité de mémoire RAM libre devient inférieure à un certain pourcentage. Si cet outil de surveillance est suffisamment stupide pour ne pas inclure le cache dans le calcul de la mémoire libre, il peut envoyer de faux avertissements. vider régulièrement le cache pourrait supprimer ces avertissements tout en permettant à l'outil de remarquer le moment où la "vraie" mémoire vive est à l'état bas.

Bien entendu, dans ce genre de situation, la vraie solution consiste à modifier l'outil de surveillance pour inclure le cache dans le calcul de la mémoire RAM libre; Le nettoyage du cache est simplement une solution de contournement, mais également une mauvaise solution, car le cache se remplit rapidement lorsque les processus accèdent au disque.

Ainsi, même si mon hypothèse est vraie, le nettoyage de la mémoire cache n’a pas de sens, c’est plutôt une solution de contournement par quelqu'un qui n’est pas assez compétent pour résoudre le problème principal.


3

Je peux penser à une raison plausible de faire cela dans un cron job nocturne.

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

La prise en charge transparente d’énormes pages par le noyau effectue un balayage périodique de la mémoire afin de fusionner les petites pages en pages énormes. Dans des conditions dégénérées, cela peut entraîner des pauses du système d'une minute ou deux (mon expérience en était dans RHEL6; espérons que cela a été amélioré). Si vous supprimez des caches, le balayeur des pages énormes aura une certaine marge de manœuvre.

Vous pourriez faire valoir que c’est une bonne raison de désactiver les énormes pages transparentes; OTOH, vous pouvez penser que l’amélioration globale des performances de transparent hugepages vaut la peine d’être payée et de payer le prix de la perte de vos caches une fois par jour.


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

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


1
Avez-vous une source pour cela? Cela ressemble à quelque chose qui devrait être corrigé dans le noyau si c'est un tel problème.
gparent

3
J'ai une expérience personnelle avec les pauses d'énormes pages transparentes. RHEL6, Dell R810, 4CPU, 64 Go de RAM. La désactivation de gigantesques transparentes (il existe un fichier / proc pour le faire) corrige immédiatement les pauses. Je n'ai pas essayé la technique de cache cache à l'époque; au lieu de cela, j'ai reconfiguré nos applications java pour utiliser d'énormes pages non transparentes et les ai laissées désactivées. IIRC, nous avons suffisamment examiné la situation pour nous rendre compte que nous n'étions pas les seules personnes touchées et que Red Hat était au courant du problème.
Dan Pritts

Bonjour Dan, je constate le même comportement sur mon serveur. Je travaille avec une énorme quantité de données et il y a une chute drastique des performances après plus de 10 calculs d'un même programme python (x2-3 du premier temps de calcul). Si je regarde, la taille de la mémoire cache est énorme, plus de 100 Go. Et si je vide ce cache mémoire et relance mon programme, je récupère mon temps de calcul initial. Avez-vous des documents ou des informations à partager sur ce phénomène? Merci.
Axel Borja

1
access.redhat.com/solutions/46111 le décrit. Vous pouvez désactiver les hugepages transparentes pour voir s’il s’agit d’un problème dans votre cas.
Dan Pritts

2

Juste pour ajouter mes deux centimes: le système sait très bien que ces pages de mémoire sont des caches et il en supprimera autant que nécessaire dès qu'une application demande de la mémoire.

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


1

La question est de 2014, mais comme le problème existe à ce jour sur certains moteurs cachés centos 6.8, 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 du fichier ne sont pas supprimés du cache inode du noyau.

Behlendorf, le 6 janvier 2015, a écrit:

La spéculation actuelle est que, pour une raison quelconque, le serveur NFS conserve une version en cache du descripteur de fichier. Jusqu'à ce que le serveur NFS supprime ce descripteur de fichier, ZFS ne peut pas dissocier ce fichier. Quelques tests clairs ont montré que la suppression de caches sur le serveur entraînerait la suppression de cette référence (comme le descripteur de fichier NFS), moment auquel l'espace est libéré correctement. La pression de la mémoire peut également causer une chute.

Par exemple, un écho nocturne 3> / proc / sys / vm / drop_caches est la solution la plus simple pour résoudre ce bogue si vous ne souhaitez pas de temps mort pour la restructuration de votre zfs.

Donc, peut-être pas la gestion du culte du fret, mais plutôt un bon débogage en était la raison.


0

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

De nombreuses applications parallèles simples ont tendance à effectuer des entrées / sorties sur des fichiers à partir d'un seul processus, ce qui laisse à la sortie une grande fraction de mémoire sur un seul nœud NUMA alloué au cache disque, tandis que sur l'autre nœud NUMA, la mémoire peut être principalement libre. Dans ces situations, étant donné que le processus de récupération de cache dans le noyau Linux, autant que je sache, n’est toujours pas pris en compte par NUMA, les processus exécutés sur le nœud NUMA auquel la mémoire est allouée sont obligés d’allouer de la mémoire sur l’autre nœud NUMA, tant qu'il y a de la RAM libre sur l'autre noeud, ce qui tue les performances.

Toutefois, 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 précis avec cron.

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


0

Lorsque le cache de votre page est assez volumineux (beaucoup plus que votre utilisation actuelle du swap) et que le swap in et le swap out se produisent à tour de rôle, vous devez alors supprimer des caches. J'ai vu des cas d'augmentation de l'utilisation de la mémoire sur l'un de mes serveurs de base de données MariaDB exécutant Ubuntu 16.04LTS, et Linux a simplement choisi d'augmenter l'utilisation de la permutation au lieu de supprimer les caches de page inutilisés. Les énorme pages transparentes sont déjà désactivées sur mon système car TokuDB a demandé sa désactivation. Quoi qu’il en soit, ce n’est peut-être pas un bug, mais Linux continue à adopter ce comportement m’intéresse beaucoup. Diverses sources ont déclaré que Linux supprimerait le cache de pages lorsque l'application le demanderait:

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

  1. Exécuter drop cache périodiquement
  2. Exécutez la suppression du cache si nécessaire (moniteur utilisant vmstat 1 pour permuter les activités)
  3. Conseillez à Linux de supprimer certains fichiers du cache (tels que les fichiers journaux Apache) à l'aide d'un utilitaire tel que dd ou python-fadvise. Voir https://unix.stackexchange.com/questions/36907/drop-a-specific-file-from-the-linux-filesystem-cache

Exemple dd run:

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

Exemple python-fadvise:

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


-5

J'ai un ordinateur de bureau avec 16 Go de RAM en cours d'exécution sur le noyau PAE. Au bout d'une heure ou deux, les performances du disque se dégradent considérablement jusqu'à ce que je supprime les caches. Je l'inscris simplement dans cron. Je ne sais pas s'il s'agit d'un problème lié au noyau PAE ou à la lenteur de l'implémentation du cache s'il y a beaucoup de mémoire.


9
C’est un excellent exemple de l’administration système «culte de la cargaison»: au lieu de localiser et de résoudre le problème, vous le masquez simplement.
Michael Hampton

2
Parfois, la solution la plus appropriée est la bonne. Cela pourrait simplement différer le règlement du problème réel, ou ce pourrait être toute la solution requise dans les circonstances. Même si c'est une mauvaise pratique, ce n'est toujours pas un "culte du fret". Il existe une cause démontrée: les caches de suppression et les performances du disque sont améliorées.
Dan Pritts

1
Une partie de la définition originale de CCSA était une tendance à confondre corrélation et causalité, et nous en sommes là. Masquer un problème en abordant une entité corrélée mais non causale est une résolution de problème non optimale, ce contre quoi le concept de CCSA tente de mettre en garde.
underscore_d
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.