Quelque chose mange toute la mémoire (je soupçonne une fuite de mémoire sur une application). Comment détecter quoi?

16

J'ai un serveur qui exécute le paquet liquidsoap + icecast et un site Web simple (httpd + mysqld). Rien de spécial. Visiteurs environ 2000+ par jour, avec environ 50 étant en ligne simultanément en moyenne.

Le serveur a 8 Go de RAM. Au fil du temps, la quantité de mémoire libre diminue constamment, bien que rien de nouveau ne soit démarré sur le serveur et qu'il n'y ait pas de nouveaux utilisateurs. À un moment donné, il commence à s'échanger, la charge sur le serveur augmente et il ne répond plus. Habituellement, je redémarre simplement le serveur ...

Que peut-on faire pour détecter ce qui fuit exactement la mémoire? J'utilise top pour surveiller l'utilisation des ressources, mais pour autant que je le vois, cela ne montre rien d'utile:

entrez la description de l'image ici

Existe-t-il un moyen de savoir ce qui utilise autant de mémoire? ou qu'est-ce qui commence à basculer lourdement sur le disque? Est-il possible de libérer de la mémoire sans redémarrer le serveur?

linux memory-usage top resources memory-leak jayarjo
la source
Une raison pour laquelle vous n'essayez pas de redémarrer certains services (apache, liquidsoap) au lieu du serveur?
jamespo
J'ai initialement répondu pour une utilisation normale de la mémoire. J'ai mis à jour un ensemble d'outils qui peuvent aider à identifier le problème.
BillThor
@jamespo, en fait, j'ai essayé, mais cela n'a eu aucun effet, donc le redémarrage était la seule chose que je savais pouvoir aider.
jayarjo
Le 4027092k mis en cache devrait expliquer l'utilisation de la mémoire, non? Je travaille en ce moment sur un problème similaire ailleurs, et jusqu'à présent, j'ai réussi à comprendre que le transfert de mémoire peut être régulé avec les paramètres suivants: vfs_cache_pressure vm.dirty_ratio vm.dirty_background_ratio Ce n'est pas un correctif complet et aucun commentaire bienvenue. J'espère que c'est une bonne direction à prendre.

Réponses:

16

L'exécution topen mode batch pour signaler périodiquement les tailles de mémoire peut être utilisée pour voir qui utilise la mémoire lorsque les choses vont au sud. L'exécution saren mode batch devrait fournir de bons diagnostics sur l'utilisation de la mémoire et les E / S associées. Fonctionnementmunin pour surveiller le système devrait vous donner un graphique avec de bons détails sur la mémoire utilisée. Cela peut aider beaucoup.

Vous pouvez utiliser limits.conf pour limiter la taille maximale du cœur des programmes. Correctement réglé, cela devrait tuer tous les programmes qui fuient la mémoire. Cela fonctionne avec le module pam_limits. Des limites peuvent également être définies avec leulimits commande.

Vous exécutez quelques programmes qui pourraient utiliser de grandes quantités de mémoire. Certaines choses que vous pourriez regarder incluent.

  • Des applications mal programmées fonctionnant sous apache2peuvent entraîner une fuite de mémoire. Vous devriez voir la taille de la mémoire augmenter lorsque cela se produit. Vous pouvez régler apache2 pour recycler les enfants après un certain nombre d'utilisations en définissant MaxRequestsPerChildà 100 environ. Si cela résout le problème, vous devez résoudre la fuite. Je regarderais cela en premier.
  • MySQL peut essayer de charger des données en mémoire. Si vous avez beaucoup de données en mémoire, cela peut provoquer des dégâts, mais ne devrait pas être aussi dramatique que vous le voyez.
  • Si un tmpfssystème de fichiers volumineux est monté, vous risquez de perdre de la mémoire si les fichiers ne sont pas supprimés lors de leur utilisation. Les fichiers volumineux de longue durée peuvent également être un problème.
  • Si le problème se produit à peu près au même moment de la journée, vous pouvez avoir un programme planifié qui fuit la mémoire.
  • Si vous avez un programme qui alloue de la mémoire partagée, mais ne le libère pas avant de quitter, vous aurez une fuite de mémoire relativement invisible. Si la mémoire partagée est verrouillée en mémoire, cela peut forcer l'échange. La quantité de mémoire partagée disponible est généralement relativement limitée.
  • Le bundle liquidsoap + icecast peut rencontrer des problèmes de mise en mémoire tampon qui utilisent de la mémoire. Je n'ai pas utilisé cette combinaison, donc je ne sais pas comment cela apparaîtrait.

Utilisation normale de la mémoire: la mémoire libre n'est pas quelque chose dont vous voulez beaucoup. Si votre système fonctionne depuis longtemps et a beaucoup de mémoire libre, quelque chose ne va pas. Chaque fois que vous lisez ou écrivez un fichier, les blocs iront dans le cache tampon. Cela réduira votre mémoire libre et c'est une bonne chose. Le système gardera suffisamment d'espace libre pour démarrer quelques programmes sans chercher ailleurs la mémoire. Comme de nombreux programmes s'exécutent rapidement, leur mémoire sera renvoyée au pool libre à la fin de leur exécution.

