非オブジェクトのpythonメモリリークをうんざりにしています

Question

メモリがリークしていると思われるuwsgiの下で動作するdjangoウェブサーバを持っています。

具体的には、プロセスのRSSは徐々に成長し、最終的に再起動する必要があります。

私はこれに他の類似の質問があることを認識していますが、これまでに見つかったすべての解決策/結論はこのケースでは適用されないようです。

これまでのところ、私はPythonのヒープを検査するmeliae、Heapy、pymplerとobjgraphを使用しており、それらはすべて同じことを報告：時間をかけて非常に少ない分散でメモリの40メガバイト（予想）について使用して、通常見ているヒープを（など希望）。

これは残念ながら、プロセスのRSSと完全に矛盾しています。このRSSは、幸いなことに、のpythonヒープサイズで400MBに成長します。

私のポイントを説明するためにいくつかのサンプル出力 - プロセスのRSS対のpythonヒープ/オブジェクトのメモリを比較

Pympler出力を：同じようなこと

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 
--------------------------- 

を示す

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 
--------------------------- 

Heapy出力

どちらの場合も、報告されたヒープサイズは40〜50MBです。w hilstプロセスRSSは200MB以上です。

私はまた、C-拡張子が悪い参照カウントをしているかどうかを確認しようとするが非gc'ableオブジェクトの数が時間の経過とともに著しく成長しないobjgraphのget_leaking_objectsを（）使用しています。

誰でもこれをデバッグする方法についての洞察はありますか？

• 私はC-増設メモリリークに内部
• uwsgi私はこれの他の証拠を見つけることができませんけれども、それ自体が（メモリをリークしているがあります。この時点で、私は2つのいずれかが当てはまる想定していますnet）

私はこれを何らかの開発環境で複製することは成功していないと言えるかもしれません（ただし、十分なトラフィックを投げていない可能性もあります）。

私たちは、C拡張（simplejson、hiredisなど）を持つモジュールを使用していますので、原因が間違いないと信じられています。

これを追跡するためのアプローチを探してください。

Answer 1

あなたはどのバージョンのPythonを使用していますか？ Python 2.4では、メモリはPythonメモリアロケータによってOSに返されませんでした。

さらに新しいバージョンでは、解放されたシンプルタイプのリストを保持するPythonのメモリアロケータに関連する問題を見ることができます。または、Linuxで動作している場合、glibcのmalloc実装がOSからメモリを割り当てる方法に固有の問題があります。 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/を見てください。