Speicherverbrauch NAV Server

Guten Morgen,

ich stelle immer wieder fest, dass der NAV Server bei der Verarbeitung größerer Datenmengen permanent Arbeitsspeicher beansprucht und diesen auch während und nach der Verarbeitung nicht mehr frei gibt.

Der Nav Server läuft in einer VMWareumgebung auf Windows 2012. Dem Server sind 4 Cores und 6 BG RAM zugewiesen. Beim Aufruf der Codeunit
wird zuerst eine Tabelle mit 300 Datensätzen (findset) durchlaufen. Innherhalb dieser Schleife wird eine weitere Tabelle mit 3 Mio Datensätzen (Findfist, Findlast usw. getestet) durchlaufen, wobei hier immer mit dem Datensatz aus dem 300 Datensätzen gefiltet wird und im Result ca. 4000 Datensätze verarbeitet werden. Bei der Verarbeitung der 4000 Datensätze wird eine Berechnung durchgeführt bei der immer wieder auf eine Tabelle mit 12 Mio Datensätze mit Findfirst zugegriffen wird. Danach wird der Datensatz (aus den 4000) modifiziert. Nach jedem Datensatz (aus den 300) wird ein Commit durchgeführt.

Beispiel:
tab1.setrange --> 300 Sätze
tab1.findset
repeat

tab2.setrange --> 3 MIo Sätze
tab2.findset
repeat
---------------
aufruf funktion
tab3.setrange --> 12 Mio Sätze
tab3.setfilter
tab3.findfirst
exit(wert)
---------------

tab2.validate(feldx, rückgabewert);
tab2.modify

until tab2..

commit
until tab1...

Die Verarbeitung ist sehr schnell. Der separate SQL-Server welcher ausreichend dimensioniert stellt ebenfalls keinen Flaschenhals dar.

Die Einstellungen des NAV-Servers sind alle Default aus der Installation. Nach jedem Satz (aus den 300) werden ca. 300 weitere MB vom Arbeitsspeicher verbraucht. Nach X Sätzen ist dann der Arbeitsspeicher von 6 GB komplett verbraucht. Die Verarbeitung wird enorm langsam.

Ich habe sämtliche find-Befehle ausprobiert, zusätzlich den commit implementiert.

Ich würde jetzt gerne wissen,

1. Warum beansprucht der NAV-Server permanent mehr Speicher, müsste er nicht mal Speicher wieder abgegeben?
2. Mit welchen Einstellungen kann ich den Speicherbedarf künstlich einbremsen damit der NAV Server nicht permanent an seine Grenzen kommt und der RTC auf Grund eines Timeouts abschmiert?
3. Gibt es einen Befehl in der Programmierung um den Speicher freizugeben? Hab bis jetzt nichts gefunden.
4. Oder hab ich einen Fehler in der Programmierung?

Vielen Dank im Voraus.

Markus

Hallo,

zum Speicher kann ich erst mal nichts sagen, aber die zweite Schleife mit dem 3 Mio. Datensätzen würde ich nicht mit einem FINDSET machen. Denn ab über 500 (Defaultwert) gefundenen Datensätzen verhält sich der FINDSET-Befehl wie ein FINDFIRST (erst ab NAV2013 anders) in einer Schleife und das wird ziemlich langsam. Also besser hier tatsächlich FIND('-') nehmen. Auch würde ich den Datensatzt in der Schleife nicht ändern, sondern den Datensatz nochmal mit einem GET holen und diesen ändern.

Hallo,

zum Speicher kann ich erst mal nichts sagen, aber die zweite Schleife mit dem 3 Mio. Datensätzen würde ich nicht mit einem FINDSET machen. Denn ab über 500 (Defaultwert) gefundenen Datensätzen verhält sich der FINDSET-Befehl wie ein FINDFIRST (erst ab NAV2013 anders) in einer Schleife und das wird ziemlich langsam. Also besser hier tatsächlich FIND('-') nehmen. Auch würde ich den Datensatzt in der Schleife nicht ändern, sondern den Datensatz nochmal mit einem GET holen und diesen ändern.

Kannst Du mir/uns dazu eine Quelle geben? Danke

