TopKontor Handwerk 6 und Oracle VirtualBox
Wenn Sie auf einem Windows-PC, auf dem TopKontor Handwerk 6 installiert ist, eine virtuelle Maschine mit Oracle VirtualBox starten wollen, kann Ihnen der Fehler „HostMemoryLow“ einen gehörigen Strich durch die Rechnung machen. In diesem Beitrag erfahren Sie, wie Sie diesen Fehler dauerhaft lösen können.
Kürzlich habe ich unter Oracle VirtualBox eine neue virtuelle Maschine (VM) erstellt. Sowohl der PC selbst als auch die VM laufen unter Windows 10 Pro. Die VM mit 1 GB zugewiesenem Hauptspeicher startete und arbeitete zwar einwandfrei, reagierte aber letztlich doch viel zu träge, um damit wirklich Spaß zu haben.
Was hilft gegen PC-Langsamkeit? RAM! Um also die Performance der VM zu verbessern, habe ich ihr mit Oracle VM VirtualBox Manager einen Hauptspeicher von 8 GB zugewiesen. Und schon gingen die Probleme los: ohne erkennbares Muster wechselte die VM während der Startphase immer wieder in den „Pause“-Modus.
D. h., der Startvorgang der virtuellen Maschine pausierte. Dann musste ich den „Pause“-Modus manuell deaktivieren, um die Startphase wieder fortzusetzen. Bis zur Anzeige des Windows-Anmeldebildschirms wiederholte sich diese Schikane etwas 2 – 20 mal pro Startvorgang. Als es wieder einmal soweit war, und der Anmelde-Bildschirm der VM nach dieser Prozedur auf keinen Tastendruck mehr reagierte, war klar:
Dieses Problem muss an der Wurzel gepackt und gelöst werden!
„HostMemoryLow“ – Das Problem analysieren
VirtualBox protokolliert wichtige Vorgänge in Protokolldateien. Wenn man im VirtualBox Manager per rechtem Mausklick das Kontextmenü der betreffenden VM öffnet, führt die Menüzeile „Zeige Log…“ geradewegs zu den Protokolldateien und öffnet diese in einem neuen Fenster.
Als die VM während des Starts wieder ungewollt in den „Pause“-Modus gewechselt war, schaute ich mir die Log-Datei einmal genauer an. Die letzten und damit neuesten Einträge hatten folgenden Inhalt:
00:00:12.080516 Host RAM: 11045MB available
00:00:12.080520 VM: Raising runtime error ‚HostMemoryLow‘ (fFlags=0x2)
00:00:12.080533 Changing the VM state from ‚RUNNING‘ to ‚SUSPENDING‘
00:00:12.080626 PDMR3Suspend: after 0 ms, 1 loops: 1 async tasks – ahci/0
00:00:12.625672 AIOMgr: Endpoint for file ‚xxxxx.vmdk‘ (flags 000c0781) created successfully
00:00:13.075681 PDMR3Suspend: 995 124 562 ns run time
00:00:13.075693 Changing the VM state from ‚SUSPENDING‘ to ‚SUSPENDED‘
00:00:13.075701 Console: Machine state changed to ‚Paused‘
00:00:13.075828 Console: VM runtime error: fatal=false, errorID=HostMemoryLow message=“Unable to allocate and lock memory. The virtual machine will be paused. Please close applications to free up memory or close the VM“
Zeile 2 beschreibt das Problem mit „HostMemoryLow„, was bedeutet, dass das Host-System (also der „echte“ PC) der VM nicht ausreichend RAM zur Verfügung stellt.
Scheinbar im Widerspruch dazu dokumentiert aber die erste Zeile, dass zu diesem Zeitpunkt 11.045 MB Host RAM verfügbar waren. Warum also erhält die VM nicht ihre konfigurierten 8 GB RAM zugewiesen, wo doch ausreichend Speicher vorhanden ist?
Oder anders gefragt: wer oder was verursacht den HostMemoryLow-Fehler?
Den Verursacher herausfinden
Wer ist Verursacher für das Problem, dass ein PC zwar über ausreichend freies RAM verfügt, dieser Speicher aber nur zu einem geringen Bruchtteil einer virtuellen Maschine unter VirtualBox zugewiesen werden kann? Worin genau liegt die Ursache?
In stundenlanger Google-Recherche habe ich zwar Hintergrundwissen in Hülle und Fülle über die Funktionsweise von VirtualBox und die Speicherverwaltung von Windows 10 erhalten, aber kein einziger der gefundenen Lösungstipps – die übrigens alle mindestens 3 Jahre alt oder noch älter waren – hat das Problem an diesem PC gelöst.
Die Windows-Speicherverwaltung
Windows verwaltet den RAM in Speicherblöcken von 4 k Bytes. Diensten und Programmen, die unter Windows aktiv sind, wird vom Windows Speichermanager benötigter Speicher zugewiesen. Der Windows Speichermanager kümmert sich darum, dass der installierte Hauuptspeicher optimal unter den um Systemressourcen konkurrierenden Diensten und Programmen aufgeteilt wird.
Wenn ein Programm z. B. 1 GB RAM vom Windows Speichermanager anfordert, dann erhält es die benötigte Menge an Speicherblöcken zugewiesen. Aus Programmsicht handelt es sich dabei um einen einzigen, zusammenhängenden Bereich zusammenhängender 4k-Speicherblöcke. Dieser Speicherbereich erscheint aber nur „virtuell“ auf Programmebene als ein zusammenhängender Bereich. In Wirklichkeit stellt der Windows Speichermanager virtuell zusammenhängende Speicherblöcke aus einer entsprechenden Anzahl physikalischer RAM-Blöcke zusammen, die nicht unmittelbar nebeneinander liegen müssen, sondern in der Regel verteilt (fragmentiert) vorliegen.
Eine besondere Anforderung von VirtualBox
Damit gibt sich Oracle VirtualBox für Windows aber nicht zufrieden. VirtualBox kann einer VM maximal nur solchen Hauptspeicher zuweisen, der in einem einzigen, zusammenhängenden Bereich auf physikalischer RAM-Ebene verfügbar ist.
Deshalb ist es für VirtualBox auch völlig belanglos, wie groß das verfügbare Host RAM ist, wenn es um die Reservierung von Hauptspeicher für eine virtuelle Maschine geht. So erklärt sich die Fehlermeldung „HostMemoryLow“, obwohl gleichzeitig mehr als genug Host RAM verfügbar ist.
Wer zerstückelt das Host RAM?
Meine Arbeitsthese aufgrund dieser Erkenntnis lautete:
„Obwohl insgesamt ausreichend Host RAM verfügbar ist, gibt es beim Start der VM keinen einzigen, physikalisch zusammenhängenden Speicherbereich in der Größe von 8 GB, um ihn der VM zuweisen zu können.“
Nun machte ich mich darin, diese These zu untermauern.
Ich startete den Windows-PC neu, nachdem ich zuvor alle Nicht-Microsoft-Dienste über „msconfig.exe“(Register „Dienste“) deaktiviert hatte. Wenn jetzt die VM ohne den „HostMemoryLow“-Fehler starten würde, dann wäre damit meine Arbeitsthese bewiesen, dass einer der auf dem PC aktiven Dienste das RAM quasi „zerstückelt“.
Der erste Start der VM mit 8 GB Hauptspeicher funktionierte reibungslos. Tatsächlich: die VM hatte 8 GB RAM verfügbar und war deshalb deutlich schneller, so dass man jetzt sinnvoll damit arbeiten kann. Um ganz sicher zu gehen, habe ich den Test noch einige Male wiederholt.
Das Ergebnis war zu 100% wiederholbar: ohne die Nicht-Microsoft-Dienste gibt es kein zerstückeltes RAM, und die VM startet ohne „HostMemoryLow“-Fehler.
Nun ging es darum, den „Schuldigen“ im Ausschlussverfahren festzustellen: welcher Dienst fragmentiert das RAM?
Ein Blick auf die Liste der Nicht-Microsoft-Dienste machte mich auf „Advantage Database Server“ aufmerksam. Er wird bei der Installation von TopKontor Handwerk 6 als Komponente für die SQL-Datenbankverwaltung mit ausgeliefert. Der Advantage Database Server (kurz: ADS) blickt auf eine über 20-jährige Entwicklungsgeschichte zurück und funktioniert sehr stabil und zuverlässig.
ADS ist aber hier und da etwas angestaubt. SAP scheint keinen allzu großen Wert auf seine Weiterentwicklung zu legen. Deshalb fiel meine erste Wahl auf ADS: Treffer! Ein aktivierter ADS führte in VirtualBox zum Fehler „HostMemoryLow“. Bei deaktiviertem ADS trat der Fehler nicht auf.
Zwischenergebnis:
Advantage Database Server kann den Hauptspeicher (RAM) so stark fragmentieren, dass es keine physikalisch zusammenhängenden Speicherblöcke von mehr als 1 GB Größe mehr gibt.
Advantage Database Server und VirtualBox gemeinsam nutzen
Das Problem ist analysiert, die Ursache herausgearbeitet und die Schuldigen sind gefunden: VirtualBox stellt etwas eigentümliche Anforderungen an den Hauptspeicher, die von Advantage Database Server unterlaufen werden.
Nun werden auf dem betreffenden PC aber beide Programme tagtäglich nebeneinander benötigt. Was soll ich sagen? Es gibt eine Möglichkeit, ADS davon abzubringen, wertvolles RAM so maßlos zu fragmentieren.
Einen Hinweis darauf liefert der (englischsprachige) Artikel „Advantage Database Server 64-bit Memory Usage“ in der Advantage Developer Zone. Hier ist beschrieben, dass ADS einen Datenbank-Cache verwaltet und dafür Hauptspeicher in einem dynamischen Verfahren reserviert, „aber nicht mehr als 85%“. WTF!?
Sind die verrückt? Eine überschaubare, schnuckelige SQL-Datenbank nimmt sich standardmäßig das Recht heraus, dass sie bis zu 85% des PC-RAM für ihr eigenes Caching reserviert? Das mag vor 20 Jahren bei RAM-Größen zwischen 640 KB und einigen MB angemessen gewesen sein. Aber heute!? An einem PC mit etlichen GB an RAM sollten doch andere Regeln gelten!
Glücklicherweise beinhaltet der Artikel eine Anleitung, wie man den ADS-Cache verkleinern oder völlig deaktivieren kann.
Meine Arbeitsthese zu diesem Zeitpunkt war:
„Das RAM-Caching von ADS ist für die Speicherfragmentierung verantwortlich. Ohne dieses Caching werde ich ADS problemlos mit VirtualBox gleichzeitig auf einem Windows-PC nutzen können.“
ADS-Cache deaktivieren
Um den Cache-Speicher von ADS auf eine bestimmte Speichergröße zu begrenzen, führen Sie den folgenden Arbeitsschritt aus, wobei Sie das „x“ durch die gewünschte Speichergröße in Megabyte (MB) ersetzen. Um das ADS-Caching komplett auszuschalten, setzen Sie den Wert auf „0“.
Ergänzen oder bearbeiten Sie den folgenden Wert vom Typ DWORD mit dem Windows Registrierungs-Editor (regedit.exe):
\HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Advantage\Configuration\MAX_CACHE_MEMORY=x
Auf dem Windows-PC war dieser Wert noch nicht in der Registrierungs-Datenbank vorhanden. Nachdem ich ihn also mit dem Wert „0“ neu angelegt habe, habe ich den PC neu gestartet.
Ergebnis
Was soll ich sagen:
seit der Deaktivierung des ADS-eigenen Cache startet VirtualBox die VM mit 8 GB Hauptspeicher völlig fehlerfrei. Die VM hat genügend Hauptspeicher und arbeitet flüssig.
TopKontor Handwerk 6 zeigt sich von dieser Änderung völlig unbeeindruckt. Das ist gut so. Die Bürosoftware funktioniert einwandfrei. Es sind überhaupt keine Leistungseinbußen festzustellen. Das Programm rennt ohne ADS-Cache genauso schnell wie mit ADS-Cache.
Da „das Internet“ die Konstellation von TopKontor Handwerk und VirtualBox offensichtlich noch nicht kennt, hoffe ich, mit diesem Tipp Power-Anwendern von TopKontor Handwerk oder Fachhandels-Kollegen etwas Zeit bei der Fehlersuche einzusparen.
