Informazioni sulle perdite di memoria in ASP.net utilizzando RedGate Memory Profiler

Question

Sto eseguendo un sito Web ASP.net 4.0 di grandi dimensioni. Utilizza un popolare sistema di gestione dei contenuti .Net, ha migliaia di elementi di contenuto, centinaia di utenti simultanei - è fondamentalmente un sito pesante.

Nel corso di 1 giorno, l'utilizzo della memoria del processo di lavoro di IIS7 può salire a 8-10 GB. Il server ha 16 GB installati ed è attualmente impostato per riciclare il pool di applicazioni una volta al giorno.

Sono sotto pressione per ridurre l'utilizzo della memoria. Gran parte dell'utilizzo della memoria è dovuto al caching di grandi stringhe di dati - ma l'intervallo di cache è impostato su 5-10 minuti - quindi queste stringhe dovrebbero alla fine scadere dalla memoria.

Tuttavia, dopo aver eseguito RedGate Memory Profiler, riesco a vedere quali sono le perdite di memoria. Ho filtrato i miei risultati dell'elenco di istanza per oggetti che sono "tenuti in memoria esclusivamente da oggetti dismessi" (ho letto sul forum RedGate che questo è il modo in cui trovi le perdite di memoria). Questo mi ha dato una lunga lista di stringhe che vengono tenute in memoria.

Per ogni stringa, utilizzo il Grafico di conservazione dell'istanza per vedere cosa lo tiene in memoria. Gli oggetti System.string sembrano essere stati memorizzati nella cache a un certo punto da System.Web.Caching.CacheDependency. Se seguo il grafico fino in fondo, passa attraverso varie altre classi incluso System.Collections.Specialized.ListDictionary fino a raggiungere System.Web.FileMonitor. Questo ha un senso in quanto le stringhe sono percorsi verso un file (immagini/PDF/ecc.).

Sembra che il CMS stia memorizzando nella cache i percorsi dei file, ma questi oggetti memorizzati nella cache vengono "filtrati". Nel tempo questo si accumula e mangia RAM.

Scusa, questo è lungo tempo ... C'è un modo per interrompere queste perdite di memoria? O per eliminarli senza ricorrere al riciclo del pool di app? Posso trovare quale classe/codice sta facendo la cache per vedere se posso riparare la perdita?

Answer 1

Sembra il problema molto comune di materiale lasciato in memoria come parte dello stato di sessione. In questo caso, le tue uniche opzioni sono 1. non mettere troppa roba nella sessione di ciascun utente, 2. Impostare la durata della sessione su qualcosa di più breve (il valore predefinito è 20 minuti, penso) e 3. riciclare periodicamente il pool di app .

Come parte di 1. Ho trovato che ci sono "buone maniere" e "cattive vie" di presentazione dei dati in un controllo della griglia di dati. Si consiglia di verificare che si stiano copiando solo i dati necessari e che non si mantengano accidentalmente i riferimenti all'intero datagrid.