Неисправность утечки памяти неигрового объекта

У меня есть веб-сервер django под управлением uwsgi, который, как представляется, течет в памяти.

В частности, RSS процессов медленно растет, пока в конце концов я не перезапущу его.

Мне известны другие подобные вопросы к этому, однако все найденные до сих пор решения/выводы, похоже, не применяются (что я могу найти) в этом случае.

До сих пор я использовал meliae, Heapy, pympler и objgraph для проверки кучу python, и все они сообщают одно и то же: обычная выглядящая куча, использующая около 40 МБ памяти (ожидается) с очень небольшим изменением со временем (по желанию).

Это, к сожалению, совершенно несовместимо с процессом RSS, который с радостью вырастет до 400 МБ + без отражения в размере кучи питона.

Некоторые примеры для иллюстрации моей точки -

Выход Pympler, сравнивающий память кучи/объектов python и процесс RSS:

Memory snapshot:
                                        types |   # objects |   total size
============================================= | =========== | ============
                                         dict |       20868 |     19852512
                                          str |      118598 |     11735239
                                      unicode |       19038 |     10200248
                                        tuple |       58718 |      5032528
                                         type |        1903 |      1720312
                                         code |       13225 |      1587000
                                         list |       11393 |      1289704
                            datetime.datetime |        6953 |       333744
                                          int |       12615 |       302760
  <class 'django.utils.safestring.SafeUnicode |          18 |       258844
                                      weakref |        2908 |       255904
     <class 'django.db.models.base.ModelState |        3172 |       203008
                   builtin_function_or_method |        2612 |       188064
                       function (__wrapper__) |        1469 |       176280
                                         cell |        2997 |       167832
                            getset_descriptor |        2106 |       151632
                           wrapper_descriptor |        1831 |       146480
                                          set |         226 |       143056
                                      StgDict |         217 |       138328
---------------------------
Total object memory: 56189 kB
Total process usage:
 - Peak virtual memory size: 549016 kB
 - Virtual memory size: 549012 kB
 - Locked memory size: 0 kB
 - Peak resident set size: 258876 kB
 - Resident set size: 258868 kB
 - Size of data segment: 243124 kB
 - Size of stack segment: 324 kB
 - Size of code segment: 396 kB
 - Shared library code size: 57576 kB
 - Page table entries size: 1028 kB
---------------------------

Результат работы с кучей, показывающий аналогичную вещь

Memory snapshot:
Partition of a set of 289509 objects. Total size = 44189136 bytes.
 Index  Count   %     Size   % Cumulative  % Kind (class / dict of class)
     0 128384  44 12557528  28  12557528  28 str
     1  61545  21  5238528  12  17796056  40 tuple
     2   5947   2  3455896   8  21251952  48 unicode
     3   3618   1  3033264   7  24285216  55 dict (no owner)
     4    990   0  2570448   6  26855664  61 dict of module
     5   2165   1  1951496   4  28807160  65 type
     6  16067   6  1928040   4  30735200  70 function
     7   2163   1  1764168   4  32499368  74 dict of type
     8  14290   5  1714800   4  34214168  77 types.CodeType
     9  10294   4  1542960   3  35757128  81 list
<1046 more rows. Type e.g. '_.more' to view.>
---------------------------
Total process usage:
 - Peak virtual memory size: 503132 kB
 - Virtual memory size: 503128 kB
 - Locked memory size: 0 kB
 - Peak resident set size: 208580 kB
 - Resident set size: 208576 kB
 - Size of data segment: 192668 kB
 - Size of stack segment: 324 kB
 - Size of code segment: 396 kB
 - Shared library code size: 57740 kB
 - Page table entries size: 940 kB
---------------------------

Обратите внимание, что в обоих случаях размер кучи составляет 40-50 МБ, а процесс RSS - 200 МБ +.

Я также использовал objgraph get_leaking_objects(), чтобы попытаться увидеть, что C-расширение делает плохой подсчет ref, однако количество объектов, не связанных с gc'able, заметно не растет со временем.

Есть ли у кого-нибудь представление о том, как отлаживать это? На этом этапе я предполагаю, что одна из двух вещей имеет место:

  • У меня внутренняя утечка памяти C-расширения
  • uwsgi сам протекает в памяти (хотя я не могу найти никаких других доказательств этого в сети).

Возможно, стоит упомянуть, что я не успел реплицировать это в какой-либо среде разработки (хотя возможно, что я просто не набрасываю на них достаточный трафик).

Мы используем кучу модулей, которые имеют C-расширения (simplejson, hiredis и т.д.), поэтому он определенно правдоподобен, что они могут быть причиной.

Ищите подходы, чтобы отслеживать это.

Ответ 1

Какую версию Python вы используете? В Python 2.4 память не была возвращена в ОС с помощью распределителя памяти Python.

В более новых версиях вы можете увидеть проблему, связанную с распределением памяти Python, которая хранит списки освобожденных простых типов, или, если вы работаете в Linux, проблема, связанная с тем, как реализация glibc malloc выделяет память из ОС. Посмотрите http://effbot.org/pyfaq/why-doesnt-python-release-the-memory-when-i-delete-a-large-object.htm и http://pushingtheweb.com/2010/06/python-and-tcmalloc/.