Wenn ich einen Cloud-Service für Windows Azure bereitstelle, wird eine Reihe von VSPerf.exe-Instanzen gestartet - alles von 1 bis 5.
Zwischen ihnen verbrauchen sie die gesamte CPU und keiner der Prozesse beendet sich jemals selbst.
Wenn ich mich per Fernzugriff mit der Instanz verbinde und die Prozesse manuell beende, werden sie bei der nächsten Anfrage neu gestartet. Wenn der Prozess während der Anforderung beendet wird, ist die Anforderung erfolgreich und die Seite wird wie erwartet angezeigt und funktioniert.
Der einzige Unterschied zwischen einer früheren Bereitstellung ist, dass ich auf .NET 4.5 aktualisiert und daher den Cloud-Dienst auf Server 2012 aktualisiert habe.
Was könnte das verursachen?
Für jeden fehlgeschlagenen Start werden 2 Ereignisse protokolliert:
VsPerf Tool Error: Error starting data collection with a dedicated process D:\Program Files (x86)\Microsoft Visual Studio 11.0\Team Tools\Performance Tools\VSPerf.
.NET Runtime version 4.0.30319.18010 - Loading profiler failed during CoCreateInstance. Profiler CLSID: '{44a86cad-f7ee-429c-83eb-f3cde3b87b70}'. HRESULT: 0x80040111. Process ID (decimal): 1444. Message ID: [0x2504].
Das VSPerf-Problem tritt nicht auf, nachdem eine neue Instanz erstellt oder die Maschinen neu erstellt wurden (zumindest ist das ein Fix (eine nervige und zeitraubende Lösung) für den Moment).
Überprüfen Sie die Azure-Veröffentlichungseinstellungen in Visual Studio. Ich wette, dass Sie die Profilerstellung auf der Registerkarte "Erweitert" aktiviert haben.
Gleiches Problem, 2 Prozesse von VSPerf.exe brennen 100% der CPU auf der zweiten Rolleninstanz. IIS reagiert auf diese Instanz nicht mehr. Wir hatten genau das gleiche Problem 4 Monate zurück, verschwand "irgendwie" als Profiling aktiviert wurde, nur als wir dieses Problem mit MSFT-Unterstützung debuggen (jemand in MSFT kennt dieses Problem). Aber ohne das Problem reproduzieren zu können (wir hatten nur Screenshots) wurde es fallen gelassen.
Seit ich es wieder sehe, 5 Minuten zurück und da Azure SDK 2.0 es leicht macht, Diagnoseprotokolle zu greifen (im Gegensatz zum Konfigurationsritual von SDK 1.8), ist hier etwas Nützliches für die nächsten Leute, die Sinn machen
Der Kernfehler ist Application VsPerf Tool Error: Error starting data collection with a dedicated process D:\Program Files (x86)\Microsoft Visual Studio 11.0\Team Tools\Performance Tools\VSPerf.
mit den detaillierten Logs (4 Einträge) unten. Interessanterweise hatte ich zwei Prozesse von VSPerf.exe, die 100% der CPU brannten und auch 2 Log-Einträge hatten ....
Das nächste, was ich zu einer Problemumgehung gefunden habe, ist das Erstellen einer Startaufgabe
%Vor% wobei VSPerf.cmd
ein einfacher Launcher ist
für ein PowerShell-Skript, das versucht, überaktive VSPerf-Instanzen zu löschen:
%Vor%Es funktioniert manchmal, aber nicht immer. Vorschläge für Verbesserungen der Zuverlässigkeit sind willkommen.
Tags und Links asp.net-mvc azure c# hosting