Wir haben IIS auf zwei Servern (IIS8 und 10) ausgeführt und stellen in letzter Zeit einen sehr hohen Speicherverbrauch unserer ASP.NET WebForms-Anwendungen fest, auf die hauptsächlich über ASPX-Seiten zugegriffen wird.
Was passiert, ist, dass unsere Anwendungspools mit der Zeit immer mehr Speicher verbrauchen, bis der physische Speicher auf dem Server (64 GB) fast erschöpft ist. Das ist definitiv nicht normal.
Wir haben versucht, herauszufinden, warum das passiert, aber uns sind die Ideen ausgegangen. Es ist unklar, ob dies ein Speicherverlust in unserer Anwendung oder normales Verhalten ist, also kann vielleicht jemand Licht in die Sache bringen.
Fakten:
Mit der Zeit reservieren UND verwenden die Anwendungspools immer mehr Speicher, der nicht freigegeben wird (der Task-Manager sagt, dass sowohl die Arbeitssatz- als auch die Commit-Größe sehr hoch sind, also wird dieser tatsächlich verwendet bzw. reserviert, oder?).
Speicherprofiler wie ANTS, .dotMemory und .NET MemoryProfiler geben an, dass der verwaltete Speicherverbrauch eher gering ist, etwa 20–200 MB, und zeigen viel nicht verwalteten Speicher an, der verwendet werden würde, aber frei ist.
Sie geben selbst mit Snapshots und detaillierten Profilierungsmethoden keinerlei Hinweise darauf, was die unkontrollierte Nutzung verursachen könnte.
Wenn wir mit der F5-Taste auf die Startseite „hämmern“, ohne sie loszulassen, können wir den Speicherverbrauch in einer Minute auf 2-5 Gigabyte hochtreiben. Das ist ein bisschen verrückt.
Wir wissen, dass IIS-/Anwendungspools dazu neigen, Speicher opportunistisch zu reservieren, je mehr Speicher verfügbar ist, aber das ist viel zu viel.
das einzige, was wir sehen, ist, dass die Startseite mit ihren Steuerelementen und ComponentModel-Objekten im Speicher gehalten wird, es aber nirgendwo in den Speicherprofilern einen einzigen Verweis auf eines unserer Seitenobjekte oder eigenen Namespace-Klassen gibt.
Der Speicherverbrauch war vor einem Jahr angeblich in Ordnung und blieb bei insgesamt 2–3 Gigabyte stehen, aber wir können ihn mit einer alten Version der Anwendung nicht mehr reproduzieren.
es passiert auch bei einer Neuinstallation von IIS unter WIN10.
Die Anwendung ist im Release-Modus erstellt, optimiert und derzeit in eine einzelne DLL kompiliert. Ich habe es auch ohne versucht, Trace-Flag aktiviert und 5 MB groß.
Es scheint, dass wir die Anwendung auseinandernehmen, in mehrere Module aufteilen und sehen müssen, wie sich diese verhalten. Die zur Laufzeit geladenen Assemblys/Bibliotheken können, sollten aber nicht das Problem sein. Wir verweisen eigentlich nicht so oft darauf (FreeTextBox, Microsoft ReportViewer, SharpCompress, Crystal Reports, AjaxControlToolKit 15), wir haben bereits alles außer CrystalReports/AjaxControlToolKit entfernt, um zu sehen, was passiert, haben aber nichts geändert.
Wir verwenden auch viele WebForms-Steuerelemente, darunter manchmal Timer und UpdatePanels.
Wir wissen auch nicht, wie wir den Übeltäter mithilfe von Memoryprofilern finden können, da wir davon ausgehen, dass es einen versteckten Verweis gibt, der dazu führt, dass eine oder mehrere ASPX-Seiten im Speicher festgehalten werden, weil die Instanzen der .NET-Klasse niemals einen Link zu irgendetwas anzeigen.
Wir freuen uns über JEDEN Hinweis, was wir hinsichtlich der Speicherreservierung möglicherweise falsch verstehen oder wie sich dieses Problem mit dem Speicherverbrauch beheben lässt.
Vielen Dank für Ihre Zeit!
BEARBEITEN (vergessen zu erwähnen): – Wir haben GC.Collect/WaitForPendingFinalizers/GC.Collect zu unserer Page_Load-Funktion der Startseite hinzugefügt, um zu sehen, ob es hilft, und es hilft tatsächlich eine Zeit lang oder ein bisschen, bis es eine weitere Drucksituation (mit F5) gibt, in der der Speicherverbrauch einfach wieder extrem ansteigt.
Antwort1
Wenn GC.WaitForPendingFinalizers hilft, könnte dies ein Zeichen für von Threads belegten Speicher sein. Wenn Sie beim Laden der Seite einen neuen separaten Thread starten, könnte dieser viel Speicher belegen. Beginnen Sie mit der Problemdiagnose, indem Sie die Anzahl der Threads im Task-Manager überprüfen.