it-swarm.com.de

Hohe Speichernutzung mit W3WP-Anwendungspool IIS 7

Ich habe eine Website-Anwendung in einem eigenen Anwendungspool auf IIS 7.0. Die Anwendung ist eine ASP.NET MVC 3-Website.

Ich habe festgestellt, dass die Speichernutzung für diese Anwendungen entsprechend w3wp IIS Arbeiterservice ist ziemlich hoch (800 MB, mit einigen Schwankungen).

Ich versuche das Problem zu diagnostizieren und habe Folgendes versucht:

Ich habe das Zwischenspeichern von Ausgabeseiten für die Website auf IIS= Ebene deaktiviert und dann den Anwendungspool wiederverwendet. Dadurch wird der w3wp-Prozess neu gestartet. Die Speichernutzung für diesen Prozess steigt dann langsam auf ca. 800 MB an Dies dauert etwa 30 Sekunden. Es werden derzeit keine Seitenanforderungen verarbeitet. Wenn ich die Website von IIS) aus neu starte, ändert sich die Speichergröße des Prozesses nicht.

Ich habe versucht, eine Debug-Kopie der Anwendung von VS 2010 auszuführen. Es gibt keine Probleme mit der Speichernutzung.

Einige Ideen, die ich habe/Fragen sind:

Hat dieses Problem mit dem Website-Code zu tun? - Angesichts der Tatsache, dass die Speicherraketen vor dem Senden/Verarbeiten von Seitenanforderungen ausgelöst haben, würde ich davon ausgehen, dass dies KEIN Code-Problem ist.

In der in MVC integrierten Anwendung ist keine Verarbeitung des Cachings beschrieben.

Die Website verwendet die Echtzeitanzeige von Daten, verwendet regelmäßig Ajax-Anforderungen und wird im Allgemeinen für längere Zeiträume offen gelassen.

Warum springt die Speichernutzung in die Höhe, nachdem die Anwendung wiederverwendet wurde und keine Benutzeranforderungen gesendet wurden? Liegt das daran, dass alte Cache-Informationen von der Festplatte in den Speicher geladen werden?

Die Anwendung stürzt NICHT ab, ich mache mir nur Sorgen um die Speichernutzung, es ist keine so große Website ...

Alle Ideen/Hilfe bei der Suche nach dem Grund für dieses Problem wäre dankbar.

23
user989056

Ich schaue nur, mein Server und meine Pools verwenden 900-1000 MB virtuellen Speicher und 380 MB Arbeitsspeicher. Meine Seiten laufen seit einigen Jahren problemlos und ich habe sie von allen Seiten überprüft. Mein Pool wird nie wiederverwendet und der Server wird bis zum nächsten Update mit 40% stabilem freiem physischem Speicher weiter ausgeführt.

Wenn Ihr Speicher nicht weiter wächst, ist dieser Speicher der Code plus die Daten, die Sie als statisch festgelegt haben, const, die Zeichenfolge und der mögliche Cache in Ihrer Anwendung.

Sie können Prozess-Explorer verwenden, um den Arbeits- und den virtuellen Arbeitsspeicher anzuzeigen.

Sie können auch überlegen, ein Profil für Ihren Code auszuführen, um festzustellen, ob ein "Speicherverlust" oder ein anderes Problem vorliegt. Suchen Sie einen von Google: https://www.google.com/search?hl=de&q=asp.net+memory+profiler .

14
Aristos

Wenn Sie es sich leisten können, einen Debugger zu verwenden, installieren Sie am besten Windows Debugging Tools und ermitteln Sie mit WinDbg und SOS.dll genau, was sich im Speicher befindet.

sobald Sie die Tools installiert haben, können Sie:

  1. Starten Sie Windbg.exe mit erhöhten Rechten (als Administrator)
  2. Verwenden Sie "File-> Attach To Process" und wählen Sie w3wp.exe für die App, die Sie herausfinden möchten. Wenn Sie viele haben, können Sie den Task-Manager verwenden und die Befehlszeilenspalte hinzufügen, um die PID anzuzeigen, oder mit IIS Manager-> Arbeitsprozesse, um dies herauszufinden, und dann diesen Prozess in WinDBG auswählen.
  3. lauf:
  4. .loadby sos clr
  5. ! dumpheap -stat

Zu diesem Zeitpunkt sollten Sie in der Lage sein, alle Typen nach dem größten Speicherverbrauch sortiert anzuzeigen, sodass Sie mit den Typen am unteren Rand beginnen können. (Ich würde empfehlen, Strings und Object auszuschließen, da dies normalerweise eine Nebenwirkung ist und nicht die Ursache). Verwenden Sie "! Dumpheap-type-here", um die Instanzen zu finden, und verwenden Sie "! Gcroot", um herauszufinden, warum sie sich im Speicher befinden, möglicherweise aufgrund eines statischen Felds oder eines durchgesickerten Event-Handlers, nicht verworfener WCF-Kanäle oder ähnliches das sind gemeinsame Quellen.

18

Das trifft hier wahrscheinlich nicht zu, aber ich dachte, ich würde es für ein gutes Maß einsetzen. Vor kurzem hatte ich ein Problem damit, dass mein Gedächtnis voll ausgelastet war, wenn es wirklich 80% davon aufräumen konnte. Problem: Es hat gedacht, dass es ungefähr 2 Gig mehr sind als es tatsächlich der Fall war, also war der GC ziemlich faul. (Es war auf einen VM ware Bug zurückzuführen - Windows meldete 8 Gig, aber physisch gab es nur 6,4). Siehe Blog . http://www.worthalook.net/2014)/01/give-back-memory /

3
GarethReid

Etwas, das helfen könnte: Wenn Sie die web.config "umschreiben" (öffnen/speichern), wird Ihre Anwendung zurückgesetzt, und Sie sollten die Speichernutzung ab diesem Punkt überwachen. Wenn es während der Verwendung weiter wächst, kann dies zu einem Speicherverlust oder zu verrücktem Caching führen. Möglicherweise können Sie feststellen, welche Aktionen auf Ihrer Site zu einer Speichererweiterung führen. Während einer langen Zeit sollte die Speichernutzung einer Anwendung stabil sein.

0
Allie