Como outros apontaram corretamente, é difícil entender a memória real usada por um processo, o que acontece com regiões compartilhadas, arquivos mmap e outros.
Se você é um experimentador, pode executar valgrind e maciço . Isso pode ficar um pouco pesado para o usuário casual, mas você terá uma idéia do comportamento da memória de um aplicativo ao longo do tempo. Se um aplicativo malloc () é exatamente o que ele precisa, então isso lhe dará uma boa representação do uso de memória dinâmica real de um processo. Mas esta experiência pode ser "envenenada".
Para complicar, o Linux permite que você supercomprometa sua memória. Quando você malloc () memória, você está afirmando sua intenção de consumir memória. Mas a alocação realmente não acontece até que você escreva um byte em uma nova página da sua "RAM" alocada. Você pode provar isso para si mesmo escrevendo e executando um pequeno programa em C da seguinte forma:
// 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 $!
Execute isso em uma máquina com menos de 16 GB de RAM e, voila !, você acabou de marcar 16 GB de memória! (não, na verdade não).
Aviso em top você vê "VIRT" como 16.004G mas% MEM é 0.0
Execute novamente com valgrind:
# Shell:
valgrind --tool=massif ./test &
sleep 36
ms_print massif.out.$! | head -n 30
E massif diz "soma de todas as alocações () = 16GB". Então isso não é muito interessante.
MAS, se você executá-lo em um processo sane :
# 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
E aqui vemos (muito empiricamente e com muita confiança) que o compilador alocou 77KB de heap.
Por que tentar tanto usar apenas o heap? Porque todos os objetos compartilhados e seções de texto que um processo usa (neste exemplo, o compilador) não são muito interessantes. Eles são sobrecarga constante para um processo. De fato, as invocações subseqüentes do processo quase chegam "livres".
Além disso, compare e contraste o seguinte:
MMAP () um arquivo de 1GB. Seu VMSize será 1 GB. Mas o tamanho do conjunto de residentes será apenas as partes do arquivo que você fez com que paginasse (desreferindo um ponteiro para essa região). E se você "ler" todo o arquivo, então, quando você chegar ao fim, o kernel pode já ter paginado os primórdios (isso é fácil de fazer porque o kernel sabe exatamente como / onde substituir essas páginas se não for referenciado novamente ). Em ambos os casos, nem VMSize nem RSS são um bom indicador de sua "utilização" de memória. Você não fez nada de malloc ().
Por contraste, Malloc () e toca LOTES de memória - até que sua memória seja trocada para o disco. Então sua memória alocada agora excede seu RSS. Aqui, o seu VMSize pode começar a lhe dizer algo (seu processo possui mais memória do que o que realmente está na sua RAM). Mas ainda é difícil diferenciar entre VMs que são páginas compartilhadas e VM que são dados trocados.
É aqui que o valgrind / maciço fica interessante. Mostra o que você intencionalmente alocou (independentemente do estado de suas páginas).
