german_nav_developer: Hauptspeicherbedarf von server.exe und slave.exe im Windows Task Manager

[Blog bot]

mit diesem Blogeintrag möchte ich kurz erläutern, was server.exe und slave.exe für eine Bedeutung beim nativen NAV Datenbankserver haben und wie der Hauptspeicherbedarf dieser ausführbaren Programme im Windows Task Manager zu interpretieren ist: Bei der server.exe handelt es sich um den nativen NAV Datenbankserver selbst als zentrales Kernstück, der unter Windows Betriebssystemen meist als Windows Dienst installiert und gestartet wird. Mittels einer MS-DOS Eingabeaufforderung kann die server.exe allerdings alternativ auch als Prozess manuell gestartet werden. Die slave.exe ist der Prozess, der für das Lesen und Schreiben in die jeweiligen nativen NAV Datenbankteile (*.fdb) zuständig ist. Pro Datenbankteil wird jeweils 1 slave.exe Prozess gestartet und zusätzlich existiert dann noch eine weiterer slave.exe Prozesse für die Administration der anderen slave.exe Prozesse und die Verwaltung des optionalen Commit Caches. Wenn eine native Datenbank also z. B. aus 3 Datenbankteilen besteht (DB1.fdb+DB2.fdb+DB3.fdb) und die server.exe in Verbindung damit wie folgt gestartet wird in einer MS-DOS Eingabeaufforderung: server.exe servername=MyServer, database=DBDB1.fdb+EBDB2.fdb+FBDB3.fdb, cache=950000, commitcache=yes</p>

dann werden parallel von der server.exe 4 slave.exe Prozesse gestartet. Wenn Sie nun den Hauptspeicherbedarf der slave.exe Prozesse und des server.exe Prozesses im Windows Task Manager betrachten, dann gilt hier tatsächlich nur der Bedarf des server.exe Prozesses. Der Windows Task Manager ist nicht in der Lage, den Bedarf der slave.exe Prozesse korrekt anzugeben, weil es sich dabei um Prozesse handelt, die zum Startzeitpunkt der server.exe von diesem Prozess selbst parallel aufgerufen werden. Der Hauptspeicherbedarf der server.exe entspricht ungefähr dem gewählten Cache (im Beispiel oben 950 MB) + einem kleinen Administrationsaufschlag. Wenn der server.exe Prozess mit CommitCache=yes gestartet wird (was MS aus Performancegründen im Kundenechtbetrieb immer empfiehlt!), dann wird maximal 2/3 des Caches als Schreibcache in Richtung Festplattensubsystem verwendet, wohingegen bei CommitCache=no der gesamte Cache als reiner Lesecache vom Festplattensubsystem zum tragen kommt. </p>

Viele Grüße Stefan Rißling Specialist Support Engineer Dynamics NAV EMEA Customer Support & Services - SMS&P</p><div style="clear:both;"></div>Далее