Utilisation maximale de la mémoire d'un linux/unix processus

Est-il un outil qui va exécuter une ligne de commande et le rapport de la crête de l'utilisation de la RAM totale?

J'imagine quelque chose d'analogue à /usr/bin/time

InformationsquelleAutor |
  1. 11

    Voici un one-liner qui ne nécessite pas de scripts externes ou de services publics, et ne vous obligent pas à démarrer le processus via un autre programme comme Valgrind ou le temps, de sorte que vous pouvez l'utiliser pour n'importe quel processus qui est déjà en cours d'exécution:

    grep VmPeak /proc/$PID/status

    (remplacer $PID avec le PID du processus qui vous intéresse)

    • Que faire si je ne sais pas PID? Par exemple, dans le cas où le programme exécute une petite quantité de temps (<1)
    • "VmHWM: Pic de resident set size" pourraient être plus utilisable pour mesurer l'utilisation de la RAM (au lieu de VmPeak qui comprend beaucoup d'autres choses aussi).
    • ça dépend vraiment de ce que vous voulez savoir. IIRC VmPeak est le nombre total maximum de l'utilisation de la mémoire, y compris la mémoire virtuelle, tandis que VmHWM est le pic de l'utilisation de la RAM. Donc, si vous voulez savoir la quantité de mémoire totale de votre programme a demandé, utilisez VmPeak; si vous voulez savoir combien de votre RAM, il n'a jamais utilisé à un moment donné, l'utilisation VmHWM.
    InformationsquelleAutor
  2. 359

    [Modifier: Fonctionne sur Ubuntu 14.04: /usr/bin/time -v command assurez-vous d'utiliser le chemin d'accès complet.]

    Ressemble /usr/bin/time ne vous donner cette info, si vous passez -v (c'est sur Ubuntu 8.10). Voir, par exemple, Maximum resident set size ci-dessous:

    $ /usr/bin/time-v ls /
.... 
Commande de minuterie: "ls /" 
L'utilisateur le temps (en secondes): 0.00 
Système de temps (en secondes): 0.01 
% De CPU ce travail a obtenu: 250% 
Écoulé (horloge murale) temps (h:mm:ss ou m:ss): 0:00.00 
Moyenne de texte partagé taille (ko): 0 
Moyenne de partage de données de taille (ko): 0 
La moyenne de la pile de la taille (ko): 0 
Totale moyenne taille (ko): 0 
Maximum résidente taille (ko): 0 
Résident moyen de définir la taille (ko): 0 
Majeur (nécessitant I/O) des défauts de page: 0 
Mineur (récupérer une image) les défauts de page: 315 
Volontaire des commutations de contexte: 2 
Involontaire des changements de contexte: 0 
Swaps: 0 
Système de fichiers entrées: 0 
Système de fichiers de sorties: 0 
Prise des messages envoyés: 0 
Prise de messages reçus: 0 
Les signaux délivrés: 0 
Taille de la Page (octets): 4096 
Statut de sortie: 0
    • Probablement, il retourne toujours 0 parce que ls n'est pas beaucoup. Essayez un CPU plus intensive de commande.
    • J'semblent toujours obtenir de zéro, même pour les grandes commandes.
    • moi aussi 🙁 au moins sur la taille de la pile, que je trouve étrange, que j'ai couru un appel récursif pour stack overflow..
    • À partir de la page de man: la Plupart des informations affichées par le temps est dérivé de la wait3(2) de l'appel système. Les chiffres sont seulement aussi bon que ceux retournés par wait3(2). Sur les systèmes qui n'ont pas de wait3(2) appel qui renvoie des informations d'état, le temps(2) de l'appel système est utilisé à la place. Cependant, il fournit beaucoup moins d'informations que wait3(2), sur les systèmes de rapports en temps la majorité des ressources à zéro.
    • "bash: -v: commande introuvable" signifie bash intercepte le temps d'utiliser son propre. /bin/time -v elle n'en résout.
    • Sur une autre distribution (CentOS 5.6, une RHEL dérivés), le Maximum de flux RSS élément est toujours non nul et semble raisonnable (c'est à dire plus grand pour les grandes tâches).
    • Fedora semble trop de travail.
    • Il serait intéressant de faire un rapide vérifier pour être sûr que la sortie de sens. Gnu temps a un bug où il fera rapport 4x l'utilisation réelle de la mémoire: stackoverflow.com/questions/10035232/...
    • vous donne des infos sur les OS, les ressources utilisées, cela inclut la quantité de mémoire partagée entre plusieurs processus. Il ne dit rien à propos de la mémoire consommée par le processus.
    • Est ce que quelqu'un succès avec time -v sur OS X?
    • Essayez time -l sur MacOS, donne le même résultat.
    • /usr/bin/time (aka GNU temps) 1.7 a un bug et n'a PAS de rapport précis utilisation maximale de la mémoire d'info: stackoverflow.com/a/10132854/62694
    • Vous avez besoin de la time TR / min pour obtenir /usr/bin/heure sur Redhat, à base de linuxes.
    • time 1.7-24 sur Ubuntu depuis le 23 Février '15 incorpore un correctif à la mémoire de reporting.
    • Cette méthode n'est pas précise. J'obtiens des résultats différents à chaque fois que je lance un complètement déterministe programme sur Linux 3.19. Le "maximum resident set size" champ est clairement affectée par d'autres choses en cours d'exécution sur le système.
    • $ \time -v ls / Fonctionne également.
    • La taille de la mémoire bug fix est dans Fedora temps package à partir de la version 1.7-39. Pour vérifier votre version: rpm -q time. Source; recherche #702826 dans la page.

    InformationsquelleAutor
  3. 94

    (Ce qui est déjà une réponse, la vieille question.. mais juste pour le record 🙂

    J'ai été inspiré par le Yang du script, et est venu avec ce petit outil, nommé memusg. J'ai simplement augmenté la fréquence d'échantillonnage de 0,1 à gérer beaucoup de court processus vivants. Au lieu de suivre un processus unique, j'ai fait de la mesure de flux rss somme des processus de groupe. (Oui, j'écris beaucoup de programmes qui travaillent ensemble), Il travaille actuellement sur Mac OS X et Linux. L'utilisation devait être similaire à celle de time:

    memusg ls -alR />/dev/null

    Il ne montre que le pic pour le moment, mais je suis intéressé par de légères extensions pour l'enregistrement des autres (approximative) des statistiques.

    Il est bon d'avoir un tel outil simple pour simplement prendre un coup d'oeil avant de commencer sérieusement le profilage.

    • tout ce qui utilise encore PS et ne sont bons qu'à déterminer observé haut de la mémoire. pas vraiment haut de la mémoire. vous pouvez toujours manquer quelque chose entre un intervalle à l'autre.
    • Quelles sont les unités de la sortie de la memusg script? Octets? Kilo-octets?
    • probablement en kilo-octets. Il a simplement montres les valeurs indiquées par ps -o rss= où rss est la mémoire réelle (résidente) taille du processus (en 1024 unités d'octets) de mon BSD page de man.
    • Alors quoi, qu'est ce que vous obtenez lorsque vous êtes à la mesure des échantillons.
    • quelque chose que le noyau déclenche à chaque fois qu'elle modifier l'allocation de la mémoire. je pense que c'est ce time -v utilise. mais je ne suis pas sûr à 100%. c'est comme dans la programmation lorsque vous utilisez un while(){ check(); wait();} si quelque chose se produit au cours de wait(), trop mauvais, vous l'avez perdu. l'autre façon est d'associer des événements et puis, vous obtenez un message à chaque fois que quelque chose se passe, de cette façon, vous ne perdez aucune information.
    • Le lien pour memusg donné dans la réponse semble être rompu. De toute façon, /usr/bin/temps cela très bien.
    • ⁺1 pour la possibilité de changer facilement de la mémoire à partir de flux RSS, par exemple VSZ, ou quoi que ce soit d'autre.
    • L'on a accepté la réponse devrait être le second, ce un travail, mais est obsolète à mon humble avis.

    InformationsquelleAutor
  4. 61

    Valgrind one-liner:

    valgrind --tool=massif --pages-as-heap=yes --massif-out-file=massif.out ./test.sh; grep mem_heap_B massif.out | sed -e 's/mem_heap_B=\(.*\)/\1/' | sort -g | tail -n 1

    Remarque l'utilisation de-pages-que-tas de mesurer toute la mémoire d'un processus. Plus d'infos ici: http://valgrind.org/docs/manual/ms-manual.html

    • time, Je vous quitte.
    • Pratique script, mais j'ai besoin de tri -g sur ma Slackware système (je présume que vous êtes à la recherche pour la valeur la plus élevée).
    • Je suis absent --pages-as-heap option dans valgrind-3.5.0 sur un centos 5.5 distribution. Aussi --trace-children pourrait être utile à valgrind. Je ne suis pas sûr de ce qu'il fait, mais je suppose que c'traces des processus enfants aussi.
    • +1 pour valgrind --massif. Vous pouvez également utiliser le ms_print outil qui vient avec elle pour la pratique de sortie (y compris ascii graphiques d'utilisation dans le temps)
    • Massif a beaucoup plus de ressources que les time si, au moins 10 fois plus de temps sur une commande comme ls.
    • Il est trop énorme en effet. Cette réponse doit mentionner le ralentir. La commande je veux mesurer prend normalement de 35 secondes. J'ai couru ce valgrind commande pour mesurer plus d'une demi-heure, et elle n'a pas encore terminé...
    • Un simple sommeil a pris plus de 100 MO!

    InformationsquelleAutor
  5. 28

    Peut-être (gnu) temps(1) déjà fait ce que vous voulez. Par exemple:

    $ /usr/bin/time -f "%P %M" command
43% 821248

    Mais d'autres outils de profilage peuvent donner des résultats plus précis en fonction de ce que vous cherchez.

    • Me semble que je reçois toujours des zéros avec cela, même pour les grosses commandes
    • J'obtiens des résultats variables, comme 400% 0, et 0% 0 sur le même programme.. peut-être est doit être exécuté pour de plus grandes périodes de temps pour être exact?
    • Je ne sais pas quoi penser. Le code ci-dessus est exactement ce que j'ai obtenu de l'exécution d'un latex de commande qui est arrivé à être dans l'histoire. Comme je l'ai dit, des résultats plus précis peuvent être obtenus avec d'autres outils.
    • Qui fonctionne au moins sur CentOS (et donc, je parie aussi RHEL) des systèmes. %P donne sans rapport avec la statistique (%de CPU) qui dépend du planificateur et est donc très variable.
    • étrangement pour moi, le "temps" de la commande devait être exécuté en utilisant le chemin d'accès exact, comme dans l'exemple, sinon il ne serait pas reconnaître l'option "-f".
    • est intégré dans la commande lors de l'utilisation de csh. Si vous utilisez le chemin d'accès exact, il vous permettra d'exécuter la commande externe. Autant que je sache, seule la version GNU prend en charge l'option de format.

    InformationsquelleAutor
  6. 18

    /usr/bin/heure peut-être est-ce que vous voulez, en fait. Quelque chose comme.

     /usr/bin/time --format='(%Xtext+%Ddata %Mmax)'

    Voir le temps(1) pour plus de détails...

    • Me semble que je reçois toujours des zéros avec cela, même pour les grosses commandes
    • Je reçois le même...
    • jes5199, Liran, en regardant les commentaires ci-dessus, il semble temps(1) peut être rompu pour la mémoire de rapports sur certains linuxes...
    • Sur Ubuntu 16.04, le texte et les données sont à zéro, mais max est non-nul, et produit d'ajouter de la valeur. Je suis heureux avec elle.
    • J'espère Mmax il signifie ce que nous voulons dire .... la page de man est un peu laconique à ce sujet
    InformationsquelleAutor
  7. 18

    Sur Linux:

    Utilisation /usr/bin/time -v <program> <args> et recherchez "Maximum resident set size".

    (À ne pas confondre avec le Bash time intégré dans la commande! Il faut donc utiliser la chemin d'accès complet, /usr/bin/time)

    Par exemple:

    > /usr/bin/time -v ./myapp
        User time (seconds): 0.00
        . . .
        Maximum resident set size (kbytes): 2792
        . . .

    Sur BSD, MacOS:

    Utilisation /usr/bin/time -l <program> <args>, recherche pour "maximum resident set size":

    >/usr/bin/time -l ./myapp
        0.01 real         0.00 user         0.00 sys
      1440  maximum resident set size
      . . .
    InformationsquelleAutor
  8. 16

    Si le processus s'exécute pour au moins un couple de secondes, puis vous pouvez utiliser le script bash suivant, qui va exécuter la ligne de commande, puis les imprimer sur la sortie stderr le pic de flux RSS (substitut pour rss tout autre attribut qui vous intéresse). C'est un peu léger, et ça marche pour moi avec le ps inclus dans Ubuntu 9.04 (que je ne peux pas dire pour time).

    #!/usr/bin/env bash
"$@" & # Run the given command line in the background.
pid=$! peak=0
while true; do
  sleep 1
  sample="$(ps -o rss= $pid 2> /dev/null)" || break
  let peak='sample > peak ? sample : peak'
done
echo "Peak: $peak" 1>&2
    • L'inconvénient majeur de cette méthode est que, si le processus alloue de la mémoire pour une courte période (par exemple, près de la fin), cela peut ne pas être détecté. La réduction du temps de sommeil peut aider un peu.
    InformationsquelleAutor
  9. 15

    Sur MacOS Sierra utilisation:

    /usr/bin/time -l commandToMeasure

    Vous pouvez utiliser grep prendre ce que vous voulez peut-être.

    • Ce! J'ai vraiment passé une heure à essayer d'obtenir des Instruments.app et dtrace pour me donner un profil de la mémoire avec l'intégrité du système allumé (ne peut pas l'éteindre), alors que j'avais besoin juste cette simple commande. Une petite remarque, vous pouvez utiliser command time -l au lieu de /usr/bin/time -l qui sera la cause de votre shell pour en réalité appeler un binaire appelé time au lieu de la fonction builtin. (Oui, command n'est pas un espace réservé, command time est différent que de simplement time.)
    • Aussi \time -l œuvres.
    InformationsquelleAutor
  10. 8

    Bien, si vous voulez vraiment montrer la mémoire de crête et quelques statistiques plus détaillées, je vous recommandons d'utiliser un profiler comme valgrind. Une belle valgrind avant la fin de l' alleyoop.

    InformationsquelleAutor
  11. 6
    time -f '%M' <run_program>
    InformationsquelleAutor
  12. 5

    Vous pouvez utiliser un outil comme Valgrind pour ce faire.

    InformationsquelleAutor
  13. 5

    Est ici (sur la base des autres réponses) un script très simple qui regarde déjà un processus en cours d'exécution. Vous avez juste à le faire fonctionner avec le pid du processus que vous voulez regarder comme argument:

    #!/usr/bin/env bash

pid=$1

while ps $pid >/dev/null
do
    ps -o vsz= ${pid}
    sleep 1
done | sort -n | tail -n1

    Exemple d'utilisation:

    max_mem_usage.sh 23423
    InformationsquelleAutor
  15. 1

    Heaptrack est KDE outil qui dispose d'une interface utilisateur graphique et de texte de l'interface. Je le trouve plus adapté que valgrind pour comprendre l'utilisation de la mémoire d'un processus, car il fournit plus de détails et flamegraphs. Il est aussi plus rapide car il fait moins de vérifier que valgrind. Et il vous donne l'utilisation maximale de la mémoire.

    De toute façon, le suivi de flux rss et vss est trompeuse parce que les pages puissent être partagées, c'est pourquoi que memusg. Ce que vous devez vraiment faire est de suivre la somme de Pss dans /proc/[pid]/smaps ou de l'utilisation pmap. GNOME system-monitor utilisé pour le faire mais c'était trop cher.

    InformationsquelleAutor
  16. 1

    Ré-inventer la roue à la main script bash. Rapide et propre.

    Mon cas d'utilisation: je voulais surveiller une machine linux qui a moins de RAM et je voulais prendre un instantané de chaque récipient d'utilisation lorsqu'il s'exécute dans une utilisation intensive.

    #!/usr/bin/env bash

threshold=$1

echo "$(date '+%Y-%m-%d %H:%M:%S'): Running free memory monitor with threshold $threshold%.."

while(true)
    freePercent=`free -m | grep Mem: | awk '{print ($7/$2)*100}'`    
  do

  if (( $(awk 'BEGIN {print ("'$freePercent'" < "'$threshold'")}') ))
  then
       echo "$(date '+%Y-%m-%d %H:%M:%S'): Free memory $freePercent% is less than $threshold%"
       free -m
       docker stats --no-stream
       sleep 60  
       echo ""  
  else
       echo "$(date '+%Y-%m-%d %H:%M:%S'): Sufficient free memory available: $freePercent%"
  fi
  sleep 30

done

    Exemple de sortie:

    2017-10-12 13:29:33: Running free memory monitor avec seuil de 30%..

    2017-10-12 13:29:33: de Suffisamment de mémoire libre disponible: 69.4567%

    2017-10-12 13:30:03: Suffisamment de mémoire libre disponible: 69.4567%

    2017-10-12 16:47:02: libérer de la mémoire 18.9387% moins de 30%

    votre commande personnalisée de sortie

    InformationsquelleAutor
  17. 1

    Sur macOS, vous pouvez utiliser DTrace à la place. Les "Instruments" de l'app est une belle interface, il est livré avec XCode autant que je sache.

    InformationsquelleAutor
  18. 0

    'htop" est mieux de commande pour voir quel processus est à l'aide de la quantité de RAM.....

    pour plus de détails
    http://manpages.ubuntu.com/manpages/precise/man1/htop.1.html

    • htop ne liste pas l'utilisation de POINTE. Seule l'utilisation ACTUELLE. (Sauf si vous savez quelque chose que je ne. Comme je l'ai regardé hier dans htop pour ce scénario exact.)
    InformationsquelleAutor
  19. -2

    Assurez-vous de répondre à la question. Fournir des détails et de partager vos recherches!

    Désolé, je suis ici la première fois et ne peut que poser des questions ...

    Utilisé suggéré:

    valgrind --tool=massif --pages-que-tas=oui --massif-out-file=massif.out ./test.sh; grep mem_heap_B massif.out | sed-e 's/mem_heap_B=(.*)/\1/' | tri -g | tail-n 1

    alors
    grep mem_heap_B massif.hors
    ...
    mem_heap_B=1150976
    mem_heap_B=1150976
    ...

    c'est très différent de ce "top" commande affiche au même moment :

    14673 gu27mox 20 0 3280404 468380 19176 R 100.0 2.9 6:08.84 pwanew_3pic_com

    ce sont mesurées en unités de valgrind ??

    La

    /usr/bin/time-v ./test.sh

    n'a jamais répondu - vous devez nourrir directement exécutable /usr/bin/time comme:

    /usr/bin/time-v pwanew_3pic_compass_2008florian3_dfunc.statique card_0.100-0.141_31212_resubmit1.dat_1.140_1.180 1.140 1.180 31212

    Command being timed: "pwanew_3pic_compass_2008florian3_dfunc.static card_0.100-0.141_31212_resubmit1.dat_1.140_1.180 1.140 1.180 31212"

User time (seconds): 1468.44
System time (seconds): 7.37
Percent of CPU this job got: 99%
Elapsed (wall clock) time (h:mm:ss or m:ss): 24:37.14
Average shared text size (kbytes): 0
Average unshared data size (kbytes): 0
Average stack size (kbytes): 0
Average total size (kbytes): 0
Maximum resident set size (kbytes): 574844
Average resident set size (kbytes): 0
Major (requiring I/O) page faults: 74
Minor (reclaiming a frame) page faults: 468880
Voluntary context switches: 1190
Involuntary context switches: 20534
Swaps: 0
File system inputs: 81128
File system outputs: 1264
Socket messages sent: 0
Socket messages received: 0
Signals delivered: 0
Page size (bytes): 4096
Exit status: 0
    InformationsquelleAutor