GQLクエリオブジェクトのメモリリーク

Question

私は、CSVの数十万行を解析する、長い実行中のバックグラウンドプロセスを持っています。私は、プロセスにメモリリークがあり、タスクがソフトメモリの限界に達して終了することがあることに気づいた。

class BaseModel(db.Model): 
    _keyNamespace = 'MyApp.Models' 

    @classmethod 
    def get_by_item_id(cls, id): 
     key = "%s_%d" % (cls._keyNamespace, id) 
     item = CacheStrategy.get(key) 
     if not item: 
      query = cls.gql("WHERE Id = :1", id) 
      item = query.get() 
      del query 

     return item 

私は裸の骨にこれを削減しましたが、まだクエリがメモリに残ってオブジェクトを引き起こしている：私はダウンのコードの次のチャンクにコードのセクションを縮小しています。コメントの最後には、200の注文バッチ・ステップごとにQueryおよびQuery_Filterのカウントが200ずつ増加することを示すサンプルGC参照ダンプが含まれています。もし私が質問の呼び出しを取り除くと、これはもちろん遠ざかります。

私の質問は、はなぜこの漏れクエリの参照である、と私はそれがデルを尊重し、クエリの参照を削除する方法を得るのですか？

私はこれをインスタンスメソッドにしました（違いはありません）。私はあなたの参照カウントコード及び（shell.appspot.comまたは新鮮なアプリ上）以下の些細なスニペットを使用して、これを再現することができないんだ

