Question Comment mesurer l'utilisation réelle de la mémoire d'une application ou d'un processus?


Cette question est couverte ici en détail.

Comment mesurez-vous l'utilisation de la mémoire d'une application ou d'un processus sous Linux?

De l'article de blog de Comprendre l'utilisation de la mémoire sous Linux, ps n'est pas un outil précis à utiliser pour cette intention.

Pourquoi ps est faux"

Selon la façon dont vous le regardez, ps ne rapporte pas l'utilisation réelle de la mémoire des processus. Ce qu'il fait, c'est montrer combien de mémoire réelle chaque processus prendrait si c'était le seul processus en cours. Bien sûr, une machine Linux typique a plusieurs dizaines de processus en cours d'exécution à tout moment, ce qui signifie que les numéros VSZ et RSS signalés par ps sont presque définitivement faux.


586
2017-09-25 03:19


origine


Réponses:


Avec ps ou des outils similaires vous obtiendrez seulement la quantité de pages de mémoire allouées par ce processus. Ce nombre est correct, mais:

  • ne reflète pas la quantité réelle de mémoire utilisée par l'application, seule la quantité de mémoire qui lui est réservée

  • peut être trompeur si les pages sont partagées, par exemple par plusieurs threads ou en utilisant des bibliothèques liées dynamiquement

Si vous voulez vraiment savoir quelle quantité de mémoire votre application utilise réellement, vous devez l'exécuter dans un profileur. Par exemple, valgrind peut vous donner des informations sur la quantité de mémoire utilisée et, plus important encore, sur d'éventuelles fuites de mémoire dans votre programme. L'outil profileur de tas de valgrind s'appelle 'massif':

Massif est un profileur de tas. Il effectue un profilage détaillé du tas en prenant des instantanés réguliers du segment de mémoire d'un programme. Il produit un graphique montrant l'utilisation du tas dans le temps, y compris des informations sur les parties du programme qui sont responsables du plus grand nombre d'allocations de mémoire. Le graphique est complété par un fichier texte ou HTML qui inclut plus d'informations pour déterminer où le plus de mémoire est alloué. Massif exécute des programmes environ 20 fois plus lentement que la normale.

Comme expliqué dans le documentation valgrind, vous devez exécuter le programme via valgrind:

valgrind --tool=massif <executable> <arguments>

Massif écrit un cliché d'instantanés d'utilisation de la mémoire (par ex. massif.out.12345). Ceux-ci fournissent, (1) une chronologie de l'utilisation de la mémoire, (2) pour chaque instantané, un enregistrement de où dans votre mémoire de programme a été alloué. Un excellent outil graphique pour analyser ces fichiers est massif-visualiseur. Mais j'ai trouvé ms_print, un simple outil textuel livré avec valgrind, pour être d'une grande aide déjà.

Pour trouver des fuites de mémoire, utilisez le (par défaut) memcheck outil de valgrind.


297
2017-09-25 03:33



Essaie le pmap commander:

sudo pmap -x <process pid>

222
2018-05-12 04:08



Difficile à dire à coup sûr, mais voici deux choses «proches» qui peuvent aider.

$ ps aux 

vous donnera la taille virtuelle (VSZ)

Vous pouvez également obtenir des statistiques détaillées à partir du système de fichiers / proc en allant à /proc/$pid/status

Le plus important est le VmSize, qui devrait être proche de ce que ps aux donne.

/ proc / 19420 $ statut du chat
Nom: firefox
Etat: S (dormant)
Tgid: 19420
Pid: 19420
PPid: 1
TracerPid: 0
Uid: 1000 1000 1000 1000
Gid: 1000 1000 1000 1000
FDSize: 256
Groupes: 4 6 20 24 25 29 30 44 46 107 109 115 124 1000
VmPeak: 222956 Ko
VmSize: 212520 kB
VmLck: 0 kB
VmHWM: 127912 kB
VmRSS: 118768 Ko
VmData: 170180 Ko
VmStk: 228 kB
VmExe: 28 kB
VmLib: 35424 kB
VmPTE: 184 kB
Discussions: 8
SigQ: 0/16382
SigPnd: 0000000000000000
ShdPnd: 0000000000000000
SigBlk: 0000000000000000
SigIgn: 0000000020001000
SigCgt: 000000018000442f
CapInh: 0000000000000000
CapPrm: 0000000000000000
CapEff: 0000000000000000
Cpus_allowed: 03
Mems_allowed: 1
voluntary_ctxt_switches: 63422
Commutateurs_ctxt non-volontaires: 7171


