Relativ überrascht stellte ich auf einem recht frisch eingerichtetem Windows Server 2019 Standard mit installierter Hyper-V Rolle fest, das der gesamte Arbeitsspeicher belegt ist.

Aufgefallen war das Ganze durch Netzwerkprobleme wie beispielweise stockendes RDP und Pings die teils hohe Laufzeiten oder gar Timeouts hatten, von weiteren Punkten ganz zu Schweigen.

Die drei laufenden VMs (1x Windows Server 2012 R2 Standard, 2x Debian 10 Buster) belegen allerdings lediglich insgesamt 9 GB (+ Overhead) des 32 GB im Host installierten RAMs. Dynamischer Arbeitsspeicher ist bei allen VMs deaktiviert, d.h. diese Funktion sollte nicht die Ursache dieses Problems zu sein.

Weder der Task-Manager, noch der Ressourcenmonitor noch externe Tools PoolMonX lieferten einen Hinweis darauf welcher Prozess oder Treiber für die exzessive Speichernutzung verantwortlich sind. Bei bzw. mit Hyper-V im Speziellen ist die Sache sowieso etwas anders, da der insgesamt belegte Arbeitsspeicher zwar in den Bordmitteln angezeigt wird, aber man dies keinem Prozess zuordnen kann.

Ersichtlich, wenn auch nicht im Detail, wird das erst beispielswiese mit Tools wie RamMap (Introduction to the new Sysinternals tool: RAMMap) auf der Registerkarte “Use Counts” unter “Driver Locked”. Einen interesanten Beitrag dazu gibt es hier:

Joe Freeman – Seeing Hyper-V and Docker memory usage on Windows

Zugegeben, diese Büchse ist nur Teil-Produktiv, die Linux-VMs werden durchaus produktiv genutzt, der Host ist unter anderem Spielwiese für aktuelle Software-Tests. Das ist sogar so gewollt, da nicht alles unter Labor-Bedingungen geprüft werden kann und soll. Ferner ist das System nicht ins Monitoring eingebunden, letzteres sollten wir dann nun doch mal nachholen.

Irgendwie ist das nun aufgetretene Problem sogar Hilf- sowie Lehrreich aber auch Nervig. Speicherlecks (Memory Leaks) zu diagnostizieren ist oft schwierig, wie man das eine oder andere Mal bereits hier im Blog nachlesen konnte. Die folgenden Anwendungen liefen, als das Problem festgestellt wurde, das bedeutet nicht, das diese für den Fehler verantwortlich sind:

• Mozilla Firefox
• Notepad++
• BackupAssist ER
• Altaro Physical Server Backup
• CrystalDiskInfo
• WinSCP
• KiTTY

Das Beenden der Anwendungen und Dienste sowie der virtuellen Computer half nichts, ein Neustart musste her und danach waren wieder die eher zu erwartenden round about 12 GB belegt.

Nicht das wir uns falsch verstehen: Arbeitsspeicher ist dazu da, genutzt zu werden! Wird dieser allerdings “zugemüllt” oder nach der aktiven Nutzung nicht wieder freigegeben, gibt es Probleme!

Kommt man der Ursache nicht auf die Schliche, besteht der Klassiker darin, regelmässig den oder die Server neuzustarten. Das funktioniert zwar auch bei einer solchen Kombi wie dieser hier, ist allerdings in Verbindung mit Virtualisierung, also hier Hyper-V und bei bestimmten Beenden- sowie Startreihenfolge der virtueller Computer etwas aufwendiger.

Nach dem Neustart versuchten wir das Problem nochmals zu provozieren, wobei unklar war, wann das Leck auftrat und über welchen Zeitraum der Arbeitsspeicher belegt wurde. Jedenfalls trat es zumindest nicht mehr auf. Dennoch haben wir etwas aufgeräumt und folgendes Deinstalliert:

• BackupAssist ER
• Altaro Physical Server Backup

Mit letzterem waren wir nicht ganz so glücklich und ersteres war schlicht die letzte Anwendung die installiert wurde (ca. zwei Wochen her). Die darauffolgenden Tage wurde die Arbeitsspeicher-Nutzung beobachtet, da fiel soweit nichts mehr auf.

Mit RAMMap und dem Task-Manager wurde zumindest weiter geschaut. Je nach Programm wird zeitweise mehr Arbeitsspeicher genutzt, vor allem unter “Process Private” in den Spalten “Total” und “Active”. interessant dabei ist, das dieser nicht immer zeitnah wieder freigegeben wird, selbst wenn das Programm bereits beendet wurde.

Ist zwar “Blasphemie” aber mittels Sordum Reduce Memory (siehe auch Windows 10: RAM-Auslastung reduzieren) konnte die Nutzung wieder auf 12,0 GB reduziert. Nebenbei bemerkt: Es ist eine CLI verfügbar, d.h. “ReduceMemory_x64.exe /O” wäre möglich und bietet (ungetestet) die Möglichkeit via Aufgabe etwas zu basteln.

Via RAMMap und “Empty – Empty Working Sets” lässt sich ebenfalls Arbeitsspeicher wieder freigeben, Reduce Memory ist allerdings effizienter.

Bleibt die Frage nach der Ursache und was man dagegen effektiv tun kann. Womöglich alles nur ein Zufall, wobei neulich bei einem Kunden ein neuer Server 2019 mit einem BSOD in Sachen Memory Management abgeschmiert ist.

Update 17.05.2021

Erstmal vielen Dank an alle die mir via Kommentare oder auf anderen Wegen Tipps und Erfahrungswerte haben zukommen lassen. Ich war nun nicht dauerhaft an dem Thema dran, in Ruhe gelassen hat es mich allerdings auch nicht. Nach langen Versuchen, Beobachten und Testen konnte die Ursache auf folgenden Dienst eingegrenzt werden:

Marvell Storage Management Service (Dienstname "Marvell Storage Management")

Dieser gehört zu einem Marvell SATA-/RAID-Controller. Was genau da Schief läuft weiß ich leider nicht, funktionale Einschränkungen durch die Deaktivierung des Dienstes habe ich bislang keine beobachtet. Die Software ist schon recht alt (Stand: 2016) und eine neuere Version konnte bislang nicht gefunden werden. Der betroffene Server läuft seit dem Ausknipsen dieses Dienstes, mal abgesehen von den Neustarts bedingt durch Windows Updates, seit Wochen problemlos durch.

Andy

Verheiratet, Vater von zwei Kindern, eines an der Hand, eines im Herzen. Schon immer Technik-Freund, seit 2001 in der IT tätig und seit über 10 Jahren begeisterter Blogger. Mit meiner Firma IT-Service Weber kümmern wir uns um alle IT-Belange von gewerblichen Kunden und unterstützen zusätzlich sowohl Partner als auch Kollegen.