2011-08-07 9 views
4

でメモリリークを追跡するheapyを使用した:http://www.toofishes.net/blog/using-guppy-debug-django-memory-leaks/私はここにどのようにジャンゴとセットアップheapyに優れたポストを追ってきたのDjangoアプリ

私は(hp.setrefを命じました)、今しばらくした後、私はまた、データを取得しますhp.heap():

>>> hp.heap() 
Partition of a set of 12075 objects. Total size = 1515496 bytes. 
Index Count %  Size % Cumulative % Kind (class/dict of class) 
    0 4048 34 339656 22 339656 22 str 
    1 3112 26 269368 18 609024 40 tuple 
    2 171 1 169992 11 779016 51 dict (no owner) 
    3 1207 10 144440 10 923456 61 list 
    4  49 0 102040 7 1025496 68 dict of module 
    5 591 5 66984 4 1092480 72 unicode 
    6 498 4 59760 4 1152240 76 function 
    7 433 4 51960 3 1204200 79 types.CodeType 
    8  57 0 50480 3 1254680 83 type 
    9  36 0 31584 2 1286264 85 dict of class 

何が今ですか?私はこの成果から何を理解すべきでしょうか?それらの 'str'と 'tuple'オブジェクトがどこに属しているかを追跡する方法は? get_rpで

、私は出力を以下の取得:

>>> hp.heap().get_rp() 
Reference Pattern by <[dict of] class>. 
0: _ --- [-] 12000 (0xd1d340 | 0xd88b50 | 0xf63f00 | __builtin__.Struct | __... 
1: a  [-] 137 dict (no owner): 0x761c30*160, 0x7655d0*1491, 0x781640*9... 
2: aa ---- [-] 45 dict of django.db.models.options.Options: 0xcf3110... 
3: a3  [-] 45 django.db.models.options.Options: 0xcf3110, 0xf0bb10... 
4: a4 ------ [-] 140 dict of django.db.models.related.RelatedObject: 0x10bec... 
5: a5   [-] 140 django.db.models.related.RelatedObject: 0xf14450... 
6: a6 -------- [-] 63 dict of django.db.models.fields.related.ForeignKey: 0x... 
7: a7   [+] 63 django.db.models.fields.related.ForeignKey: 0xf0e690... 
8: a5b ------- [-] 7 dict of django.db.models.fields.related.OneToOneField: ... 
9: a5ba   [+] 7 django.db.models.fields.related.OneToOneField: 0x15447... 

は、それがメモリリークしているDjangoのことを今正しい仮定ですか?しかし、所有者を持たないこれらの弁護士は何ですか?

答えて

0

私はheapyの経験はありませんが、私の経験上、Django(そして他のほとんどのPythonプログラム)はメモリをリークしませんが、いくつかのようにメモリをきれいにするわけでもありません。

また、Djangoには診断上の理由でメモリを消費させる設定があります。たとえば、DEBUG = Trueを設定すると、すべてのSQLクエリが保持されるため、プロセスが実行される時間が長くなればなるほど、使用されるメモリが増えます。

更新:問題はあなたのPythonコードにありません。 heapyが提供している要約を見てください:そこに表されるメモリの合計サイズは1.5Mbです! Pythonプログラムが本当に漏れている場合、最も一般的な原因は漏れやすいC拡張です。 Djangoプロセスで実行しているC拡張がありますか?

+1

ありがとうございますが、それは本当に私の質問に答えていない。結果をどのように解釈するかについてのことでした。我々は明らかにメモリリーク(2GBまたはmemを食べるプロセス)を持っていて、DEBUG = Trueに関連していないのは、私たちの生産環境ではFalseだからです。 – petteri

+0

数十万のモデルインスタンスを使用すると、リークすることなく大量のメモリを消費することができます。 –

+0

@petteri:答えを更新しました。 –

関連する問題