Da mich das auch interessiert hat, habe ich das http://www.der-softwareentwickler-blog. ... zt-werden/ und das http://msdn.microsoft.com/en-us/library/dd355237.aspx dazu gefunden .

Cheers
André

...Denn ab über 500 (Defaultwert)...

Die Zahl 500 stammt aus Zeiten von NAV2009, schon NAV 2009 R2 hat nur 50 Datensätze beim Findset gelesen (außerdem ist dieser Wert konfigurierbar)

Waldo hat in seinem Blog hier schon Zahlen veröffentlicht, die nachweisen dass ein FINDSET in 2009 auch bei einer großen Datensatzanzahl effektiver ist (weniger Zugriffe).

Aber die ganzen Zahlen gelten, wie gesagt, für NAV 2009. NAV 2013 hat einen neuen SQL- Unterbau. Womit diese Zahlen eh hinfällig sein dürften. Genauere Infos zu NAV 2013 und FIND*- Performance hier.

Gruß, Fiddi

3. Gibt es einen Befehl in der Programmierung um den Speicher freizugeben? Hab bis jetzt nichts gefunden.

In C/AL gibt es so etwas nicht, das war bei der Konzeption ein Paradigma die Entwickler von solchen Dingen fernzuhalten.
Für den System Health Check u.a. vom NAV Server gibt es für NAV 2013 ein neues Tool:
Microsoft Dynamics NAV 2013 Management Pack for System Center

Den hohen Speicherverbrauch konnte ich nun auch beobachten, als ich beim OMA die Funktionen rund um die C/AL History benutzt habe.

Dem Server sind 4 Cores und 6 BG RAM zugewiesen.

Also mal ganz ehrlich, NAV kaufen und einsetzen und dann beim RAM knippsig sein. 150 € und der Server ist um 16 GB reicher.

Abgesehen davon bin ich mir gerade nicht sicher ob die Auslagerungsdatei in einer VM genauso arbeitet wie auf einem physischen Rechner.

Das unter .NET (und soweit ich das sehe ist NST in .NET geschrieben) wird der Speicher nicht sofort frei gegeben (Stichwort Garbage-Collector) es sein denn der Programmierer zwingt das Programm dazu.

Noch ne Frage zu "4 Cores" und dem eingesetzten OS: Sind der VM 4 Kerne oder 4 CPU zugeordnet? Ist das OS eine Standard oder Enterprise/Datacenter Version? Bei Standard kann es nämlich sein, dass die klemmt wenn mehr als 2 CPU zugeordnet sind.

Volker

Also mal ganz ehrlich, NAV kaufen und einsetzen und dann beim RAM knippsig sein. 150 € und der Server ist um 16 GB reicher.

also ich denke nicht, dass ein Aufstocken die Lösung ist. Ich nehme an, dass hier einfach ein Testsystem eingesetzt wird, auf dem Performance-Tests durchgeführt werden.
Wenn ich dem Ding unendlich Ram gebe, dann bringt das nix.
Desweiteren werden laut den genannten Aussagen auch die 16gb i-wann voll....somit - nix gekonnt.

Die Hauptfrage ist demnach, warum der NAV-Server den Ram nicht wieder freigibt, wenn er fertig ist.

Hallo,

die erste Frage ist, welchen Build Ihr einsetzt, den würde ich zunächst einmal aktualisieren (7.0.34550 ist aktuell).
zweitens ist die Frage Wer oder Was den Speicher verbraucht, ist der Speicher überhaupt reserviert, oder ist der als Freigebbar markiert, und die DotNet- Garbagecollection würde Sie wegräumen?

Gruß, Fiddi

Naja, ich vermute mal, dass für jeden Datensatz NST-intern ein neues Objekt angelegt wird und ein entsprechendes "dispose" fehlt. Irgendwann kommt dann der Garbage-Collector und löscht nicht mehr benötigte Objekte aus dem Speicher. Aber wohl nicht schnell genug, so dass in diesem Fall RAM ausgeht.

