Mal wieder ein interessantes Kundenproblem…

Problemstellung:

In einer Kundenumgebung wird eine Terminalserverumgebung unter W2k8 mit 48 GB Hauptspeicher und etwa 15-20 Benutzter pro Server betrieben. Auf den Einsatz einer Auslagerungsdatei wurde verzichtet da genügend Hauptspeicher pro Benutzer vorhanden – ist auch im weiteren Verlauf ohne Bedeutung. Die Benutzer bekommen auf einmal in der Hauptanwendung – eine JAVA-basierte Anwendung – die Meldung „Out of virtual Memory“. Allerdings zeigte der Task Manager eine Hauptspeicherbelegung von 40 %, der Ressourcenmonitor eine zu 100 % belegte Auslagerungsdatei (Wir hatten doch keine???) bzw. einen zu 100 % belegten virtuellen Speicher.

Problemanalyse und -ursache

Der Auslöser war ein Wechsel der zugrundeliegenden JAVA-Runtime von 32-Bit auf 64-Bit. Auf Grund der Portabilität von JAVA ist dies ja möglich. Die 64-Bit-Runtime war vom Anwendungshersteller getestet und freigegeben. Dies geschah auch mit dem bekannten Ansatz „64-Bit ist ja performanter“.

Jetzt muss man sich tiefer mit Hauptspeichermanagement beschäftigen. (ganz tief ist dies möglich in diesem Blog-Beitrag von Mark Russinovich: http://blogs.technet.com/b/markrussinovich/archive/2008/11/17/3155406.aspx). Neben den tatsächlich genutzten Hauptspeicher-Bytes gibt es noch die sogenannten „commited Bytes“ bei einer Anwendung. Eine Anwendung kann sich Hauptspeicherbereiche ist seinem virtuellen Adressbereich „committen“ (zusichern) lassen. Damit kann die Anwendung sich Hauptspeicherbereiche sichern die sie vielleicht mal braucht. Dies kann geschehen, weil der Bereich im physischen Bereich zusammenliegen soll oder weil die Anwendung „hamstert“.

Leider werden die „committed Bytes“ ab W2k8 nicht mehr im Task Manager angezeigt – Zitat aus dem Blogbeitrag: „On Vista and Server 2008, Task Manager doesn’t show the commit charge graph and labels the current commit charge and limit values with „Page File“ (despite the fact that they will be non-zero values even if you have no paging file)“ – damit hätten wir die Erklärung für die Anzeigen zur Auslagerungsdatei. Die richtigen Aussagen bekommt man nur im „Process Explorer“ von Microsoft/Sysinternals (auch „der bessere Taskmanager“ genannt). Und hier wurde richtig angezeigt: Auslastung des physikalischen Hauptspeichers bei etwa 30 %, Committed Bytes 100%.

Damit stellte sich die Frage: Wieviel kann nun eine Anwendung committen? Bei 32-Bit-Anwendungen sind dies 2 GB, bei 64-Bit-Anwendung sind dies theoretisch rund 8 TB.

Was war passiert: Durch einen noch nicht geklärten Anwendungsfehler hat die Anwendung versucht möglichst viel Hauptspeicher zu „committen“ – man könnte auch von „pessimistischen Speicher-Locking“ oder „hamstern“ sprechen. Bei der 32-Bit-Version kein Problem da maximal 2 GB möglich: max. 2 GB * max. 20 Benutzer + BS < 48 GB. Bei einen Bedarf über 2 GB hat sich nur die einzelne Anwendung/der einzelne Benutzer lahm gelegt. In der 64-Bit-Umgebung war da mehr drin und damit hat sich die Anwendung pro Benutzer zu viel Hauptspeicher „committed“ ohne ihn wirklich zu nutzen. Und damit eine Anwendung/ein Benutzer ein „out of Memory“ des gesamten Servers erreicht.

Leider erkennt man solche Fehler im Normalfall in keinen Tests und Abnahmen sondern erst im Echtbetrieb…

Was lernen wir:

• Es gibt verschiedene „Out of Memorys“ bei Microsoft – und mehr als genug physischer Hauptspeicher kann trotzdem nicht genug sein
• Jeder Umstieg von 32-Bit auf 64-Bit selbst in abgeschlossenen und fachlich getesteten Anwendungen will genau begleitet und überwacht werden
• Man sollte sich neben den Standard-Werkzeugen auch mit weiterführenden Monitoringtools auseinandersetzen
• Ein fortwährendes und pro-aktives Monitoring aller Umgebungen ist von hoher Bedeutung