Seuls init, telnet et sh sont en cours d'exécution, toujours une fuite de mémoire. Comment trouver la raison?

Nous avons un problème avec les boîtes Linux intégrées. Certaines boîtes ont une fuite de mémoire.

Aucun des processus ne contient pas la mémoire perdue.

Après avoir éliminé tous les processus possibles, la fuite existe toujours. En regardant dans / proc / meminfo, il semble que la mémoire perdue se trouve dans la mémoire inactive:

~ # echo 1 > /proc/sys/vm/drop_caches ; cat /proc/meminfo
MemTotal:       126744 kB
MemFree:        107684 kB
Buffers:             0 kB
Cached:           1160 kB
SwapCached:          0 kB
Active:           1204 kB
Inactive:        12532 kB
SwapTotal:           0 kB
SwapFree:            0 kB
...


~ # ps        
  PID USER       VSZ STAT COMMAND
    1 root      2748 S    init       
    2 root         0 SW<  [kthreadd]
    3 root         0 SW<  [ksoftirqd/0]
    4 root         0 SW<  [events/0]
    5 root         0 SW<  [khelper]
   31 root         0 SW<  [kblockd/0]
   42 root         0 SW<  [khubd]
   48 root         0 SW<  [kmmcd]
   82 root         0 SW   [pdflush]
   83 root         0 SW   [pdflush]
   84 root         0 SW<  [kswapd0]
   85 root         0 SW<  [aio/0]
  170 root         0 SW<  [rpciod/0]
  176 root         0 SW<  [mmcqd]
 1346 root      2756 S    telnetd -l /bin/login 
 1347 root      2856 S    -sh 
 3737 root      2856 R    ps 
~ #

Les disques RAM ne sont pas utilisés. La version Linux est 2.6.25.9.

Est-il possible de trouver une raison pour laquelle la mémoire inactive augmente tout le temps? Est-il possible de vider ou de supprimer la mémoire inactive?

linux memory

— Ski
source

Comment ces problèmes de fuite de mémoire se manifestent-ils? Recevez-vous un message d'erreur lorsque vous exécutez un programme donné? Quel est le programme et le message d'erreur exact?

— RedGrittyBrick

Nous essayons de surveiller l'utilisation de la mémoire et de déclencher une alarme lorsque son utilisation dépasse 40%. Plusieurs clients ont remarqué l'alarme. Et maintenant, nous étudions la raison de l’alarme. Après 2 réponses, il semble que notre sw compte mal la mémoire utilisée.

— SKi

Votre raisonnement est faux. Tout le but de la mémoire doit être utilisé. Utiliser la majeure partie de votre mémoire est tout à fait normal. Les ordinateurs modernes utilisent autant de mémoire que possible pour améliorer les performances. La mémoire non utilisée est complètement perdue. Ce n'est pas comme si vous n'utilisiez que la moitié de la mémoire maintenant, vous pouvez en utiliser deux fois plus demain. Toute mémoire que vous n'utilisez pas aujourd'hui est une perte de performance à jamais.

— David Schwartz

Oui, je comprends ça. Le seul but est de détecter une éventuelle fuite de mémoire avant que la fuite ne pose problème. Nous n'allons pas laisser tomber des caches ou autres dans les environnements de production.

— SKi

Réponses:

La mémoire inactive n'est pas un problème, certainement pas une "fuite"; ce sont des pages de mémoire qui ont généralement été utilisées pour mettre en mémoire tampon des fichiers ou des exécutables qui ne sont pas en cours d'exécution et qui sont conservées pour une éventuelle utilisation. Si quelque chose a besoin de ces données (lire le même fichier ou exécuter le même programme), elles seront réutilisées sans que le disque ne soit touché à nouveau. Si quelque chose d'autre a besoin des pages, leur état inactif signifie qu'elles seront utilisées en cas de besoin.

En d'autres termes, considérez la mémoire libre comme une mémoire qui n'a jamais été allouée. La mémoire inactive est la mémoire allouée et libérée .

— geekosaur
source

La mémoire inactive est la première ligne à être libérée. S'il avait déjà été libéré, ce serait libre, pas inactif. (Dans son cas, je suppose que la majeure partie de la mémoire inactive est une mémoire qu'il a forcée à quitter le cache en supprimant le cache de page.)

— David Schwartz

Il n'y a aucune preuve de fuite d'aucune sorte dans les données que vous avez publiées. La mémoire est correctement suivie comme inactive. Si vous effectuez une opération syncantérieure à drop_caches, vous ne verrez probablement pas autant de mémoire inactive, mais vous la créez en forçant des pages à sortir du cache. S'ils ne peuvent pas être libérés (disons qu'ils sont sales), ils deviennent inactifs.

Vous pouvez forcer la synchronisation plus rapide de la mémoire sale et inactive en cours d'exécution sync, mais je ne peux imaginer aucune raison possible de le faire. Vous ne pouvez pas forcer la mémoire propre et inactive à être libérée, et je ne peux pas imaginer la raison pour laquelle vous voudriez. Le système peut déjà le supprimer et il est déjà le premier à être utilisé lorsque le pool de mémoire disponible est épuisé. Pourquoi voulez-vous qu'il soit plus libre?

Si vous ne souhaitez pas que le système utilise la mémoire, sortez-la de la machine et déposez-la sur votre bureau. En ce moment, vous ralentissez le système en le forçant à réduire la taille des caches et à vider les pages encrassées plus rapidement qu'il ne le souhaite, ce qui entraîne des tonnes d'E / S inutiles. Laissez-le tranquille et laissez-le faire son travail.

— David Schwartz
source