INFO  2011-10-17 16:29:39,158 orderparser.py:151] Putting a 200 unit batch of orders, 0.335000 seconds from start 
DEBUG 2011-10-17 16:29:40,315 memleaker.py:20] Top Mem Leaks 
DEBUG 2011-10-17 16:29:40,334 memleaker.py:22]  356306 Property 
DEBUG 2011-10-17 16:29:40,334 memleaker.py:22]  356305 PropertyValue 
DEBUG 2011-10-17 16:29:40,334 memleaker.py:22]  74410 Path 
DEBUG 2011-10-17 16:29:40,334 memleaker.py:22]  74408 Path_Element 
DEBUG 2011-10-17 16:29:40,334 memleaker.py:22]  45127 PropertyValue_ReferenceValue 
DEBUG 2011-10-17 16:29:40,334 memleaker.py:22]  45127 PropertyValue_ReferenceValuePathElement 
DEBUG 2011-10-17 16:29:40,334 memleaker.py:22]  43822 Reference 
DEBUG 2011-10-17 16:29:40,335 memleaker.py:22]  30595 EntityProto 
DEBUG 2011-10-17 16:29:40,335 memleaker.py:22]  320 ProtocolMessage 
DEBUG 2011-10-17 16:29:40,335 memleaker.py:22]  217 Query 
DEBUG 2011-10-17 16:29:40,335 memleaker.py:22]  209 Query_Filter 
DEBUG 2011-10-17 16:29:40,335 memleaker.py:22]   55 NOT_PROVIDED 
DEBUG 2011-10-17 16:29:40,335 memleaker.py:22]   34 Index_Property 
DEBUG 2011-10-17 16:29:40,335 memleaker.py:22]   28 ExtendableProtocolMessage 
DEBUG 2011-10-17 16:29:40,336 memleaker.py:22]   18 CompositeIndex 
INFO  2011-10-17 16:29:40,644 orderparser.py:151] Putting a 200 unit batch of orders, 1.821000 seconds from start 
DEBUG 2011-10-17 16:29:41,930 memleaker.py:20] Top Mem Leaks 
DEBUG 2011-10-17 16:29:41,948 memleaker.py:22]  356506 Property 
DEBUG 2011-10-17 16:29:41,948 memleaker.py:22]  356505 PropertyValue 
DEBUG 2011-10-17 16:29:41,948 memleaker.py:22]  74410 Path 
DEBUG 2011-10-17 16:29:41,948 memleaker.py:22]  74408 Path_Element 
DEBUG 2011-10-17 16:29:41,948 memleaker.py:22]  45127 PropertyValue_ReferenceValue 
DEBUG 2011-10-17 16:29:41,948 memleaker.py:22]  45127 PropertyValue_ReferenceValuePathElement 
DEBUG 2011-10-17 16:29:41,948 memleaker.py:22]  43822 Reference 
DEBUG 2011-10-17 16:29:41,951 memleaker.py:22]  30595 EntityProto 
DEBUG 2011-10-17 16:29:41,951 memleaker.py:22]  417 Query 
DEBUG 2011-10-17 16:29:41,951 memleaker.py:22]  409 Query_Filter 
DEBUG 2011-10-17 16:29:41,951 memleaker.py:22]  320 ProtocolMessage 
DEBUG 2011-10-17 16:29:41,951 memleaker.py:22]   55 NOT_PROVIDED 
DEBUG 2011-10-17 16:29:41,951 memleaker.py:22]   34 Index_Property 
DEBUG 2011-10-17 16:29:41,951 memleaker.py:22]   28 ExtendableProtocolMessage 
DEBUG 2011-10-17 16:29:41,953 memleaker.py:22]   18 CompositeIndex 
INFO  2011-10-17 16:29:42,276 orderparser.py:151] Putting a 200 unit batch of orders, 3.450000 seconds from start 
DEBUG 2011-10-17 16:29:43,565 memleaker.py:20] Top Mem Leaks 
DEBUG 2011-10-17 16:29:43,585 memleaker.py:22]  356706 Property 
DEBUG 2011-10-17 16:29:43,585 memleaker.py:22]  356705 PropertyValue 
DEBUG 2011-10-17 16:29:43,585 memleaker.py:22]  74410 Path 
DEBUG 2011-10-17 16:29:43,585 memleaker.py:22]  74408 Path_Element 
DEBUG 2011-10-17 16:29:43,585 memleaker.py:22]  45127 PropertyValue_ReferenceValue 
DEBUG 2011-10-17 16:29:43,585 memleaker.py:22]  45127 PropertyValue_ReferenceValuePathElement 
DEBUG 2011-10-17 16:29:43,585 memleaker.py:22]  43822 Reference 
DEBUG 2011-10-17 16:29:43,586 memleaker.py:22]  30595 EntityProto 
DEBUG 2011-10-17 16:29:43,586 memleaker.py:22]  617 Query 
DEBUG 2011-10-17 16:29:43,586 memleaker.py:22]  609 Query_Filter 
DEBUG 2011-10-17 16:29:43,586 memleaker.py:22]  320 ProtocolMessage 
DEBUG 2011-10-17 16:29:43,586 memleaker.py:22]   55 NOT_PROVIDED 
DEBUG 2011-10-17 16:29:43,586 memleaker.py:22]   34 Index_Property 
DEBUG 2011-10-17 16:29:43,586 memleaker.py:22]   28 ExtendableProtocolMessage 
DEBUG 2011-10-17 16:29:43,588 memleaker.py:22]   18 CompositeIndex 

Answer 1

：下記参照カウントトレース

from google.appengine.ext import db 
import logging 
import sys 
import types 

def get_refcounts(): 
    d = {} 
    # collect all classes 
    for m in sys.modules.values(): 
     for sym in dir(m): 
      o = getattr (m, sym) 
      if type(o) is types.ClassType: 
       d[o] = sys.getrefcount (o) 
    # sort by refcount 
    pairs = map (lambda x: (x[1],x[0]), d.items()) 
    pairs.sort() 
    pairs.reverse() 
    return pairs 

def print_top(num = 15): 
    print 'Top Mem Leaks' 
    for n, c in get_refcounts()[:num]: 
     print '%10d %s' % (n, c.__name__) 

class TestModel(db.Model): 
    id = db.IntegerProperty() 


print_top() 

q = TestModel.gql("WHERE id = :1", 1) 
item = q.get() 
del q 

print_top() 

それはそうです環境内の何かが実行されたクエリへの参照を保持している可能性があります。あなたはappstatsや別の開発ツールやデバッグツールを使用していますか？あなたが観察した振る舞いを示す最小限の複製事例を作成できますか？