Comment mesurer sous Linux le pic de mémoire d'une application après la fin

Comment mesurer la mémoire maximale d'une application exécutée sous Linux?

J'exécute cette application en lot, donc je ne peux pas utiliser RSS car, elle signale la mémoire actuelle. J'ai besoin que la mémoire de pointe utilisée par l'application soit signalée à la fin.

Le VmPeak n'est pas non plus une solution, car il rapporte la mémoire allouée et ne calcule pas non plus à partir du vrai Ram mais aussi à partir du disque dur.

Voici 2 méthodes pour suivre l'utilisation maximale de la mémoire d'un processus.

Sirupeux

Je n'ai pas utilisé cet outil mais cela ressemble à ce que vous recherchez. Ça s'appelle Syrupy .

La description

Syrupy est un script Python qui prend régulièrement des instantanés de la mémoire et de la charge CPU d'un ou plusieurs processus en cours d'exécution, afin de créer dynamiquement un profil de leur utilisation des ressources système.

Exemple

$ syrupy.py myprog

  PID DATE        TIME     ELAPSED  CPU   MEM    RSS   VSIZE
14634 2008-10-10  20:45:25   00:00  0.0   0.0   2996    6680
14634 2008-10-10  20:45:26   00:01  105   0.2   7804   12592
14634 2008-10-10  20:45:27   00:02  103   0.2   8996   13776
14634 2008-10-10  20:45:28   00:03  103   0.2  10468   15348
14634 2008-10-10  20:45:29   00:04  103   0.3  11412   16396
14634 2008-10-10  20:45:30   00:05  104   0.3  12492   17444

/usr/bin/time -v

Oui, ironiquement, la commande GNU time peut vous donner l'utilisation maximale de la mémoire d'un processus. Il rend compte de la mémoire de pointe comme ceci: Maximum resident set size (kbytes).

Exemple

$ /usr/bin/time -v ~/projects/prime_numbers/eratosthenes_prime_sieve.pl 10 1000000
...

    Command being timed: "/home/saml/projects/prime_numbers/eratosthenes_prime_sieve.pl 10 1000000"
    User time (seconds): 1.12
    System time (seconds): 0.05
    Percent of CPU this job got: 54%
    Elapsed (wall clock) time (h:mm:ss or m:ss): 0:02.19
    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): 79304
    Average resident set size (kbytes): 0
    Major (requiring I/O) page faults: 0
    Minor (reclaiming a frame) page faults: 20014
    Voluntary context switches: 83
    Involuntary context switches: 274
    Swaps: 0
    File system inputs: 0
    File system outputs: 0
    Socket messages sent: 0
    Socket messages received: 0
    Signals delivered: 0
    Page size (bytes): 4096
    Exit status: 0

Références

• Utilisation maximale de la mémoire d'un processus Linux / Unix
• mesure de la mémoire de pointe d'un processus de longue durée sous linux

Même si le sujet est assez ancien, je veux partager un autre projet qui a émergé de la fonctionnalité du noyau cgroups Linux.

https://github.com/gsauthof/cgmemtime :

cgmemtime mesure l'utilisation de la mémoire haute tension RSS + CACHE d'un processus et de ses processus descendants.

Pour ce faire, il place le processus dans son propre groupe de contrôle.

Par exemple, le processus A alloue 10 MiB et bifurque un enfant B qui alloue 20 MiB et qui bifurque un enfant C qui alloue 30 MiB. Les trois processus partagent une fenêtre de temps où leurs allocations entraînent une utilisation de la mémoire RSS (taille de l'ensemble résident) correspondante.

La question est maintenant: combien de mémoire est réellement utilisée à la suite de l'exécution de A?

Réponse: 60 Mio

cgmemtime est l'outil pour répondre à ces questions.

Des exemples d'utilisation seraient:

$ sudo ./cgmemtime --setup -g <myusergroup> --perm 775

$ ./cgmemtime ./testa x 10 20 30
Parent PID is 27189
Allocating 10 MiBs
New Child: 27193
Allocating 20 MiBs
New Child: 27194
Allocating 30 MiBs
Child user:    0.000 s
Child sys :    0.005 s
Child wall:    6.006 s
Child high-water RSS                    :      11648 KiB
Recursive and acc. high-water RSS+CACHE :      61840 KiB

$ ./cgmemtime python -c 'print range(100000)[48517]'
48517
Child user:    0.014 s
Child sys :    0.014 s
Child wall:    0.029 s
Child high-water RSS                    :       9948 KiB
Recursive and acc. high-water RSS+CACHE :       5724 KiB