Как правильно отметили другие, трудно получить представление о фактической памяти, используемой процессом, с общими областями, файлами mmap и тому подобным.
Если вы экспериментатор, вы можете запустить valgrind и массив . Это может быть немного тяжелым для обычного пользователя, но вы со временем получите представление о поведении памяти в приложении. Если приложение malloc () именно то, что ему нужно, это даст вам хорошее представление о реальном динамическом использовании памяти процессом. Но этот эксперимент можно «отравить».
Чтобы усложнить ситуацию, Linux позволяет вам перегружать память. Когда вы используете malloc () памяти, вы заявляете о своем намерении использовать память. Но на самом деле распределение не происходит до тех пор, пока вы не напишите байт на новую страницу вашего выделенного «ОЗУ». Вы можете доказать это себе, написав и запустив небольшую C-программу, например:
// 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 $!
Запустите это на машине с менее чем 16 ГБ ОЗУ и, вуаля!, Вы только что набрали 16 ГБ памяти! (нет, не совсем).
Обратите внимание, что topвы видите «VIRT» как 16.004G, но% MEM равен 0.0
Запустите это снова с valgrind:
# Shell:
valgrind --tool=massif ./test &
sleep 36
ms_print massif.out.$! | head -n 30
И массив говорит "сумма всех allocs () = 16GB". Так что это не очень интересно.
НО, если вы запустите его в нормальном процессе:
# 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
И здесь мы видим (очень эмпирически и с очень высокой достоверностью), что компилятор выделил 77KB кучи.
Зачем так стараться, чтобы использовать только кучу? Потому что все общие объекты и текстовые разделы, которые использует процесс (в данном примере, компилятор), не очень интересны. Они постоянные накладные расходы на процесс. Фактически, последующие вызовы процесса почти приходят бесплатно.
Кроме того, сравните и сопоставьте следующее:
MMAP () файл объемом 1 ГБ. Ваш VMSize будет 1 + ГБ. Но ваш размер резидентного набора будет только теми частями файла, в который вы были помещены (путем разыменования указателя на этот регион). И если вы «прочитаете» весь файл, то к тому времени, когда вы дойдете до конца, ядро, возможно, уже выровняло начало (это легко сделать, потому что ядро точно знает, как / где заменить эти страницы, если разыменоваться снова ). В любом случае, ни VMSize, ни RSS не являются хорошим индикатором использования вашей памяти. Вы на самом деле ничего не использовали malloc ().
В отличие от Malloc () и коснитесь много памяти - пока ваша память не будет перенесена на диск. Таким образом, ваша выделенная память теперь превышает ваши RSS. Здесь ваш VMSize может начать вам что-то говорить (вашему процессу принадлежит больше памяти, чем на самом деле находится в вашей памяти). Но все еще трудно различить ВМ, которая является общими страницами, и ВМ, которая обменивается данными.
Это где Вальгринд / массив становится интересным. Он показывает, что вы намеренно распределили (независимо от состояния ваших страниц).
htopавтора на один похожий вопрос, который у меня был на днях ... Как рассчитать использование памяти из / proc / meminfo (как htop)