Journal Récupérer la mémoire consommée

Posté par  (site web personnel) .
Étiquettes : aucune
-3
4
sept.
2008
Je cherche à récupérer la mémoire consommée par un processus lancé comme benchmark. Je cherche à rendre cela automatique.

Time propose de rendre des informations sur la mémoire en plus du temps passé, mais il rend toujours "0".

J'ai lu cette page mais cela a l'air bien complexe:
http://elinux.org/Runtime_Memory_Measurement

En gros, elle suggère de lancer le test puis d'aller fouiller dans /proc ou dans la commande ps. Le problème est qu'il peut y avoir une race condition et que l'on ne peut pas avoir la "taille max".

La commande statique size permet d'avoir déjà beaucoup d'information (taille des données statiques et du code). Mais j'aimerais avoir les tailles allouées par malloc() et la taille de la pile sans devoir instrumenter mon code.

Donc, est-ce que vous connaissez un moyen simple d'avoir la taille max de la mémoire consommé par le tas (malloc) et la pile sur un processus "court" ? Ou est-ce que je vais devoir bricoler avec un ps lancé en parallèle ?

  • # valgrind

    Posté par  . Évalué à 10.

    Le seul outil qui te donnera les info fiable sur le sujet, c'est massif l'outil de valgrind. Sinon tu peux creer une lib qui intercepte tous les appel aux fonctions d'allocation (malloc,mmap,brk,...) et faire tes mesures toi meme.

    Mais syncerement, massif pour analyser la conso memoire et callgrind pour analyser le temp passe dans chaque operation sont les deux seuls outils qui te donneront des informations fiables et utilisable.

  • # a la mimine

    Posté par  (site web personnel) . Évalué à 3.

    Tu peux toujours reimplementer un malloc bete qui appelle le vrai (via un syscall sinon ça va boucler severe avant de peter la pile ...) mais qui en profite pour comptabiliser dans une globale statique la taille memoire allouée et pourquoi pas generer un graphique via un thread. le tout dans une lib dynamique prechargée via un LD_PRELOAD.
    ca ralentira considerablement le processus, mais tu pourra l'appliquer a n'importe quel process.

    • [^] # Re: a la mimine

      Posté par  (site web personnel) . Évalué à 1.

      Tu peux toujours reimplementer un malloc bete qui appelle le vrai (via un syscall sinon ça va boucler severe avant de peter la pile ...)

      Hum, tu es sûr de ce que tu dis? Il me semble que malloc n'est pas un appel système, mais une fonction de la libc. À moins que tu ne veuilles parler de brk(2)? Enfin, sans aller jusque là, la technique "habituelle" serait de faire un dlopen/dlsym de la libc et du symbole de malloc().

      seb.

      • [^] # Re: a la mimine

        Posté par  . Évalué à 2.

        C'est le principe du LD_PRELOAD: tu charges une lib qui va faire intermédiaire aux appels à la libc, en remplaçant malloc et free, qui appelerons les originaux mais en ayant entre deux comptabilisé la mémoire allouée/libérée.

  • # struct rusage

    Posté par  . Évalué à 2.

    Et en utilisant la struct rusage que te fournit wait4, et notamment les membres :

    long ru_maxrss; /* max resident set size */
    #define ru_first ru_ixrss
    long ru_ixrss; /* integral shared memory size */
    long ru_idrss; /* integral unshared data " */
    long ru_isrss; /* integral unshared stack " */

    tu n'as pas cette info ?

    Source :
    man 2 wait4
    /usr/include/sys/ressource.h

    • [^] # Re: struct rusage

      Posté par  (site web personnel) . Évalué à 2.

      getrusage ressemble beaucoup aux informations que retourne time -A (mais qui sont toute nulle).

      Je vais regarder.

      "La première sécurité est la liberté"

  • # Journal ?!

    Posté par  . Évalué à -1.

    Je me trompe où tu as fais un journal à la place d'écrire dans un forum ?

    Et lorsque tu voudras faire un journal, tu en feras une dépêche de première page ?

    • [^] # Re: Journal ?!

      Posté par  (site web personnel) . Évalué à 9.

      Je me disais aussi qu'il manquait un commentaire aigri sur cette page...

      "La première sécurité est la liberté"

    • [^] # Re: Journal ?!

      Posté par  . Évalué à 2.

      Et voilà! Pour la prochaine évolution majeure de linuxfr, les forums seront présentés sur la page d'accueil et on pourra les pertinenter ou les moinsser. Commes les forums sont moins lus que le reste, leur note par défaut sera inférieure à celle des journaux etc.

  • # exmap

    Posté par  (site web personnel) . Évalué à 5.

    http://labs.o-hand.com/exmap-console/

    Exemple pour le processus nautilus :

    exmap nautilus
    http://pastebin.com/m73c72c92

    Exmap est très verbeux par défault, mais il y a des options de filtrage et de tri. Il t'affiche aussi une donnée bien sympathique: le "sole use" qui est la quantité de mémoire réellement consommée par le processus. Par exemple pour une appli GTK, les bibliothèques GTK sont partagées entre différent processus. Le sole use ne montre donc que la mémoire que seule cette application utilise, ce qui est un bonne indicateur de sa consommation mémoire réelle, quand tu es dans l'environnement cible. Ici, nautilus consommerait plus en "sole use" s'il était chargé dans un environnement KDE, vu qu'il serait la seule appli en cours d'utilisation utilisant les bibliothèques GNOME.

    Voici une vue plus synthétique des informations fournies par exmap :
    exmap --no-file-info nautilus
    Process 4397 [nautilus]
    Virtual memory : 92812 KB
    Effective VM : 86660 KB
    Heap : 6680 KB
    Stack : 260 KB
    vdso : 0 B
    Mapped : 18704 KB
    Effective mapped: 12552 KB
    Sole use : 8792 KB

    • [^] # Re: exmap

      Posté par  (site web personnel) . Évalué à 0.

      ah, et si tu veux les pics de consommation, ils n'ont pas l'air fournis par exmap. Tu peux alors essayer ceci :
      cat /proc/$(pgrep nautilus)/status | grep VmPeak

  • # un petit truc...

    Posté par  (site web personnel, Mastodon) . Évalué à 1.

    Et ce petit truc, ça peut pas aider ?


    /*
    * Warning: this function was a GNU/Linuxism !
    */
    malloc_stats();

  • # un compte rendu

    Posté par  (site web personnel) . Évalué à 2.

    J'ai testé toutes les méthodes proposées :
    - valgrind avec massif
    - valgrind avec memcheck
    - exmap
    - le grep de VmPeak

    Pas un seul ne donne les mêmes résultats. En effet, entre les effets de partages mémoire (library), le COW, l'allocation paraisseuse (après un malloc il faut effectivement accéder à une page pour qu'elle soit lu), que le chiffre est différent.

    memcheck donne ce qui est demander par malloc(). Dans mon cas, 3Go.
    massif donne des résultats étranges sur mon cas de test. Mais je n'ai pas la dernière version.
    exmap marque les pages utilisées réellement par le noyau (c'est un module noyau), on a donc les pages utilisées uniquement par le processus analysées (125Ko dans mon cas).

    Vmpeak correspond à la demande au système de pagination du noyau. J'ai 1Go dans mon cas, ce qui correspond à ma RAM (qui est inférieur au malloc de 3Go).

    Mon cas de test est spécial, mais finalement, cela montre bien la complexité de mesure de la mémoire consommée.

    "La première sécurité est la liberté"

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.