анализ утечки памяти с верхом

Question

Я хотел бы использовать инструмент «top» для анализа потребления памяти и возможных утечек памяти процесса.Для этого я написал эту программу (имя-программы: memoryTest):

int main(){
char* q;
for(int i=0; i<100; i++){
    q = (char*) malloc(1024); 
    sleep(1);
}
return 0;   

}

Теперь я могу смотреть эту программу с помощью top, фильтруя ее с помощью опции «o» испецификация фильтра "COMMAND = memoryTest" после указанного процесса, однако я не вижу изменений в потреблении памяти процессом.У меня здесь глупая ошибка?

Answer 1

со страницы руководства malloc:

Обычно malloc () выделяет память из кучи и корректирует размер кучи по мере необходимости, используя sbrk (2).При выделении блоков памяти, больших, чем байты MMAP_THRESHOLD, реализация malloc () glibc выделяет память как частное анонимное отображение, используя mmap (2).MMAP_THRESHOLD по умолчанию составляет 128 кБ, но настраивается с помощью mallopt (3).До Linux 4.7 выделения, выполняемые с использованием mmap (2), не зависели от ограничения ресурса RLIMIT_DATA;начиная с Linux 4.7, это ограничение также применяется для распределений, выполняемых с помощью mmap (2).

Пулы памяти называются аренами, а реализация находится в arena.c.Макрос HEAP_MAX_SIZE определяет максимальный размер арены, и в основном он составляет 1 МБ для 32-разрядных и 64 МБ для 64-разрядных:

HEAP_MAX_SIZE = (2 * DEFAULT_MMAP_THRESHOLD_MAX)
32-bit [DEFAULT_MMAP_THRESHOLD_MAX = (512 * 1024)] = 1,048,576 (1MB)
64-bit [DEFAULT_MMAP_THRESHOLD_MAX = (4 * 1024 * 1024 * sizeof(long))] = 67,108,864 (64MB)

Информация из реализации кучи (arena.c):

/ * Куча - это единая непрерывная область памяти, содержащая (объединяемые) malloc_chunks.Он назначается с помощью mmap () и всегда начинается с адреса, выровненного по HEAP_MAX_SIZE.* /

РЕДАКТИРОВАТЬ:

Распределение кучи можно наблюдать с помощью strace .При первом вызове brk () основная арена выделяется 200 КБ (72 КБ из libstdc ++ с 128 КБ top_pad).

brk(NULL)                               = 0x556ecb423000 -> current program break
brk(0x556ecb455000)                     = 0x556ecb455000 -> resize the heap by moving brk 0x32000 bytes upward (main arena initialization with 200K). 
write(1, "i = 0\n", 8)                = 8
...
write(1, "i = 123\n", 8)                = 8     
brk(0x556ecb476000)                     = 0x556ecb476000 -> resize the heap by moving brk 0x21000 bytes upward (growing heap 128K). 
...
write(1, "i = 252\n", 8)                = 8
brk(0x556ecb497000)                     = 0x556ecb497000 -> resize the heap by moving brk 0x21000 bytes upward (growing heap 128K). 

Ваше приложение использовало только 100 КБ из 128 КБ доступной кучи, поэтому потребление памятине будет наблюдаться программой top или htop.

Вы можете легко увидеть изменение в потреблении памяти, если принудительно заставить glibc использовать mmap (), запросив блоки размером более 128 Кб или увеличив количество блоков (> 128).

Answer 2

Если вы хотите понять использование памяти, не используйте top.Используйте бесплатную программу с открытым исходным кодом https://github.com/vmware/chap (отказ от ответственности: я являюсь первоначальным разработчиком).

Просто соберите работающее ядро ​​до завершения программы, например, запустив gcore, затем введите:

chap your-core-file-name

Затем вы можете делать такие вещи, как:

считать список пропущенных счетчик пропущенных счетчик использовать счетчик свободный ....

Вот пример использования вашей программы, собирающей ядро ​​через 30 секунд:

