Verwendung des Windows 2012 Core Extreme-Speichers im SVCHOST / Workstation-Dienst

Wir haben ungefähr 200 Server, Hyper V, File Cluster und IIS, bei denen alle das gleiche Problem auftreten. Bei normaler Verwendung tritt auf dem Server ein Ereignis auf, bei dem der RAM auf dem Server maximal oder nahezu maximal ist. Sobald dies geschieht, beendet der SVCHOST / Workstation-Dienst (insbesondere durch Isolieren des Workstation-Dienstes auf seinen eigenen SVCHOST) die Freigabe von Handles / Threads, und der von diesem Dienst verwendete Speicher wird niemals freigegeben. In einigen extremen Fällen verfügen wir über Workstation-Dienste, die bis zu 40 GB RAM auf einem 255 GB-Server verwenden. In einigen Fällen wurden auch mehr als 40 Millionen Griffe gefunden.

Beim Neustart verschwindet das Problem natürlich und tritt erst wieder auf, wenn der gesamte Speicher verwendet wurde, z. B. vom W3-Prozess oder den HyperV-VMs. Danach beginnt der Workstation-Dienst, den gesamten Arbeitsspeicher abzurufen. Der Vorgang ist sehr langsam und kann je nach RAM-Speicher auf einem Server Wochen / Monate dauern.

Sowohl unsere Hyper V-Server als auch meine IIS-Server greifen auf Freigaben für Arbeitsdateien zu. Diese Freigaben befinden sich im SSD-Speicher und sind daher sehr leistungsfähig. Wir haben alle aktuellen Patches installiert, sind jedoch nicht auf R2 umgestiegen, da wir über zahlreiche Tools verfügen, die dies zu einem wichtigen Schritt machen und keinen eindeutigen Hinweis darauf finden, dass dies in R2 behoben werden würde.

Wir haben ProcMon und andere Tools ausgeführt, aber auf den problematischsten Servern werden diese Tools nicht einmal ausgeführt. Auf der anderen Seite zeigen die Ergebnisse nur, dass in diesem Prozess tatsächlich ein Speicherverlust vorliegt.

Gibt es eine Möglichkeit, den Speicher von diesem Prozess freizugeben oder den Fehler insgesamt zu vermeiden? Wir möchten nicht neu starten müssen und können den Prozess nicht neu starten, sobald er sich in einem Fehlerzustand befindet. Der Prozess wird eingefroren.

Wir versuchen, regelmäßige Neustarts zu vermeiden, um dieses Problem zu beheben. Daher sind alle Antworten willkommen.

Ich hatte ein unheimlich ähnliches Problem, bei dem der Svchost die Serverleistung zerstörte.

Die Lösung: Es stellte sich heraus, dass ich ein vollständiges Ereignisprotokoll hatte. Ich räumte es auf und alles lief wieder, als wäre nie etwas passiert.

(Ich empfehle außerdem, die Größe des Ereignisprotokolls von der Standardeinstellung zu ändern, siehe unten)

So legen Sie die maximale Protokollgröße über die 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.
- Verwenden Sie unter Maximale Protokollgröße (KB) das Drehfeldsteuerelement, um den gewünschten Wert festzulegen, und klicken Sie auf OK.

Es klingt genau so, wie es hier passiert, war aber eine wirklich einfache Lösung. Ein Neustart würde das Problem vorübergehend lösen, aber sobald irgendetwas versuchte, in das Protokoll zu schreiben, würde alles außer Kontrolle geraten und einfach weiter Ressourcen verschlingen.

Hoffe das hilft!

>Is there a way we can free up the memory from this process ?

Es gibt keine Möglichkeit, den zugewiesenen Speicher extern (ordnungsgemäß) freizugeben oder Ressourcen zu verwalten, ohne die fehlerhafte App zu beenden.

>or avoid the bug all together? 

Es tritt ein Speicher- und Ressourcenverlust auf. Die einzige Möglichkeit, das Problem zu lösen, besteht darin, das Leck zu finden und entweder seinen Auslöser zu vermeiden (falls möglich) oder das Leck auf Quellcode-Ebene zu beheben. Im letzten Fall benötigen Sie Microsoft-Hilfe für die Erstellung des Patches, aber es wird erwartet, dass Sie ihnen "genau" mitteilen, wo das Problem wirklich liegt.

Sie können versuchen, den Schuldigen zu finden, indem Sie den Speicher- / Ressourcenverlust mithilfe von MS Application Verifier lokalisieren

Das Löschen von RAM ist einfach, aber keine Lösung.

Ich empfehle Sysinternals RAMMAP oder VMMAP für eine eingehendere Untersuchung. Mit diesen Tools können Sie besser sehen, was passiert. Sehr oft ist es ein Metadateiproblem.

Seit Server 2008 haben wir dieses Problem mit allen Terminalservern, denen der Speicherplatz ausgeht, mit einem unglaublichen Speicherverbrauch im Laufe der Zeit, wenn Anwendungen von der Freigabe gestartet werden.

Unsere Problemumgehung besteht darin, diese Anwendungen auf einem separaten Terminalserver zu hosten und häufig den Speicherverbrauch zu löschen.

Wir tun dies mit einer selbst entworfenen c ++ - Befehlszeilenanwendung, die
SetProcessWorkingSetSize () mit SeDebugPrivilege für alle Prozesse verwendet

Es wird dringend empfohlen, so etwas nicht zu tun;)