Як правильно вказали інші, важко отримати обробку фактичної пам’яті, яка використовується процесом, що стосується спільних областей, а також файлів mmap'ed і чого іншого.
Якщо ви експериментатор, ви можете запускати валлінг і масив . Це може стати важким для випадкового користувача, але ви зрозумієте поведінку програми в пам'яті з часом. Якщо додаток 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
І масив каже "сума всіх алоків () = 16 ГБ". Тож це не дуже цікаво.
АЛЕ, якщо ви запускаєте його у розумному процесі:
# 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
І тут ми бачимо (дуже емпірично і з дуже високою впевненістю), що компілятор виділив 77 КБ купи.
Чому так важко намагатися отримати просто купівельне використання? Тому що всі спільні об’єкти та текстові розділи, які використовує процес (у цьому прикладі компілятор), не дуже цікаві. Вони постійні накладні витрати для процесу. Насправді, наступні виклики цього процесу майже виходять "безкоштовними".
Також порівняйте та порівняйте наступне:
MMAP () файл 1 Гб. Ваш VMSize становитиме 1 + ГБ. Але Ви розміром встановленого резидента будуть лише ті частини файлу, які ви спричинили для того, щоб бути створеними на сторінці (шляхом перенаправлення вказівника на цей регіон). І якщо ви "прочитали" весь файл тоді, до того часу, як ви досягнете кінця, ядро, можливо, вже започаткувало початки (це легко зробити, тому що ядро точно знає, як / де замінити ці сторінки, якщо знову буде відзначено) ). В будь-якому випадку ні VMSize, ні RSS не є хорошим показником використання вашої пам'яті. Ви фактично нічого не malloc () не редагували.
Навпаки, Malloc () і торкніться ЛОТИ пам'яті - доки ваша пам'ять не перейде на диск. Тож ваша виділена пам'ять тепер перевищує ваш RSS. Тут ваш VMSize може почати щось вам повідомляти (ваш процес має більше пам’яті, ніж те, що насправді знаходиться у вашій ОЗУ). Але все ще важко розмежовувати VM, що використовується спільними сторінками, і VM, що обмінюється даними.
Тут стає цікавим вальгринд / масив. Він показує, що ви навмисно виділили (незалежно від стану ваших сторінок).
htopавтора на одне подібне запитання, яке було у мене днями ... Як обчислити використання пам'яті з / proc / meminfo (як htop)