Использование памяти, о котором сообщает гуппи, отличается от команды PS
Я представляю свой скрученный сервер. Это использует намного больше памяти, чем я ожидал. Его использование памяти растет со временем.
ps -o pid,rss,vsz,sz,size,command
PID RSS VSZ SZ SZ COMMAND
7697 70856 102176 25544 88320 twistd -y broadcast.tac
Поскольку Вы видите, что это стоит 102 176 КБ, а именно, 99,78125 МБ. И я использую гуппи от скрученного кабельного колодца для наблюдения профиля использования памяти.
>>> hp.heap()
Partition of a set of 120537 objects. Total size = 10096636 bytes.
Index Count % Size % Cumulative % Kind (class / dict of class)
0 61145 51 5309736 53 5309736 53 str
1 27139 23 1031596 10 6341332 63 tuple
2 2138 2 541328 5 6882660 68 dict (no owner)
3 7190 6 488920 5 7371580 73 types.CodeType
4 325 0 436264 4 7807844 77 dict of module
5 7272 6 407232 4 8215076 81 function
6 574 0 305776 3 8520852 84 dict of class
7 605 1 263432 3 8784284 87 type
8 602 0 237200 2 9021484 89 dict of type
9 303 0 157560 2 9179044 91 dict of zope.interface.interface.Method
<384 more rows. Type e.g. '_.more' to view.>
Гул... Кажется, что существует что-то не так. Гуппи показывает, что общее использование памяти составляет 10 096 636 байтов, а именно, 9 859,996 КБ или 9,628 МБ.
Это - огромная разница. Что случилось этот странный результат? Что я делаю неправильно?
Обновление: Я записал сценарий монитора вчера вечером. Это записывает использование памяти и число подключенных пользователей. Это - радио-сервер, таким образом, Вы видите, что существуют радио и общие слушатели. Вот число, которое я генерировал matplotlib. 
Что-то странно. Иногда использование памяти, распечатанное PS, является очень низким, как это
2010-01-15 00:46:05,139 INFO 4 4 17904 36732 9183 25944
2010-01-15 00:47:03,967 INFO 4 4 17916 36732 9183 25944
2010-01-15 00:48:04,373 INFO 4 4 17916 36732 9183 25944
2010-01-15 00:49:04,379 INFO 4 4 17916 36732 9183 25944
2010-01-15 00:50:02,989 INFO 4 4 3700 5256 1314 2260
Какова причина супер низкой стоимости использования памяти? И кроме того, даже нет никаких радио онлайн, никаких слушателей, использование памяти все еще высоко.
2 ответа
Нет, @Dynamic не получит вам никаких преимуществ в размере памяти / кода
-121--3450549-Возможно, из-за оказания бронирования / памяти на основе определения PS:
RSS: resident set size, the non-swapped physical memory
that a task has used (in kiloBytes).
VSZ: virtual memory usage of entire process.
vm_lib + vm_exe + vm_data + vm_stack
Это может быть немного запутано, можно увидеть 4 различных метрики размера с:
# ps -eo pid,vsz,rss,sz,size,cmd|egrep python
PID VSZ RSS SZ SZ CMD
23801 4920 2896 1230 1100 python
виртуальным размером включает в себя память Это было зарезервировано процессом и не использовано, размер всех общих библиотек, которые были загружены, страницы, которые помешаются, и блоки, которые уже были освобождены вашим процессом, поэтому он может быть намного больше, чем размер всех живых объектов в Python.
Некоторые дополнительные инструменты для исследования производительности памяти:
Куча (часть GUPPY, которую вы используете): http://guppy-pe.sourceforge.net/
Валидатор памяти Python http://www.softwareverify.com/python/memory/index.html
Pysizer http://pysizer.8325.org/
Хорошее руководство по отслеживанию утечек памяти в Python с использованием PDB и Objgraph:
http://www.lshift.net/blog/2008/11/14 / Pyrace-Python-Memory-Leaks
, как указано выше, размер RSS - это то, что вы больше всего интересуют здесь. Размер «виртуального» включает в себя сопоставленные библиотеки, которые вы, вероятно, не хотите рассчитывать.
Прошло некоторое время, так как я использовал куча, но я уверен, что статистика, которую он печатает, не включает в себя накладные расходы, добавленные самим кучкой. Это накладные расходы могут быть довольно значительными (я видел процесс RSS 100 МБ, расти еще один дюжина или около того MB, см. http://www.pkgcore.org/trac/pkgcore/doc/dev-notes/heapy.rst ).
Но в вашем случае я подозреваю, что проблема в том, что вы используете некоторую библиотеку C, которая либо утечка, либо использующая память таким образом, чтобы куча не отслеживала. Куча осознает память, используемую непосредственно объектами Python, но если эти объекты охватывают объекты C, которые отдельно выделены отдельно, обычно обычно не знают об этой памяти. Вы можете добавить поддержку кучи к вашим привязанию (но если вы не контролируете привязки, которые вы используете, это, очевидно, является проблемой, и даже если вы управляете привязками, вы не сможете сделать это в зависимости от того, что вы обертываете ).
Если есть утечки на уровне C Healpy, также проиграют отслеживание этой памяти (размер RSS подойдет, но размеры кучи, не останется прежним). VALGRIND, вероятно, ваша лучшая ставка, чтобы отслеживать их, так же, как и в других приложениях C.
Наконец: фрагментация памяти часто вызывает использование вашей памяти (как видно в верхней части), но не снижается (много). Обычно это не так уж большая проблема с демонами, поскольку процесс повторно использует эту память, он просто не выпускается обратно в ОС, поэтому значения в верхней части не возвращаются. Если использование памяти (как видно на вершину) увеличивается более или менее линейно с количеством пользователей (подключений), не вернутся вниз, но и не продолжает расти навсегда, пока вы не достигли нового максимального количества пользователей, фрагментация, вероятно, винить.