W3wp.exe mit 100% CPU - Wo starten Sie?

Question

Eine ASP.NET -Web -App, die auf IIS6 ausgeführt wird, schießt regelmäßig die CPU bis zu 100%. Es ist die W3WP, die in diesen Episoden für fast alle CPU -Verwendung verantwortlich ist. Die CPU bleibt bei 100% zwischen ein paar Minuten bis zu einer Stunde festgehalten.

Dies befindet sich auf einem Staging -Server und die Website erhält zu diesem Zeitpunkt nur sehr leichte Verkehr von Tester.

Wir führen Ants -Profiler auf dem Server aus, aber es war nicht angemessen.

Wo können wir herausfinden, was diese Episoden verursacht und welchen Code die CPU während der ganzen Zeit beschäftigt ist?

Answer 1

1. Standard -Windows -Performance -Zähler (suchen Sie nach anderen korrelierten Aktivitäten, wie z. Sie können sie sowohl aus Code als auch aus Perfmon lesen (um die Datenerfassung auszulösen, wenn die CPU -Verwendung beispielsweise einen Schwellenwert überschreitet).
2. Benutzerdefinierte Leistungszähler (insbesondere für Off-Box-Anfragen und andere Anrufe, bei denen die Ausführungszeit ungewiss ist)
3. Laden Sie Tests mit Tools wie Visual Studio -Teamtest oder WCAT
4. Wenn Sie auf IIS 7 testen oder ein Upgrade durchführen können, können Sie fehlgeschlagene Anforderungsverfolgung konfigurieren, um eine Trace zu generieren, wenn Anforderungen mehr Zeit in Anspruch nehmen
5. Verwenden Sie Logparser, um zu sehen, welche Anfragen zum Zeitpunkt der CPU -Spike eingetroffen sind
6. Code-Bewertungen / Walk-Throughs (insbesondere suchen Sie nach Schleifen, die möglicherweise nicht ordnungsgemäß enden, z. B. wenn ein Fehler auftritt, sowie Sperren und potenzielle Threading-Probleme, wie z.
7. CPU- und Speicherprofilerstellung (kann bei einem Produktionssystem schwierig sein)
8. Process Explorer
9. Windows Resource Monitor
10. Detaillierte Fehlerprotokollierung
11. Benutzerdefinierte Spurenprotokollierung, einschließlich Details zur Ausführungszeit (möglicherweise bedingt, basierend auf dem CPU-Use-Perf-Zähler)
12. Gehen die Fehler auf, wenn sich die Apppool recycelt? Wenn ja, könnte es eine Ahnung sein.

Answer 2

Es ist keine große Antwort, aber Sie müssen möglicherweise die alte Schule besuchen und einen Bild -Schnappschuss des IIS -Prozesses erfassen und es debuggen. Vielleicht möchten Sie auch auschecken Tess Ferrandez's Blog - Sie ist ein Kick A ** Microsoft Escalation Engineer und ihr Blog konzentriert sich auf das Debuggen von Windows ASP.NET, aber das Blog ist für das Windows -Debugging im Allgemeinen relevant. Wenn Sie das ASP.NET -Tag auswählen (mit dem ich verknüpft habe), sehen Sie mehrere Elemente, die ähnlich sind.

Answer 3

Wenn Ihre CPU bis zu 100% spitzt und dort bleibt, ist es sehr wahrscheinlich, dass Sie entweder ein Deadlock -Szenario oder eine unendliche Schleife haben. Ein Profiler scheint eine gute Wahl für die Suche nach einer unendlichen Schleife zu sein. Deadlocks sind jedoch viel schwieriger aufzuspüren.

Answer 4

Process Explorer ist ein ausgezeichnetes Werkzeug für die Fehlerbehebung. Sie können es versuchen, das Problem von High zu finden Zentralprozessor Verwendungszweck. Es gibt Ihnen einen Einblick in die Art und Weise, wie Ihre Anwendung funktioniert.

Sie können es auch versuchen Procdump Um den Prozess abzuwerfen und zu analysieren, was wirklich in der CPU passiert ist.

Answer 5

Schauen Sie sich auch Ihre Perfmon -Zähler an. Sie können Ihnen sagen, wo ein Großteil dieser CPU -Zeit verbracht wird. Hier ist ein Link zu den häufigsten Zählern zu verwenden:

• http://www.microsoft.com/technet/prodtechnol/windowserver2003/library/iis/852720c8-7589-49c3-a9d1-73fdfc9126f0.mspx?mfr=trus
• http://www.microsoft.com/technet/prodtechnol/windowserver2003/library/iis/be425785-c1a4-432c-837c-a03345f3885e.mspx?mfr=tru

Answer 6

Wir hatten dies auf einer rekursiven Abfrage, die Tonnen von Daten in die Ausgabe geworfen hat. Haben Sie doppelt überprüft, ob alles beendet ist und es keine unendlichen Schleifen gibt?

Könnte versuchen, es mit einer einzelnen Seite einzugrenzen - wir haben festgestellt Und zeitaufwändig, aber wenn Sie es nicht mit einer Codeverfolgung finden können, haben Sie möglicherweise kein Glück -

Wir konnten IIS -Protokolldateien verwenden, um sie auf eine Reihe von Seiten zu verfolgen, die verdächtig waren -

Ich hoffe, das hilft !

Answer 7

Dies ist bestenfalls eine Vermutung, aber vielleicht baut und bereitet Ihr Entwicklungsteam die Anwendung im Debug -Modus an, an der deren Stelle des Release -Modus eingesetzt werden. Dies führt zu dem Auftreten von .pdb -Dateien. Dies impliziert, dass Ihre Anwendung zusätzliche Ressourcen zur Erfassung des Systemstaates und des Debuggens von Informationen während der Ausführung Ihres Systems aufnimmt und zu einer weiteren Verbrauchsnutzung führt.

Es wäre also einfach genug, um sicherzustellen, dass sie im Freigabemodus aufbauen und eingesetzt werden.

Answer 8

Ich weiß, dass dies ein sehr alter Beitrag ist, aber dies ist auch ein häufiges Problem. Alle vorgeschlagenen Methoden sind sehr nett, aber sie werden immer auf einen Prozess hinweisen, und es gibt viele Chancen, dass wir bereits wissen, dass unsere Website Probleme macht, aber wir möchten nur wissen, welche spezifische Seite zu viel Zeit in der Verarbeitung verbringt. Das präziseste und einfachste Werkzeug ist meiner Meinung nach IIS selbst.

1. Klicken Sie einfach auf Ihren Server im linken Bereich von IIS.
2. Klicken Sie im Hauptbereich auf "Arbeiterprozesse". Sie sehen bereits, welcher Anwendungspool zu viel CPU nimmt.
3. Doppelklicken Sie auf diese Zeile (schließlich aktualisieren Sie, indem Sie auf "All" anzeigen), um zu sehen, welche Seiten in diesem Pool zu viel CPU -Zeit ("Zeitverringerung" -Spalte verbrauchen)

Answer 9

Wenn Sie eine Seite identifizieren, deren Laden einige Zeit benötigt, verwenden Sie SharePoint's Entwickler Dashboard Um zu sehen, welche Komponente Zeit braucht.