Perdita di memoria nella libreria ndb di Google

Question

Penso che ci sia una perdita di memoria nella libreria ndb ma non riesco a trovare dove.

C'è un modo per evitare il problema descritto di seguito?
Hai un'idea più precisa dei test per capire dove si trova il problema?

---

È così che ho riprodotto il problema:

ho creato un minimalista applicazione Google App Engine con 2 file.
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), 
]) 

ho caricato l'applicazione, chiamata /create una volta.
Successivamente, ogni chiamata a / aumenta la memoria utilizzata dall'istanza. Fino a quando non si arresta a causa dell'errore Exceeded soft private memory limit of 128 MB with 143 MB after servicing 5 requests total.

Esempio di grafico di utilizzo della memoria (si può vedere la crescita della memoria e va in crash):

Nota: Il problema può essere riprodotto con un altro quadro di webapp2, come web.py

Answer 1

Dopo ulteriori indagini e con l'aiuto di un ingegnere google, ho trovato due spiegazioni sul consumo di memoria.

Contesto e filo

ndb.Context è un oggetto "filo locale" e vengono cancellati solo quando una nuova richiesta di venire nel thread. Quindi il thread lo tiene tra le richieste. Molti thread possono esistere in un'istanza di GAE e potrebbero essere necessarie centinaia di richieste prima che un thread venga utilizzato una seconda volta e il contesto venga cancellato.
Questa non è una perdita di memoria, ma le dimensioni dei contesti nella memoria possono superare la memoria disponibile in una piccola istanza GAE.

Soluzione:
Non è possibile configurare il numero di thread utilizzati in un'istanza GAE. Quindi è meglio mantenere ogni contesto il più piccolo possibile. Evita la cache nel contesto e cancellala dopo ogni richiesta.

coda di eventi

Sembra che NDB non garantisce che coda di evento viene svuotata dopo una richiesta. Ancora una volta questa non è una perdita di memoria. Ma lascia il Futures nel contesto del thread e si torna al primo problema.

Soluzione:
Wrap tutto il codice che utilizzano NDB con @ndb.toplevel.

Answer 2

C'è un problema noto con NDB. Si può leggere su it here e c'è un lavoro around here:

La non-determinismo osservato con fetch_page è dovuta all'ordine iterazione del eventloop.rpcs, che è passato a datastore_rpc.MultiRpc.wait_any() e apiproxy_stub_map. __check_one seleziona lo rpc dell'dall'iteratore.

Il recupero con page_size di 10 fa un rpc con count = 10, limit = 11, una tecnica standard per forzare il backend a determinare con maggiore precisione se ci sono più risultati. Questo restituisce 10 risultati, ma a causa di un bug nel modo in cui il QueryIterator viene svelato, viene aggiunto un RPC per recuperare l'ultima voce (utilizzando il cursore ottenuto e count = 1). NDB restituisce quindi il batch di entità senza elaborare questo RPC. Credo che questo RPC non verrà valutato fino a quando non viene selezionato casualmente (se MultiRpc lo consuma prima di un rpc necessario), poiché non blocca il codice client.

Soluzione alternativa: utilizzare iter(). Questa funzione non ha questo problema (il conteggio e il limite saranno gli stessi). iter() può essere utilizzato come soluzione alternativa per i problemi di prestazioni e memoria associati alla pagina di recupero causata da quanto sopra.

Answer 3

Una possibile soluzione è quella di utilizzare context.clear_cache() e GC.Collect() sul metodo get.

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