Ich habe einige Leistungsprobleme mit einem VM-Image (ich habe keinen Zugriff auf den VM-Host, nur auf das Gastbetriebssystem).
Ich versuche herauszufinden, warum es Zeiträume zwischen 10 und 60 Sekunden gibt, in denen der Server einfach aufhört, Anfragen zu versenden.
Dabei laufen mehrere Leistungsindikatoren, aber mir ist etwas sehr Merkwürdiges aufgefallen: Kurz nach Beginn dieser „toten“ Perioden fallen alle meine ASP.NET-Anwendungsindikatoren (aktive Sitzungen, Anzahl der Pipeline-Instanzen, ausgeführte Anfragen) auf Null und steigen dann wieder auf den normalen Wert, sobald wir die „tote“ Periode verlassen. Siehe Grafik hier:
Ich weiß mit hundertprozentiger Sicherheit, dass diese Sitzungen, obwohl sie aus den Zählerstatistiken verschwunden sind, über den gesamten Zeitraum hinweg noch aktiv waren.
Hat jemand dieses Verhalten bei den Zählern schon einmal gesehen? Ist es möglich, dass eine Art VM-Ressourcenmangel das Fehlverhalten dieser Zähler und möglicherweise die Inaktivitätsperioden im Allgemeinen verursacht?
Antwort1
Wir hatten gerade dieses Problem – es hat mich verrückt gemacht und viele andere Probleme verursacht. Während dieses Tiefpunkts blieben die Anfragen stecken BeginRequestoder MapRequestHandler– dann begannen sie plötzlich alle mehr als 10 Sekunden später wieder mit dem Durchlaufen der Zustände.
Die eigentliche Ursache war, dass die IIS-App eine Datei in ihr eigenes /bin-Verzeichnis geschrieben hat. IIS hat dies erkannt und ein Soft-Recycling durchgeführt, wodurch die Anzahl der lauschenden Worker vorübergehend auf 0 reduziert wurde (was ich durch Pipeline Instance Countdiese Frage erkannt habe und der Grund dafür ist, warum ich sie gefunden habe). Dies wurde jedoch in keinem anderen Tool als neuer Prozess oder Ähnliches angezeigt.
Wir haben es gefunden, indem wir einen Minidump aller IIS-Prozesse erstellt haben mitDebugDiag2von MS während einer der Verlangsamungen, gefunden durch Pingen eines kleinen Endpunkts mit Fiddler. DebugDiag hat einen CrashHangAnalysis-Bericht. Dieser Bericht enthielt viele Informationen – es dauerte eine Weile, sie HttpRuntime Shutdown Reportmit einem Stacktrace einschließlich System.Web.DirectoryMonitor.FireNotificationsund zu finden System.Web.Compilation.BuildManager.OnWebHashFileChange.
Das veranlasste mich, im Prod-Bin-Verzeichnis nachzuschauen und festzustellen, dass dort ein fehlerhaftes E-Mail-Protokoll geschrieben wurde, was dazu führte, dass IIS die App recycelte. Das war besonders seltsam, weil das Speicherdiagramm der App in New Relic nur das zeigte, was wie ein stetiger Speicherverlust aussah, aber in Wirklichkeit wurde die ganze App (sozusagen) neu gestartet und vergrößerte nur den vorhandenen Speicher. Es sah nicht wie eine normale Wiederverwendung aus und die PIDs blieben gleich. Keine Ahnung, was für eine Zauberei IIS damit anstellen wollte.
Auch das Ändern der erweiterten IIS AppPool-Einstellung Disable Recycling for Configuration Changeshat Truedieses Problem nicht verhindert, wie indiese andere Frage. Wir mussten Binärdateien ändern und erneut bereitstellen, um das Problem zu beheben.