Speicherleck in Google Ndb-Bibliothek

Question

Ich denke, es gibt einen Speicherverlust in der ndb-Bibliothek, aber ich kann nicht finden, wo.

Gibt es eine Möglichkeit, das unten beschriebene Problem zu vermeiden?
Haben Sie eine genauere Vorstellung von Tests, um herauszufinden, wo das Problem liegt?

---

Das ist, wie ich das Problem reproduziert:

I mit 2 Dateien eine minimalistische Google App Engine-Anwendung erstellt.
app.yaml:

application: myapplicationid 
version: demo 
runtime: python27 
api_version: 1 
threadsafe: yes 


handlers: 
- url: /.* 
    script: main.APP 

libraries: 
- name: webapp2 
    version: latest 

main.py:

# -*- coding: utf-8 -*- 
"""Memory leak demo.""" 
from google.appengine.ext import ndb 
import webapp2 


class DummyModel(ndb.Model): 

    content = ndb.TextProperty() 


class CreatePage(webapp2.RequestHandler): 

    def get(self): 
     value = str(102**100000) 
     entities = (DummyModel(content=value) for _ in xrange(100)) 
     ndb.put_multi(entities) 


class MainPage(webapp2.RequestHandler): 

    def get(self): 
     """Use of `query().iter()` was suggested here: 
      https://code.google.com/p/googleappengine/issues/detail?id=9610 
     Same result can be reproduced without decorator and a "classic" 
      `query().fetch()`. 
     """ 
     for _ in range(10): 
      for entity in DummyModel.query().iter(): 
       pass # Do whatever you want 
     self.response.headers['Content-Type'] = 'text/plain' 
     self.response.write('Hello, World!') 


APP = webapp2.WSGIApplication([ 
    ('/', MainPage), 
    ('/create', CreatePage), 
]) 

ich die Anwendung hochgeladen, rief einmal /create.
Danach erhöht jeder Aufruf von / den von der Instanz verwendeten Speicher. Bis es wegen des Fehlers Exceeded soft private memory limit of 128 MB with 143 MB after servicing 5 requests total stoppt.

Exemple von Diagramm zur Speicherauslastung (Sie können das Speicherwachstum und Abstürze sehen):

Hinweis: Das Problem kann mit einem anderen Rahmen als webapp2, wie web.py

Answer 1

Nach weiteren Untersuchungen, und mit Hilfe eines Google-Ingenieurs, habe ich zwei Erklärungen zu meinem Speicherverbrauch gefunden.

Context und Gewinde

ndb.Context ist ein "thread local" Objekt und wird erst dann gelöscht, wenn eine neue Anforderung in dem Faden kommen. So hält der Thread zwischen Anfragen fest. Viele Threads können in einer GAE-Instanz vorhanden sein und es kann Hunderte von Anfragen erfordern, bevor ein Thread ein zweites Mal verwendet wird und sein Kontext gelöscht wird.
Dies ist kein Speicherverlust, aber die Größe des Kontexts im Speicher kann den verfügbaren Speicher in einer kleinen GAE-Instanz überschreiten.

Umgehung:
Sie können nicht die Anzahl der Threads in einer GAE-Instanz verwendet konfigurieren. Daher ist es am besten, jeden Kontext möglichst klein zu halten. Vermeiden Sie den Kontextcache und löschen Sie ihn nach jeder Anfrage.

Ereigniswarteschlange

Es scheint, dass NDB nicht, dass Ereignis-Warteschlange nach einer Anforderung geleert wird garantiert. Auch dies ist kein Speicherleck. Aber lassen Sie Futures in Ihrem Thread-Kontext, und Sie sind zurück zum ersten Problem.

Umgehung:
Wrap alle Code, der mit @ndb.toplevel NDB verwenden.

Answer 2

reproduziert wird Es ist ein bekanntes Problem mit NDB. Sie können über it here und es ist ein Werk around here lesen:

Die Nicht-Determinismus mit fetch_page beobachtet die Iterationsreihenfolge von eventloop.rpcs zurückzuführen ist, die datastore_rpc.MultiRpc.wait_any() und apiproxy_stub_map geben wird. __check_one wählt den letzten rpc aus dem Iterator aus.

Abrufen mit page_size von 10 ist ein RPC mit count = 10, Limit = 11, eine Standardtechnik, um das Backend zu zwingen, genauer zu bestimmen, ob es mehr Ergebnisse gibt. Dies ergibt 10 Ergebnisse, aber aufgrund eines Fehlers in der Art, wie der QueryIterator entschlüsselt wird, wird ein RPC hinzugefügt, um den letzten Eintrag zu holen (unter Verwendung des erhaltenen Cursors und Anzahl = 1). NDB gibt dann den Batch von Entitäten zurück, ohne diesen RPC zu verarbeiten. Ich glaube, dass dieser RPC nicht ausgewertet wird, bis er zufällig ausgewählt wird (wenn MultiRpc ihn vor einem notwendigen RPC verbraucht), da er den Client-Code nicht blockiert.

Problemumgehung: Verwenden Sie iter(). Diese Funktion hat dieses Problem nicht (Anzahl und Limit sind identisch). iter() kann als Workaround für die Leistungs- und Speicherprobleme verwendet werden, die mit der oben erwähnten Abrufseite verbunden sind.

Answer 3

Eine mögliche Abhilfe ist context.clear_cache() und GC.Collect() auf get-Methode zu verwenden.

def get(self): 

    for _ in range(10): 
     for entity in DummyModel.query().iter(): 
      pass # Do whatever you want 
    self.response.headers['Content-Type'] = 'text/plain' 
    self.response.write('Hello, World!') 
    context = ndb.get_context() 
    context.clear_cache() 
    gc.collect()