Allerdings habe ich im Kopf, dass man das Verhalten des Garbage-Collectors über das .NET-Framework einstellen kann. http://blog.binarymist.net/2010/10/17/garbage-collection-in-net-4-0/ könnte ein Ausgangspunkt für weitere Nachforschungen sein.

Ein Würgaround könnte sein den NST regelmäßig neu zu starten.

Volker

Noch ne Frage zu "4 Cores" und dem eingesetzten OS: Sind der VM 4 Kerne oder 4 CPU zugeordnet? Ist das OS eine Standard oder Enterprise/Datacenter Version? Bei Standard kann es nämlich sein, dass die klemmt wenn mehr als 2 CPU zugeordnet sind.

Unter Windows Server 2012 gilt die Aussage nicht.
Der Unterschied zwischen Windows Server 2012 Standard und Datacenter ist einzig die Anzahl der installierbaren VMs (2 vs unlimited).

Der Windows Server 2008 R2 Standard kann auch 4 Kerne, Enterprise bis zu 8.

Hi Jan,

Vorsicht. 2012 ist in o. g. der Host. Vom Gast-OS wissen wir hier noch nichts. Außerdem ist nicht die Anzahl der Kerne die Frage, sondern die Anzahl der CPU (Sockel). Win 2008 Std kann nur 2 CPU (Sockel), aber ruhig mi je 4 Kernen. Daher sollte man die Anzahl der CPU in der VM auch auf 2 setzen.

Volker

Naja, ich vermute mal, dass für jeden Datensatz NST-intern ein neues Objekt angelegt wird und ein entsprechendes "dispose" fehlt. Irgendwann kommt dann der Garbage-Collector und löscht nicht mehr benötigte Objekte aus dem Speicher. Aber wohl nicht schnell genug, so dass in diesem Fall RAM ausgeht.

Allerdings habe ich im Kopf, dass man das Verhalten des Garbage-Collectors über das .NET-Framework einstellen kann. http://blog.binarymist.net/2010/10/17/garbage-collection-in-net-4-0/ könnte ein Ausgangspunkt für weitere Nachforschungen sein.

Solange der Standard dann wiederhergestellt wird, wenn MS das bei der NST in Griff bekommen hat. Diese Einstellung gilt ja global und könnte evtl. andere Programme beeinträchtigen.

Ein Würgaround könnte sein den NST regelmäßig neu zu starten.

_Regelmäßig_ die NST neu starten ist nicht mal ein "Würgaround". Das würde nur Sinn machen, wenn ein zweiter NST aufgesetzt ist, der nur diese Verarbeitung macht und dann kann dieser Dienst so oft neu gestarten werden wie man lustig ist. Die NST der Anwender darf davon nicht betroffen sein.

Hi Jan,

Vorsicht. 2012 ist in o. g. der Host. Vom Gast-OS wissen wir hier noch nichts. Außerdem ist nicht die Anzahl der Kerne die Frage, sondern die Anzahl der CPU (Sockel). Win 2008 Std kann nur 2 CPU (Sockel), aber ruhig mi je 4 Kernen. Daher sollte man die Anzahl der CPU in der VM auch auf 2 setzen.

Volker

In Hyper-V definiert man logische Prozessoren, da gibts keine Sockel/Kerne Unterschied, oder eine Zuweisung von Sockel/Kerne zu logischen Prozessor. (Man kann ja auch mehr logische Prozessoren als physische haben, wird von MS aber nicht empfohlen).

Win2008 Standard kann bis zu 4 logische Prozessoren als Gastsystem zugewiesen werden:
http://technet.microsoft.com/en-us/libr ... 68(v=ws.10).aspx

Nur schreibt er VMWare und nicht Hyper-V und genau den Fall mit zuviel (4 statt 2) zugewiesenen CPU hatten wir vor kurzem.

Volker

