Como outros já apontaram corretamente, é difícil controlar a memória real usada por um processo, com regiões compartilhadas e com arquivos mapeados e outros enfeites.
Se você é um experimentador, pode executar valgrind e massif . Isso pode ser 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, isso fornecerá uma boa representação do uso real da memória dinâmica de um processo. Mas esse experimento pode ser "envenenado".
Para complicar, o Linux permite que você comprometa demais sua memória. Quando você malloc () memória, você está declarando sua intenção de consumir memória. Mas a alocação não acontece realmente até você escrever um byte em uma nova página da sua "RAM" alocada. Você pode provar isso escrevendo e executando um pequeno programa em C da seguinte maneira:
// 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 ganhar 16 GB de memória! (Não, na verdade não).
Observe que topvocê vê "VIRT" como 16.004G, mas% MEM é 0.0
Execute isso novamente com valgrind:
# Shell:
valgrind --tool=massif ./test &
sleep 36
ms_print massif.out.$! | head -n 30
E o maciço diz "soma de todas as atribuições () = 16GB". Então isso não é muito interessante.
MAS, se você executá-lo em um processo são :
# 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 77 KB de heap.
Por que se esforçar tanto para obter apenas o uso de 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 uma sobrecarga constante para um processo. De fato, as invocações subsequentes do processo quase vêm de graça.
Além disso, compare e contraste o seguinte:
MMAP () um arquivo de 1 GB. Seu VMSize será de 1 + GB. Mas seu Tamanho do conjunto residente será apenas as partes do arquivo em que você causou a paginação (desreferenciando um ponteiro para essa região). E se você "ler" o arquivo inteiro, no momento em que chegar ao fim, o kernel poderá já ter paginado o início (isso é fácil de fazer, porque o kernel sabe exatamente como / onde substituir essas páginas, se desreferenciado novamente ) Em ambos os casos, nem o VMSize nem o RSS são um bom indicador do "uso" da sua memória. Você realmente não fez nada com malloc ().
Por outro lado, Malloc () e toque em MUITA memória - até que sua memória seja trocada para o disco. Portanto, sua memória alocada agora excede o seu RSS. Aqui, o seu VMSize pode começar a lhe dizer algo (seu processo possui mais memória do que o que realmente reside na sua RAM). Mas ainda é difícil diferenciar entre VMs que são páginas compartilhadas e VMs que são dados trocados.
É aqui que o valgrind / maciço se torna interessante. Ele mostra o que você alocou intencionalmente (independentemente do estado de suas páginas).
htopautor a uma pergunta semelhante eu tive no outro dia ... Como calcular o uso de memória de / proc / meminfo (como htop)