-bash-4.1$ ./q53633998 &
[1] 18014
-bash-4.1$ sleep 30
gcore 18014
-bash-4.1$ gcore 18014
0x00000030ed6aca20 in __nanosleep_nocancel () at ../sysdeps/unix/syscall-         template.S:82
82      T_PSEUDO (SYSCALL_SYMBOL, SYSCALL_NAME, SYSCALL_NARGS)
Saved corefile core.18014
-bash-4.1$ ~/public_html/chap core.18014
chap> count used
36 allocations use 0x9120 (37,152) bytes.
chap> count free
1 allocations use 0x17db0 (97,712) bytes.
chap> count leaked
35 allocations use 0x8d18 (36,120) bytes.
chap> count anchored
1 allocations use 0x408 (1,032) bytes.
chap> list anchored
Used allocation at 19d4e40 of size 408

1 allocations use 0x408 (1,032) bytes.
chap> explain 19d4e40
Address 19d4e40 is at offset 0 of
an anchored allocation at 19d4e40 of size 408
Allocation at 19d4e40 appears to be directly anchored from at least one stack.
Address 0x7ffc88570270 is on the live part of the stack for thread 1.
Stack address 7ffc88570270 references 19d4e40

chap> list leaked
Used allocation at 19cc010 of size 408

Used allocation at 19cc420 of size 408

Used allocation at 19cc830 of size 408

Used allocation at 19ccc40 of size 408

Used allocation at 19cd050 of size 408

Used allocation at 19cd460 of size 408

Used allocation at 19cd870 of size 408

Used allocation at 19cdc80 of size 408

Used allocation at 19ce090 of size 408

Used allocation at 19ce4a0 of size 408

Used allocation at 19ce8b0 of size 408

Used allocation at 19cecc0 of size 408

Used allocation at 19cf0d0 of size 408

Used allocation at 19cf4e0 of size 408

Used allocation at 19cf8f0 of size 408

Used allocation at 19cfd00 of size 408

Used allocation at 19d0110 of size 408

Used allocation at 19d0520 of size 408

Used allocation at 19d0930 of size 408

Used allocation at 19d0d40 of size 408

Used allocation at 19d1150 of size 408

Used allocation at 19d1560 of size 408

Used allocation at 19d1970 of size 408

Used allocation at 19d1d80 of size 408

Used allocation at 19d2190 of size 408

Used allocation at 19d25a0 of size 408

Used allocation at 19d29b0 of size 408

Used allocation at 19d2dc0 of size 408

Used allocation at 19d31d0 of size 408

Used allocation at 19d35e0 of size 408

Used allocation at 19d39f0 of size 408

Used allocation at 19d3e00 of size 408

Used allocation at 19d4210 of size 408

Used allocation at 19d4620 of size 408

Used allocation at 19d4a30 of size 408

35 allocations use 0x8d18 (36,120) bytes.
chap> list free
Free allocation at 19d5250 of size 17db0

1 allocations use 0x17db0 (97,712) bytes.
chap>

Последнее «свободное» выделение - это конец блока памяти, выделенного во время первого вызова mallocи постепенно выделяется по мере выполнения последующих вызовов malloc.

Конечно, существуют другие инструменты (например, valgrind), которые работают по-другому, обрабатывая процесс, но если вам нужен инструмент, который может анализировать использование памяти процессомбез изменения способа выполнения процесса, глава является хорошим выбором.

Answer 3

Попробуйте следующее:

#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <unistd.h>

int main(){
  char* q;
  for(int i=0; i<10000; i++){
    q = (char*)malloc(1024); 
    memset(q,0,1024);
  }
  getchar();
  return 0;
}

для различных значений в цикле for.

Проблема в том, что Linux не обязательно использует память, даже если она распределена, пока она не будет заполнена.Поэтому вам необходимо записать данные в то, что вы выделяете, иначе они могут даже не зарегистрировать, что эта память используется.Вот почему некоторые приложения могут выделять память, и это нормально, тогда даже когда они выделены, когда они приходят к использованию памяти, они могут обнаружить, что память недоступна.

memset будет принудительно записыватьнули в выделенном буфере, в результате чего память используется и регистрируется как используемая сверху.Обратите внимание, что htop может быть проще использовать здесь.

Если вы хотите продолжить, изучите «оптимистичный malloc», который является характеристикой Linux, обратите внимание, что некоторые другие операционные системы не ведут себя таким образом.

Также стоит отметить, что внутренняя память выделяется в виде смежных фрагментов определенного размера.Таким образом, выделение, скажем, дополнительных 1 КБ, может не регистрировать увеличение размера, если память выделяется с минимальным размером блока, скажем, 4 КБ.