обзор / история использования резидентной памяти

Question

У меня довольно сложная программа (Python с SWIG-кодом C ++, долго работающий сервер), который показывает постоянно растущее использование резидентной памяти. Я копался с обычными инструментами для утечки (valgrind, модуль Pythons gc и т. Д.), Но пока безрезультатно. Я немного боюсь, что настоящая проблема заключается в фрагментации памяти в Python и / или в управляемой памяти libc.

В любом случае, мой вопрос сейчас более конкретен: есть ли инструмент, позволяющий визуализировать использование резидентной памяти и в идеале показать, как она развивается со временем? Я думаю, что необработанные данные находятся в / proc / $ PID / smaps, но я надеялся, что есть какой-то инструмент, который показывает мне хороший график количества использованных файлов mmap, анонимной памяти mmap и кучи с течением времени, так что легче (буквально) увидеть, что меняется. Я ничего не мог найти, хотя.

Кто-нибудь знает инструмент, который отображает карту памяти (тип памяти и объем) определенного процесса в пространстве и времени интуитивно понятным способом?

---

Обновление: Я нашел инструмент "pmap", но версия в моей системе, похоже, не поддерживает RSS и не дает возможности объединять размеры для всех отображаемых файлов, соответственно. нанесены на карту "анон" области. В итоге я взломал небольшой скрипт, который анализирует / proc / $ PID / smaps каждые две минуты, пока оригинальная программа запускается и печатает такие строки:

12:00:28 {'_TOTAL': 729.20703125, 'file': 53.609375, 'heap': 22.08984375,
          'anon': 653.5, 'stack': 0.0078125}
...
15:42:47 {'_TOTAL': 940.16015625, 'file': 53.484375, 'heap': 22.2109375,
          'anon': 864.45703125, 'stack': 0.0078125}

Нет хороших графиков, но после нескольких часов работы я думаю, что сейчас безопасная ставка, когда мне нужно поближе взглянуть на сегменты памяти 'anon': -)

---

Обновление: В последнем выпуске valgrind профилирование уровня поддержки страниц в профиле памяти ("массив") было выполнено с помощью --pages-as-heap=yes. Ура! Запуск моей программы в течение нескольких часов через массив и последующую подачу полученного файла в Massif Visualizer привел к хорошему графику потребления памяти по типу страницы с течением времени, включая трассировки стека, чтобы увидеть, куда поступают все вызовы mmap. от. \ О /

Answer 1

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

Я нашел этот код, может быть, он вам поможет.

http://www.nightmare.com/medusa/memory-leaks.html

Answer 2

Это редко, но вы можете проверить утечка файла (или сокета) , я имею в виду, когда программа открывает файлы и никогда не закрывает их.В моей конфигурации рабочего стола не было никаких признаков утечки сокета, пока она не превысила 1000+.Конечно, они были открыты около.1 / сек, так что оно появилось через несколько дней.Это зло!

Answer 3

Я тестирую с vmstat , но у него нет графического интерфейса и т. Д., Все его необработанные данные:

[~]> vmstat -S K 1
procs -----------memory---------- ---swap-- -----io---- -system-- ----cpu----
r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa
1  0    172 663244 410016 187756    0    0     6    12   14    4  0  0 99  0
0  0    172 663228 410016 187756    0    0     0    68   20   66  0  0 100  0
0  0    172 663228 410016 187756    0    0     0     0   12   54  0  0 100  0
0  0    172 663228 410016 187756    0    0     0     0   20   54  0  0 100  0
^C