Comme d'autres l'ont souligné à juste titre, il est difficile de connaître la mémoire réellement utilisée par un processus, les régions partagées, les fichiers mmap'ed, etc.
Si vous êtes un expérimentateur, vous pouvez exécuter valgrind et massif . Cela peut paraître un peu lourd pour l'utilisateur occasionnel, mais vous aurez une idée du comportement de la mémoire d'une application au fil du temps. Si une application malloc () correspond exactement à ce dont elle a besoin, cela vous donnera une bonne représentation de l'utilisation réelle de la mémoire dynamique d'un processus. Mais cette expérience peut être "empoisonnée".
Pour compliquer les choses, Linux vous permet de surcharger votre mémoire. Lorsque vous malloc (), vous indiquez votre intention de consommer de la mémoire. Mais l'allocation ne se produit vraiment que lorsque vous écrivez un octet dans une nouvelle page de votre "RAM" allouée. Vous pouvez vous le prouver en écrivant et en exécutant un petit programme C comme ceci:
// test.c
#include <malloc.h>
#include <stdio.h>
#include <unistd.h>
int main() {
void *p;
sleep(5)
p = malloc(16ULL*1024*1024*1024);
printf("p = %p\n", p);
sleep(30);
return 0;
}
# Shell:
cc test.c -o test && ./test &
top -p $!
Exécutez cette application sur une machine disposant de moins de 16 Go de RAM et, voila!, Vous venez de bénéficier de 16 Go de mémoire! (non, pas vraiment).
Notez que topvous voyez "VIRT" comme 16.004G mais% MEM est 0.0
Exécutez ceci à nouveau avec valgrind:
# Shell:
valgrind --tool=massif ./test &
sleep 36
ms_print massif.out.$! | head -n 30
Et massif dit "somme de tous les allocs () = 16 Go". Donc ce n'est pas très intéressant.
MAIS, si vous l'exécutez sur un processus sain :
# Shell:
rm test test.o
valgrind --tool=massif cc test.c -o test &
sleep 3
ms_print massif.out.$! | head -n 30
--------------------------------------------------------------------------------
Command: cc test.c -o test
Massif arguments: (none)
ms_print arguments: massif.out.23988
--------------------------------------------------------------------------------
KB
77.33^ :
| #:
| :@::@:#:
| :::::@@::@:#:
| @:: :::@@::@:#:
| ::::@:: :::@@::@:#:
| ::@:::@:::::@:: :::@@::@:#:
| @::@:::@:::::@:: :::@@::@:#:
| @::@:::@:::::@:: :::@@::@:#:
| :@@@@@@@@@@@@@@@@@@@@:@::@:::@:::::@:: :::@@::@:#:
| :@@ :@::@:::@:::::@:: :::@@::@:#:
| :@:@@ :@::@:::@:::::@:: :::@@::@:#:
| :@:@@ :@::@:::@:::::@:: :::@@::@:#:
| :@@:@@ :@::@:::@:::::@:: :::@@::@:#:
| :@@:@@ :@::@:::@:::::@:: :::@@::@:#:
| :@::::@@:@@ :@::@:::@:::::@:: :::@@::@:#:
| :::::@::::@@:@@ :@::@:::@:::::@:: :::@@::@:#:
| :::::::@::::@@:@@ :@::@:::@:::::@:: :::@@::@:#:
| ::::::::@::::@@:@@ :@::@:::@:::::@:: :::@@::@:#:
| ::::::::@::::@@:@@ :@::@:::@:::::@:: :::@@::@:#:
0 +----------------------------------------------------------------------->Mi
0 1.140
Et nous voyons ici (très empiriquement et avec une très grande confiance) que le compilateur a alloué 77 Ko de tas.
Pourquoi essayer si fort d’obtenir une utilisation juste du tas? Parce que tous les objets partagés et les sections de texte utilisés par un processus (dans cet exemple, le compilateur) ne sont pas très intéressants. Ils sont des frais généraux constants pour un processus. En fait, les invocations ultérieures du processus sont presque "gratuites".
En outre, comparez les éléments suivants:
MMAP () un fichier de 1 Go. Votre VMSize sera 1 + GB. Mais votre taille de groupe de résidents ne sera que les parties du fichier dans lesquelles vous avez paginé (en supprimant la référence d'un pointeur vers cette région). Et si vous "lisez" l'intégralité du fichier, le noyau aura peut-être déjà commencé à paginer au début (c'est facile à faire, car le noyau sait exactement comment et où remplacer ces pages si elles sont à nouveau déréférencées ). Dans les deux cas, ni VMSize ni RSS ne sont un bon indicateur de votre "utilisation" en mémoire. Vous n'avez rien fait de malloc ().
En revanche, Malloc () et appuyez sur BEAUCOUP de mémoire - jusqu'à ce que votre mémoire soit échangée sur le disque. Donc, votre mémoire allouée dépasse maintenant votre RSS. Ici, votre VMSize pourrait commencer à vous dire quelque chose (votre processus possède plus de mémoire que ce qui se trouve réellement dans votre RAM). Cependant, il est toujours difficile de faire la distinction entre une machine virtuelle composée de pages partagées et une machine virtuelle échangeant des données.
C'est là que valgrind / massif devient intéressant. Il vous montre ce que vous avez intentionnellement alloué (quel que soit l'état de vos pages).
htopauteur à une question similaire que j'avais posée l'autre jour ... Comment calculer l'utilisation de la mémoire à partir de / proc / meminfo (comme htop)