Question Pourquoi déposer des caches sous Linux?


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?


81
2018-05-20 03:12


origine


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♦
Déboguer le noyau. C'est à peu près ça. Cela ne libère pas réellement de RAM; il supprime les caches, comme son nom l'indique, et réduit donc les performances. - Michael Hampton♦
@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 effectué un virage serré à droite, éviter les virages serrés à droite est une solution médiocre. - David Schwartz
en relation thedailywtf.com/Articles/Modern-Memory-Management.aspx Argumenter fortement c'est une mauvaise idée. - Drunix
En relation, et une description utile du "problème": linuxatemyram.com - Bill Weiss


Réponses:


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


85
2018-05-20 04:59



+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
@Tonny: Il nous resterait alors sans sysadmin department :( - PlasmaHH
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
Expliquez l'administration du 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
"Il est possible que, même si votre application n'utilise pas cette RAM, mais que Linux mette en cache de manière agressive dans sa mémoire, même si l'application a besoin de mémoire, elle ne libère pas une partie de ces antémémoires, mais préfère commencer à la permuter." 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


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 en utilisant pdflush.


62
2018-05-20 06:26



+1 pour expliquer Pourquoi C'est une mauvaise idée. - Ogre Psalm33


La raison pour laquelle les caches de ce type sont supprimées est l’analyse comparative des performances des disques et constitue la seule raison pour laquelle elles existent.

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 le Documentation:

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

L'utilisation de ce fichier peut entraîner des problèmes de performances. Depuis qu'il se défait   objets mis en cache, il peut en coûter une quantité importante d'E / S et de CPU pour   Recréez les objets lâchés, surtout s’ils étaient très sollicités.   De ce fait, l'utilisation en dehors d'un environnement de test ou de débogage est   non recommandé.


34
2018-05-20 13:51



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. - α CVn
"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
Le cas évident est lorsque vous souhaitez vider la RAM pour permettre l’allocation de plus de pages gigantesques (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 content que le - Dan Pritts


L’idée de base ici n’est probablement pas si mauvaise (elle est très naïve et trompeuse): il est possible que certains fichiers soient mis en cache, mais qu’il est très peu probable qu’on y accède dans un proche avenir, par exemple les fichiers journaux. Ces béliers "mangent", qui devront être libérés plus tard 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 commencent à 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? définitivement 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 choses comme posix_fadvise()ou en utilisant un outil de ligne cmd comme vmtouch (qui peut également être utilisé pour examiner des choses 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 davantage de RAM, car l'utilisation maximale quotidienne du serveur correspond à cela.


25
2018-05-20 19:46



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.out toutes les 15 minutes, car nohup.out se développe rapidement. Peut-être que linux met en cache nohup.out même si je l’efface - ivcode
@ivcode Si vous n'avez pas besoin de la sortie de nohup vous devriez le 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 de /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


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 toutes les nuits.


16
2018-05-22 00:47



J'ai voté pour avoir signalé les préjugés du deuxième ordre concernant les réponses aux caches de dépôt. - Noah Spurrier
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 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 travailler sauf si je lâche d'abord des caches (Arch linux). - Aleksandr Dubinsky


Il est possible que cela ait été institué comme un 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 pour faire ce qu’il essaie de faire. Si le système est en train de permuter (essayer de lire et d’écrire à partir d’une partition d’échange de disque plus rapidement que ce qu’il est réellement capable), le fait de supprimer périodiquement des caches peut faciliter la tâche. symptôme, mais ne fait rien pour guérir le 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 a atteint 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.


8
2018-05-20 15:16





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.

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 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).


4
2018-05-21 08:03



"Un bogue dans le noyau qui rend fou kswapd" - Quel bogue s'agit-il? - Ben
@Ben voir ce fil (Ce message et quelques suivis, dont l'un inclut une supposition d'où il pourrait provenir) - mirabilos
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
@ Fernando j'ai aussi un cronjob de “drop caches” sur la boîte m68k - mirabilos


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 tombe en dessous d’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
2018-05-21 06:20





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 pour 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; j'espère 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 pensez peut-être que l'amélioration globale des performances de transparentes d'énormes pages vaut la peine d'être payée et qu'elle mérite 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 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.


3
2018-01-14 15:43



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
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) a immédiatement corrigé les pauses. Je n'ai pas essayé la technique de suppression de cache à l'époque; au lieu de cela, j'ai reconfiguré nos applications java pour utiliser d'énormes pages non transparentes et laissé les pages transparentes 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 du cache mémoire 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? Je vous remercie. - Axel Borja
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


Juste pour ajouter mes deux centimes: le système sait très bien que ces pages de mémoire sont des caches et laisseront tomber autant que nécessaire quand 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".


2
2018-05-26 11:04