Understanding Speicherverluste in ASP.net mit RedGate Memory Profiler

Question

Ich betreibe eine große ASP.net 4.0-Website. Es verwendet ein beliebtes .Net-Content-Management-System, hat Tausende von Content-Elementen, Hunderte von gleichzeitigen Nutzern - ist im Grunde eine schwere Website.

Im Laufe von 1 Tag kann die Speicherauslastung des Arbeitsprozesses IIS7 auf 8-10 GB steigen. Der Server hat 16 GB installiert und ist derzeit so eingestellt, dass er den App-Pool einmal pro Tag recycelt.

Ich werde unter Druck gesetzt, Speicherverbrauch zu reduzieren. Ein großer Teil der Speicherbelegung ist auf das Zwischenspeichern großer Datenstrings zurückzuführen - das Cache-Intervall ist jedoch nur auf 5 bis 10 Minuten festgelegt -, sodass diese Zeichenfolgen schließlich aus dem Speicher gelöscht werden.

Allerdings kann ich RedGate Memory Profiler sehen, was ich denke, sind Speicherlecks. Ich habe meine Ergebnisse der Instanzliste nach Objekten gefiltert, die "ausschließlich von disponierten Objekten im Speicher gehalten werden" (ich habe im RedGate-Forum gelesen, dass Sie auf diese Weise Speicherlecks finden). Dies gab mir eine lange Liste von Strings, die im Speicher gehalten werden.

Für jede Zeichenfolge verwende ich Instanz Retention Graph, um zu sehen, was es im Speicher hält. Die System.string Objekte scheinen irgendwann von System.Web.Caching.CacheDependency zwischengespeichert worden zu sein. Wenn ich dem Graphen den ganzen Weg folge, durchläuft er verschiedene andere Klassen einschließlich System.Collections.Specialized.ListDictionary, bis er System.Web.FileMonitor erreicht. Dies ist sinnvoll, da die Strings Pfade zu einer Datei sind (Bilder/PDFs/etc).

Es scheint, dass der CMS Pfade zu Dateien zwischenspeichert, aber diese zwischengespeicherten Objekte sind dann "durchgesickert". Mit der Zeit baut sich das auf und verschlingt RAM.

Entschuldigung das ist langatmig ... Gibt es eine Möglichkeit für mich, diese Speicherlecks zu stoppen? Oder sie zu löschen, ohne den App-Pool zu recyceln? Kann ich herausfinden, welche Klasse/welcher Code das Caching durchführt, um zu sehen, ob ich das Leck beheben kann?

Answer 1

Es klingt wie das sehr häufige Problem von Sachen, die im Sitzungszustand im Speicher belassen werden. Wenn das der Fall ist, sind Ihre einzigen Optionen 1. Stellen Sie nicht so viel Zeug in die Sitzung jedes Benutzers, 2. Setzen Sie die Lebensdauer der Sitzung auf etwas kürzer (der Standardwert ist 20 Minuten, denke ich) und 3. recyceln Sie den App-Pool regelmäßig .

Als Teil von 1. Ich habe festgestellt, dass es "gute Wege" und "schlechte Wege" gibt, Daten in einem Data Grid Control zu präsentieren. Möglicherweise möchten Sie überprüfen, dass Sie nur die Daten kopieren, die Sie benötigen, und nicht versehentlich Verweise auf das gesamte Datagrid beibehalten.