darf ich fragen, was die frage der kerne mit dem speicherverbrauch zu tun hat? ich versteh den zusammenhang im moment wohl nich :(

Wenn die Zuordnung der Kerne nicht 100% funktioniert, dann funktioniert u. U. der Garbage-Collector weil er auf einem anderen Kern als der Arbeitsprozess ausgeführt wird auch nicht richtig und es erfolgt nie eine Freigabe des Speichers.

Volker

Hallo zusammen,

die VM (VMWare Server) stellt dem Windows 2012 Server 2 Sockets mit 4 virtuellen Prozessoren (Intel Xeon E5-2620 2GHZ) zur Verfügung.
Die Einstellungen für den Carbage Collector habe ich ebenfalls geprüft. Ich habe dazu einen Beitrag im Internet gefunden, allerdings für NAV2009, jedoch auch ohne Erfolg.
http://mibuso.com/blogs/kine/2012/04/24/garbage-collector-in-nav-2009/.

Ich verwende aktuell das Build 34346 vom Februar.

Ich habe jetzt mal an den Einstellungen des NAV-Servers gespielt. Dabei hab ich den Wert Data Cache Size welcher Default auf 9 steht verändert.
Meine Ergebnisse:
- Bei 5 werden ca. 1 GB RAM verwendet
- Bei 6 ca. 2 GB
- bei 7 ca. 4 GB
- bei 9 reicht der RAM von 6 GB (abzüglich andere Dienste) nicht aus.

Microsoft schreibt hier zu:http://msdn.microsoft.com/en-us/library/hh169480(v=nav.70).aspx

For a call to any of the FIND functions, 1024 rows are cached. You can set the size of the cache by using the Data Cache Size setting in the Microsoft Dynamics NAV Server configuration file. The default size is 9, which approximates a cache size of 500 MB. If you increase this number by one, then the cache size doubles.
You can bypass the cache by using the SELECTLATESTVERSION Function (Database).

Ich habe die Funktion SELECTLATESTVERSION implementiert. Leider auch ohne Erfolg.

Viele Grüße

Markus

Hallo,

gibt es denn hierzu neue Erkenntnisse vorallem im Bereich NAV2013. Wir hängen aktuell auch bei unseren Artikelimport welcher sich ca. bei 10% aufhängt da der RAM des Applicationservers komplett überfüllt ist und der Import sich dann irgendwann aufhängt trotz 20GB RAM.

Hallo,

Wir hängen aktuell auch bei unseren Artikelimport welcher sich ca. bei 10% aufhängt da der RAM des Applicationservers komplett überfüllt

Ein bisschen mehr Info wäre schon gut. Wie viele Artikel, welches Format,wieviele Felder,....

Gruß Fiddi

Es handelt sich um ca. 100k Artikel mit jeweils 240 Feldern. Der Import wird von einer XML-Datei eingelesen, welche aus einem Magento-Online Shop exportiert wurden.

wie lange hast du denn den Import mal laufen lassen?
meist fängt sich nav dann wieder!
wie groß ist die XML-Datei in MB

Hallo,

Es handelt sich um ca. 100k Artikel mit jeweils 240 Feldern. Der Import wird von einer XML-Datei eingelesen, welche aus einem Magento-Online Shop exportiert wurden.

Das finde ich schon sehr sportlich ein derartiges Datenvolumen per XML (womöglich noch XML-Port) verarbeiten zu wollen. (ich würde die Datei mal auf eine Größe weit jenseits der 100MB schließen).

So viel ich weiß, verarbeitet NAV XML-Daten nach dem DOM- Prinzip, d.h. alle XML-Daten werden zunächst in den Speicher geladen bevor Sie verarbeitet werden. Das dürfte jeden Rechner vor eine Herausforderung stellen.

Ich würde hier Häppchenweise vorgehen, oder die Daten per CSV verarbeiten. Letzteres hat den Vorteil eines erheblich geringeren Datenvolumens und der Möglichkeit, die Daten sequenziell zu verarbeiten.

Gruß, Fiddi

Hallo,

Es handelt sich um ca. 100k Artikel mit jeweils 240 Feldern. Der Import wird von einer XML-Datei eingelesen, welche aus einem Magento-Online Shop exportiert wurden.

Ich würde hier Häppchenweise vorgehen, oder die Daten per CSV verarbeiten. Letzteres hat den Vorteil eines erheblich geringeren Datenvolumens und der Möglichkeit, die Daten sequenziell zu verarbeiten.

Bei dem Datenvolumen entweder csv über den Client oder gleich die integration services auf dem sql-server.