Bonjour,
Je souhaite mesurer la consommation mémoire de l'une de mes applications tournant sur une cible embarquée (un powerpc)
La commande free me ressort le résultat suivant:
free:
total used free shared buffers
Mem: 126208 51864 74344 0 0
-/+ buffers: 51864 74344
Swap: 0 0 0
Or lorsque je récupère la valeur de Vmsize dans /proc/pid/status j’obtiens le résultat suivant:
(avec pid le pid de mon application)
Appli:
VmPeak: 264960 kB
VmSize: 264960 kB
Même résultat avec top qui me sort 211% d'utilisation mémoire. Comment cela est possible ? Comment faire pour connaitre l'impact mémoire réel de mon application ??
Merci d'avance pour vos éclaircissement.
# que veut dire réel ! ?
Posté par Old Geek . Évalué à 4.
1) Sous unix toute la mémoire est partagée par copy on write,
les libraries et les binaires, ce qui signifie qu'une grande partie de ton application
à de la mémoire partagée avec d'autres programmes, tant que les pages sont les mêmes, c'est mutualisé (shared).
2) les applications allouent de la mémoire virtuelle, qui tant qu'elle n'est pas réellement utilisée (des écritures dedans), n'est en fait pas allouée par le système, il y a donc par défaut un mécanisme permettant d'allouer plus de mémoire que l'on en a réellement …
l'impact réel étant une question simple la réponse ne l'est pas !, essaie voire de jouer avec pmap, cela te donneras peut être des idées …
[^] # Re: que veut dire réel ! ?
Posté par Old Geek . Évalué à 1.
et encore je ne parle même pas de la mémoire partagée
(shared memory) ou pire de ksm … (kernel shared memory), qui augmente encore d'un cran la complexité du calcul !
[^] # Re: que veut dire réel ! ?
Posté par Tangi Colin . Évalué à 1. Dernière modification le 25 avril 2012 à 17:48.
par réel, j'entendais quel place utilise mon programme en ram (sur mes 128Mo ça m'en prend combien). J'aimerai avoir cette valeur pour aussi vérifier que je n'ai pas de fuite de mémoire.
[^] # Re: que veut dire réel ! ?
Posté par gaaaaaAab . Évalué à 3.
pour la vérification des fuites mémoire (et plus globalement de la gestion de la mémoire), jette un oeil sur valgrind
[^] # Re: que veut dire réel ! ?
Posté par Enoch (site web personnel) . Évalué à 2. Dernière modification le 26 avril 2012 à 17:26.
Avec un ps aux tu aura une bonne estimation :
Les colonnes qui vont t'intéresser sont les colonnes %MEM (pourcentage de mémoire résidente occupée par chaque process) et la colonne RSS (Resident Set Size -> mémoire physique non-swappée utilisée par ton process en Ko).
Après comme dit plus haut pour connaitre la mémoire totalement utilisée par un programme c'est plus compliqué, faut prendre en compte la mémoire partagée, etc.
Mais pour repérer un process qui bouffe trop de mémoire ça devais te suffire je pense.
[^] # Re: que veut dire réel ! ?
Posté par Tangi Colin . Évalué à 1.
Merci beaucoup pour cette réponse, c'est RSS que je cherchais (qui se trouve aussi dans /proc/pid/status).
# mémoire virtuelle != mémoire physique
Posté par alk . Évalué à 3.
La différence entre free et /proc/pid/status vient du fait que free donne des informations sur la mémoire physique alors que Vm{Peak,Size} donnent des informations sur la mémoire virtuelle.
Un processus peut avoir réservé bien plus de mémoire qu'il n'y a de mémoire physique sur le système. Ce n'est pas un problème tant qu'il ne s'en sert pas. S'il s'en sert alors le système finira par swapper ou le processus sera tué.
Ce phénomène peut se produire dans le cas d'un programme qui contient "beaucoup" de threads. Si c'est ton cas, tu peux essayer de réduire la taille de la stack des threads. Par défaut, la glibc réserve 8MB pour la stack de chaque thread dans l'espace mémoire du processus père. Sauf cas particulier, avec 32kB ça devrait fonctionner sans problème.
Voir man setrlimit (global) ou man pthread_attr_setstacksize (par thread).
En même temps, si cela vient des threads, la mémoire ne sera pas utilisée donc tu ne devrait pas avoir de pb. Sauf si tu créer trop de thread et que tu atteins la limite de l'espace virtuel (déjà vu!).
[^] # Re: mémoire virtuelle != mémoire physique
Posté par alk . Évalué à 1.
Han. J'ai posté trop vite et répondu à moitié à côté.
Niveau outils pour connaître l'empreinte mémoire d'un programme, il y a un certain temps, j'ai bricolé avec ps_mem.py et sp-smaps parmi les outils développés chez maemo.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.