176
2017-09-25 03:49



Dans les versions récentes de Linux, utilisez le smaps sous-système. Par exemple, pour un processus avec un PID de 1234:

cat /proc/1234/smaps

Il vous dira exactement combien de mémoire il utilise à ce moment-là. Plus important encore, il va diviser la mémoire en privé et partagé, de sorte que vous pouvez dire combien de votre mémoire exemple du programme utilise, sans inclure la mémoire partagée entre plusieurs instances du programme.


123
2017-08-06 09:43



Il n'y a pas de moyen facile de calculer cela. Mais certaines personnes ont essayé d'obtenir de bonnes réponses:


119
2017-09-25 13:46



Utilisation smem, qui est une alternative à ps qui calcule l'USS et le PSS par processus. Ce que vous voulez, c'est probablement le PSS.

  • USS - Taille de l'ensemble unique. C'est la quantité de mémoire non partagée propre à ce processus (pensez-y U pour unique Mémoire). Il n'inclut pas la mémoire partagée. Ainsi, cela va en dessous de-rapporte la quantité de mémoire utilisée par un processus, mais est utile lorsque vous souhaitez ignorer la mémoire partagée.

  • PSS - Taille de l'ensemble proportionnel. Voici ce que tu veux. Il ajoute la mémoire unique (USS), ainsi qu'une partie de sa mémoire partagée divisée par le nombre d'autres processus partageant cette mémoire. Ainsi, il vous donnera une représentation précise de la quantité de mémoire physique réelle utilisée par processus - avec la mémoire partagée réellement représentée comme partagée. Pensez à la P être pour physique Mémoire.

Comment cela se compare à RSS tel que rapporté par ps et d'autres utilités:

  • RSS - Taille de l'ensemble résident. C'est la quantité de mémoire partagée plus la mémoire non partagée utilisée par chaque processus. Si des processus partagent la mémoire, cela plus de-rapport la quantité de mémoire réellement utilisée, car la même mémoire partagée sera comptée plus d'une fois - apparaissant de nouveau dans chaque autre processus qui partage la même mémoire. Ainsi c'est équitablement peu fiable, en particulier lorsque les processus à haute mémoire ont beaucoup de forks - ce qui est courant dans un serveur, avec des processus comme Apache ou PHP (fastcgi / FPM).

Remarque: smem peut également (facultativement) afficher des graphiques tels que des camemberts et autres. OMI, vous n'avez pas besoin de ça. Si vous voulez juste l'utiliser depuis la ligne de commande comme si vous utilisiez ps -A v, vous n'avez pas besoin d'installer la dépendance recommandée par python-matplotlib.


86
2017-12-06 23:10



Qu'en est-il de time ?

Pas le Frapper intégré time mais celui que vous pouvez trouver avec which time, par exemple /usr/bin/time

Voici ce qu'il couvre, sur un simple ls :

$ /usr/bin/time --verbose ls
(...)
Command being timed: "ls"
User time (seconds): 0.00
System time (seconds): 0.00
Percent of CPU this job got: 0%
Elapsed (wall clock) time (h:mm:ss or m:ss): 0:00.00
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): 2372
Average resident set size (kbytes): 0
Major (requiring I/O) page faults: 1
Minor (reclaiming a frame) page faults: 121
Voluntary context switches: 2
Involuntary context switches: 9
Swaps: 0
File system inputs: 256
File system outputs: 0
Socket messages sent: 0
Socket messages received: 0
Signals delivered: 0
Page size (bytes): 4096
Exit status: 0

49
2017-11-04 21:51