Как найти источник увеличения использования памяти витым сервером?

Question

У меня есть сервер аудио трансляции, написанный на Python и основанный на Twisted. Он работает нормально, но его использование памяти увеличивается, когда на сервере больше пользователей, но использование памяти никогда не снижается, когда эти пользователи отключаются. Как вы видите на следующем рисунке:

Вы можете видеть, что кривая использования памяти повышается там, где кривая слушателей / радио увеличивается, но после пика слушателей / радио использование памяти все еще остается высоким, никогда не снижается.

Я попробовал следующий метод для решения этой проблемы:

1. Обновление Twisted с 8,2 до 9,0
2. Используйте гуппи, чтобы сбросить кучу, но это совсем не помогает
3. Переключить реактор селектора на реактор Эполла, та же проблема.
4. Используйте objgraph, чтобы нарисовать диаграмму отношения объектов, но я не вижу точек из этого.

Вот среда, в которой я использовал свой витой сервер:

• Python: 2.5.4 r254: 67916
• ОС: версия Linux 2.6.18-164.9.1.el5PAE (mockbuild@builder16.centos.org) (версия gcc 4.1.2 20080704 (Red Hat 4.1.2-46))
• Витая: 9,0 (под virtualenv)

свалка гуппи:

Partition of a set of 116280 objects. Total size = 9552004 bytes.
 Index  Count   %     Size   % Cumulative  % Type
  0  52874  45  4505404  47   4505404  47 str
  1   5927   5  2231096  23   6736500  71 dict
  2  29215  25  1099676  12   7836176  82 tuple
  3   7503   6   510204   5   8346380  87 types.CodeType
  4   7625   7   427000   4   8773380  92 function
  5    672   1   292968   3   9066348  95 type
  6    866   1    82176   1   9148524  96 list
  7   1796   2    71840   1   9220364  97 __builtin__.weakref
  8   1140   1    41040   0   9261404  97 __builtin__.wrapper_descriptor
  9   2603   2    31236   0   9292640  97 int

Как видите, общий размер 9552004 байта равен 9,1 МБ , и вы можете увидеть rss, переданный командой ps:

[xxxx@webxx ~]$ ps -u xxxx-o pid,rss,cmd
  PID   RSS CMD
22123 67492 twistd -y broadcast.tac -r epoll

rss моего сервера 65,9 МБ , это означает, что на моем сервере 56,8 МБ используется невидимая память, что это такое?

Мои вопросы:

1. Как найти источник увеличения использования памяти?
2. Какое видимое использование памяти у гуппи?
3. Что это за невидимое использование памяти?
4. Это вызвано утечками памяти некоторых модулей, написанных на C? Если это так, как я могу отследить и исправить это?
5. Как Python управляет памятью? Пул памяти? Я думаю, что это может быть вызвано кусками аудиоданных. Так что есть небольшие утечки в блоке памяти, принадлежащем интерпретатору Python.

Обновление 2010/1/20 : Интересно, я загружаю последний файл журнала, и это показывает, что память никогда не увеличивается ни на минуту. Я думаю, может быть, выделенное пространство памяти достаточно велико. Вот последняя цифра.

Обновление 2010/1/21 : Еще одна фигура здесь. гул .... поднять немного

Упс ... Все еще идет вверх

Answer 1

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

1. размер куска 511
2. размер куска 1040
3. размер куска 386
4. размер куска 1350
5. ...

Большинство из них имеют размер более 256 байт, Python использует malloc для кусков, размер которых превышает 256 байт, а не использует пул памяти. И вы можете представить, что эти куски выделены и освобождены, что случилось бы? Например, когда освобождается блок размером 1350, в куче может быть свободное пространство 1350 байт. После этого, вот еще один запрос 988, как только malloc выберет отверстие, а затем появится еще одно новое маленькое свободное отверстие размером 362. После долгого пробега в кучах появляется все больше маленьких отверстий, другими словами много фрагментов в кучах. Размер страницы виртуальной памяти обычно составляет 4 КБ, эти фрагменты распределены по большому диапазону кучи, это делает ОС не способной выгружать эти страницы. Таким образом, RSS всегда высоко.

После модификации конструкции модуля управления аудиоблоками моего сервера он теперь использует мало памяти. Вы можете увидеть рисунок и сравнить с предыдущим.

Новый дизайн использует bytearray вместо списка строк . Это большой кусок памяти, поэтому больше нет фрагментации.

Answer 2

Для меня это звучит как утечка памяти в C-модуле. Valgrind - хороший инструмент для отслеживания проблем, связанных с выделением памяти. Я не знаю, насколько хорошо это работает с загруженными модулями во время выполнения, хотя ...

Answer 3

Задумывались ли вы об использовании альтернативы CentOS dtrace - SystemTap Я думаю, что это называется.

Это должно дать вам довольно низкоуровневый след того, что происходит внутри ваших * nix процессов ....... удар в темноте, но может дать вам больше прозрачности при внутрипроцессной активности.

Интересный вопрос. Ждем ответов других.

Ben