Lorsque vous lisez un fichier qui se trouve dans le cache de tampon, aucun accès au disque n'est requis et la lecture est résolue à partir du cache de tampon. Les écritures utilisent un mécanisme similaire. Si votre système a besoin de mémoire, le cache tampon est l'un des premiers endroits utilisés. La plupart des tampons peuvent être libérés immédiatement.

Si vous avez une fuite de mémoire, vous verrez de la mémoire libre et des tampons commencer à rétrécir. Ce n'est toujours pas un problème grave, car la mémoire perdue devrait finalement être déplacée vers l'espace d'échange. Votre système fonctionnera toujours correctement jusqu'à ce que vous remplissiez l'espace de swap et tirez l'espace libre restant au point où les programmes ne peuvent pas être démarrés. Il est typique qu'une petite quantité d'espace d'échange puisse être utilisée.

BillThor
la source
Le problème dans mon cas est un peu bizarre. Même lorsque la charge est énorme et que le serveur échange beaucoup, il y a beaucoup de mémoire libre (comme je l'ai compris après avoir lu sur les tampons et les caches). top ne montre aucun processus monopolisant de plus en plus la mémoire. Mais la charge monte et à un moment donné le serveur devient inutilisable: | Merci pour la réponse détaillée.
jayarjo
2
@jayarjo: Munin et sar devraient aider à détecter ce qui se passe. Si vous avez beaucoup de mémoire libre, vous ne devriez pas échanger. Vous pouvez avoir un problème d'E / S différent. saraidera à identifier quelle partition possède les E / S et peut aider à découvrir le problème.
BillThor
+1 pour MaxRequestsPerChild conseil
jamespo
11

Vous pouvez utiliser cette commande pour voir les 10 meilleures applications concernant l'utilisation de la RAM:

ps -A --sort -rss -o comm,pmem | head -n 11

Parfois, cette commande vous aide si de nombreux sous-processus ont été générés:

ps auxf

De cette façon, vous pouvez voir quels processus vont ensemble.

Raffael Luthiger
la source
Ce sont des commandes pratiques, merci je les noterai pour l'avenir. Mais le problème est qu'il y a toujours les mêmes processus en haut (vous pouvez les voir dans la capture d'écran ci-jointe) - apache, mysql, liquidsoap, icecast. Et ils utilisent (ou du moins sont montrés à utiliser) la même quantité de mémoire (vraiment négligeable), même lorsque le serveur est en train de mourir de charge: |
jayarjo
@jayarjo: Le nombre de processus change-t-il? Avez-vous beaucoup plus de processus? Et s'agit-il d'un serveur physique ou virtuel?
Raffael Luthiger
Je n'ai remarqué aucun changement dans le nombre de processus. Fondamentalement, lorsque je fais le top, alors que le serveur est en train de mourir de charge, je vois une image très similaire à celle que j'ai jointe à la question d'origine, à l'exception de la charge énorme: | Le serveur est physique.
jayarjo
2
Essayez d'obtenir plus d'informations avec "vmstat" (par exemple vmstat -s). Ou avec l'outil déjà mentionné "sar". Avez-vous peut-être un système de fichiers basé sur la RAM? Alors peut-être que "iostat" peut aussi donner plus d'informations.
Raffael Luthiger
1
Je doute que le champ psou la topsortie "pmem" (% MEM) soit la bonne chose à regarder si l'on essaie de détecter une fuite de mémoire: n'est-ce pas seulement le pourcentage de la mémoire physique que le processus utilise actuellement? Mais d'autres parties de la mémoire utilisée (y compris les fuites) du processus peuvent être échangées. Peut-être que "taille" ou "vsize" serait plus approprié pour mesurer la taille d'un processus? Par exemple, ps -A --sort -size -o comm,size | head -n 11oups -A --sort -vsize -o comm,vsize | head -n 11
imz - Ivan Zakharyaschev
8

Rien n'utilise vraiment cette mémoire en termes d'applications.

Vous devez déduire la valeur «mise en cache» qui représente le cache de page pour avoir une meilleure idée de votre utilisation réelle de la mémoire en termes d'utilisation du programme.

Fondamentalement, c'est une bonne gestion de la mémoire et c'est idéalement ce que vous voulez.

Voir le lien ici pour plus d'informations: http://www.linuxatemyram.com/

Matthew Ife
la source
oui, j'ai trouvé ce lien et lu sur les tampons et les caches, mais pour autant que je puisse en tirer ce que j'ai lu, ils ne peuvent pas provoquer de permutation, n'est-ce pas?
jayarjo
@jayarjo Je pense que pour comprendre ce qui se passe là-bas, nous aurions besoin de statistiques démontrant le problème. Les chiffres que vous avez donnés ne montrent pas l'échange ou beaucoup d'utilisation réelle de la mémoire.
Matthew Ife
1

Je ne suis pas vraiment un pro, mais le savon liquide + icecast est lié au multimédia. Lorsque le système est libre, il met en cache et / ou occupe la mémoire pour une utilisation future. Et si le trafic augmente à un certain moment de la journée / sur une période de temps, il commencera à échanger. À ce stade, si les demandes (utilisateurs visualisant du contenu) augmentent, les ressources nécessaires seront supérieures à 8 Go de RAM.

Yash
la source