Problemi con le perdite di memoria di Ironpython nell'applicazione Web

Question

ha chiunque abbia ottenuto con successo Ironpython in esecuzione senza problemi in un ambiente web? Sto correndo in alcuni problemi.

Primo problema, non sto effettivamente eseguendo alcun tipo di script specifici di Ironpython, sto implementazione del Pygments Libreria così posso Ottieni l'evidenziazione della sintassi del lato server. La biblioteca è di circa 20 file.

Oltre al fatto che l'ultima versione di Ironpython non può compilare gli script in una DLL (a causa di questo problema ), lo farò in esecuzione con successo copiando tutti i file e le dipendenze nella cartella Bin.

Il problema è che sono andato a guardare come il mio processo W3WP.exe sta facendo quando si esegue evidenziando e notato alcuni problemi ShowStopper:

.

• Anche in un sito web totalmente semplice e vuoto sotto Cassini, evidenziando il codice select * from table utilizzando il Lexer SQL causa un salto da 10 MB ogni volta che lo eseguo (Aggiornamento della pagina) ... Sto spegnendo esplicitamente il motore e Utilizzo di LightweightScopes in una singola chiamata. Inizia a circa 30 MB e con circa 20 rinfreschi è a 150 MB o giù di lì.

• Nella mia applicazione Web effettiva, utilizzando SQL Lexer (stesso codice) causa il mio pool di app per aumentare di circa 200 MB / sec (letteralmente, lo uccido quando raggiunge circa 1 GB) finché non si schianta W3WP o rallenta il mio PC fino a un gattonio. Questo non accade nel sito di test vuoto e non ci sono problemi in un'app console con lo stesso codice esatto. Altri lexer come C # non causano enormi perdite di memoria, ma hanno lo stesso effetto di aumentare la memoria ogni volta che si chiamano la funzione.

  Questo mi porta a credere che questo problema specifico specifico, considerando che l'app console non ha problemi (istanziando il runtime causare un aumento di 20 MB di memoria). Sto usando la versione 2.7 IPY e 1.4 Release di Pygments.

  Non ho il codice esatto con me al momento, ma sembra qualcosa di simile:

  var options = something;
  options["LightweightScopes"] = ScriptRuntimeHelpers.True; // from another SO post, 'true' didn't seem to work
  var engine = Python.CreateEngine(options);
  //
  // set up search paths here...
  //
  dynamic scope = whatever;
  ScriptSource source = engine.CreateScriptSourceFromFile("myscript.py");
  
  // Execute? Compile? It populates the scope at this point...
  source.Compile(scope);
  
  // execute (code, lexer name, style)
  // this is a python function I have that calls the Pygments code
  var highlighted = scope.generate_html("select * from table", "sql", "monokai");
  
  engine.Shutdown();
  return highlighted;
  

  .

  Come ho detto, ho copiato questo stesso codice in: a) un'app console, b) una nuovissima applicazione web vuota, c) la mia app originale. L'app console non ha perso memoria, ma le app Web fanno.

  Ho anche eseguito la funzione con il Python nativo (python myscript.py) e il IPY (ipy myscript.py) e né avevano alcuna perdita di memoria.

  C'è qualche migliore pratica che mi manca di smaltire il runtime? Ho intenzione di eseguire questo in un ambiente condiviso, quindi la possibile soluzione alternativa di istanziazione del motore in una pool di app diversi probabilmente non funzionerà per me (anche quella enorme perdita con il 200mb / s è una specie di showstopper). .

  Attualmente, a meno che qualcuno non abbia una cura miracolosa, ho intenzione di scaricare il codice e vai con un evidenziatore JavaScript Syntax. È molto sfortunato perché le pygments sono fantastiche ...

Answer 1

È una storia piuttosto lunga. (Tldr, scusa). Questo è .NET, molto probabilmente guardando la frammentazione dell'heap piuttosto che l'esaurimento della memoria.

Se stai davvero perdendo memoria, si tiene premuto per riferimenti troppo a lungo. Rivedi IDISPOSIBILI (in particolare la comprensione dell'elenco può ferire, soprattutto con le cose Linqy come Orderby e distinte attaccate).

I Una volta ha realizzato un'applicazione 2x Esegui 2x più velocemente, quando è stato in grado di fallire in modo affidabile esauritura / frammentazione del mucchio attaccando un semplice .tolista () sulle più grandi enumerazioni che ho dovuto guidare un grande processo.

Ci sono buoni profiler di memoria per .NET, ma attualmente so come utilizzare solo mono -profiler (cattiva memoria). Un semplice google ti aiuterà a trovare un profiler che puoi usare sul tuo ambiente: lascia che ti dica esattamente cosa oggetti assegnati dove si frammentano il tuo mucchio

---

.

PS. Dato che ti ho visto puntando il dito sulle applicazioni Web sulla seconda scansione della tua domanda, aggiungerei: controlla quali riferimenti (indirettamente) vengono tenuti dallo stato della sessione (applicazione, sessione).