анализ утечки памяти с верхом
Я хотел бы использовать инструмент «top» для анализа потребления памяти и возможных утечек памяти процесса.
Для этого я написал эту программу (имя программы: memoryTest):
int main(){
char* q;
for(int i=0; i<100; i++){
q = (char*) malloc(1024);
sleep(1);
}
return 0;
}
Теперь я могу смотреть эту программу сверху,
фильтруя с опцией «o» и спецификацией фильтра «COMMAND = memoryTest» после указанного процесса, однако я не вижу изменений в потреблении памяти процессом.
У меня есть глупая ошибка здесь?
Решение
Попробуйте следующее:
#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 КБ.
Другие решения
Если вы хотите понять использование памяти, не используйте top. Используйте бесплатную программу с открытым исходным кодом https://github.com/vmware/chap (Отказ от ответственности: я оригинальный разработчик).
Просто соберите живое ядро до завершения программы, например, запустив gcore, затем наберите:
глава -Файл-имя вашего основного
Тогда вы можете делать такие вещи, как:
граф просочился
список утек
количество использованных
считать бесплатно
….
Вот пример использования вашей программы, собирающей ядро через 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), которые по-разному работают, управляя процессом, но если вам нужен инструмент, который может анализировать использование памяти процессом без изменения способа его запуска, хорошим выбором будет chap.
Из справочной страницы malloc:
Обычно malloc () выделяет память из кучи и настраивает
размер кучи по мере необходимости, используя sbrk (2). При размещении блоков
памяти больше чем MMAP_THRESHOLD байт, glibc malloc ()
Реализация выделяет память как частное анонимное отображение
используя 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. * /
РЕДАКТИРОВАТЬ:
Распределение кучи можно наблюдать с помощью Трассирование. При первом вызове 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).