Wir haben ungefähr 200 Server, Hyper V, File Cluster und IIS, die alle das gleiche Problem haben: Bei normaler Nutzung tritt auf dem Server ein Ereignis auf, das den RAM auf dem Server voll oder fast voll macht. Sobald dies geschieht, hört der SVCHOST/Workstation-Dienst (aussortiert durch Isolierung des Workstation-Dienstes auf seinen eigenen SVCHOST) auf, Handles/Threads freizugeben, und der von diesem Dienst verwendete Speicher wird nie freigegeben. In einigen Extremfällen haben wir Workstation-Dienste, die bis zu 40 GB RAM auf einem 255 GB-Server verwenden. In einigen Fällen werden auch über 40 Millionen Handles gefunden.
Beim Neustart verschwindet das Problem natürlich und tritt erst wieder auf, wenn der gesamte Speicher verwendet wurde, beispielsweise vom W3-Prozess oder den HyperV-VMs. Danach beginnt der Workstation-Dienst, den gesamten RAM zu beanspruchen. Der Vorgang ist sehr langsam und kann je nach RAM-Menge auf einem Server Wochen/Monate dauern.
Sowohl unsere Hyper-V-Server als auch unsere IIS-Server greifen auf Freigaben für Arbeitsdateien zu. Diese Freigaben befinden sich auf SSD-Speicher und sind daher sehr leistungsfähig. Wir haben alle aktuellen Patches installiert, sind aber noch nicht auf R2 umgestiegen, da wir über viele Tools verfügen, die diesen Schritt erheblich machen würden, und keinen klaren Hinweis darauf finden können, dass dies in R2 behoben wäre.
Wir haben ProcMon und andere Tools ausgeführt, aber auf den problematischsten Servern laufen diese Tools nicht einmal. Auf den anderen zeigen die Ergebnisse, die sie liefern, nur, dass es in diesem Prozess tatsächlich einen Speicherverlust zu geben scheint.
Gibt es eine Möglichkeit, den Speicher dieses Prozesses freizugeben oder den Fehler ganz zu vermeiden? Wir möchten nicht neu starten müssen und können den Prozess nicht neu starten, wenn er sich in einem Fehlerzustand befindet. Der Prozess friert ein.
Wir versuchen, regelmäßige Neustarts zur „Behebung“ dieses Problems zu vermeiden und sind daher für jede Antwort dankbar.
Antwort1
Ich hatte ein unheimlich ähnliches Problem, bei dem der SVChost die Serverleistung zerstörte.
Die Lösung:Es stellte sich heraus, dass mein Ereignisprotokoll voll war. Ich habe es gelöscht und alles lief wieder, als wäre nie etwas passiert.
(Ich empfehle außerdem, die Standardgröße des Ereignisprotokolls zu ändern, siehe unten)
So legen Sie die maximale Protokollgröße mithilfe der Windows-Oberfläche fest
- Starten Sie die Ereignisanzeige.
- Navigieren Sie in der Konsolenstruktur zu dem Ereignisprotokoll, das Sie verwalten möchten, und wählen Sie es aus.
- Klicken Sie im Menü Aktion auf Eigenschaften.
- Stellen Sie unter Maximale Protokollgröße (KB) mithilfe des Drehreglers den gewünschten Wert ein, und klicken Sie auf OK.
Das klingt genau wie das, was hier passiert, aber es war letztendlich wirklich einfach zu beheben. Ein Neustart würde das Problem vorübergehend lösen, aber sobald irgendetwas versuchte, in das Protokoll zu schreiben, geriet alles außer Kontrolle und verbrauchte weiterhin Ressourcen.
Hoffe das hilft!
Antwort2
>Is there a way we can free up the memory from this process ?
Es gibt keine Möglichkeit, zugewiesenen Speicher extern (ordnungsgemäß) freizugeben oder Ressourcen zu verwalten, ohne die fehlerhafte App zu beenden.
>or avoid the bug all together?
Sie haben einen Speicher- und Ressourcenverlust. Das Problem können Sie nur lösen, indem Sie den Verlust finden und entweder dessen Auslöser vermeiden (falls möglich) oder den Verlust auf Quellcodeebene beheben. Im letzten Fall benötigen Sie die Hilfe von Microsoft bei der Erstellung des Patches, aber anscheinend erwarten sie von Ihnen, dass Sie ihnen „genau“ sagen, wo das Problem wirklich liegt.
Sie können versuchen, den Schuldigen zu finden, indem Sie den Speicher-/Ressourcenverlust mit Hilfe von MSAnwendungsprüfer
Antwort3
Das Erstellen von RAM ist einfach, aber keine Lösung.
Für eine gründlichere Untersuchung empfehle ich Sysinternals RAMMAP oder VMMAP. Mit diesen Tools können Sie besser erkennen, was passiert. Sehr häufig handelt es sich um ein Metadateiproblem.
Seit Server 2008 haben wir dieses Problem bei allen Terminalservern, bei denen der Arbeitsspeicher knapp wird und es mit der Zeit zu einem unglaublichen Speicherverbrauch kommt, wenn Anwendungen aus einer Freigabe gestartet werden.
Unsere Problemumgehung besteht darin, die Anwendungen auf einem separaten Terminalserver zu hosten und den Speicherverbrauch häufig zu löschen.
Wir tun dies mit einer selbst entwickelten C++-Befehlszeilenanwendung unter Verwendung von
SetProcessWorkingSetSize() mit SeDebugPrivilege für alle Prozesse.
Es wird dringend empfohlen, so etwas nicht zu tun ;)