[gelöst] Maximale Speicherauslastung durch den NST

[ThomasFerstl]

Heyho,

ich habe aktuell mit dem Problem zu kämpfen, dass der NAV Service Tier (NAV 2016 CU4 Build 44974) sich gelegentlich sämtlichen verfügbaren Speicher unter den Nagel reißt und anschließend nicht mehr reagiert. Für die Anwender sieht es dann so aus, als wäre Navision abgestürzt.

Im Ereignisprotokoll finde ich nur einen Warneintrag "Cache synchronization took longer than the specified CacheSynchronizationPeriod." Ereignis-ID 202.

Hat irgendjemand schon so ein Verhalten beobachtet?

Zuletzt geändert von ThomasFerstl am 14. November 2017 11:23, insgesamt 1-mal geändert.

Das Problem der maximalen Speicherauslastung scheint derzeit ausschließlich beim Report-Druck aufzutreten, allerdings nicht reproduzierbar.

Kann jetzt gerade den anderen Thread nicht kopieren, aber benutzt ihr externe DLLs direkt im RDLC?

Kann jetzt gerade den anderen Thread nicht kopieren

Da du vermutlich den hier meintest: viewtopic.php?f=66&t=31832&p=121065#p121065
Bitteschön

Danke. Genau den

Hallo Carsten,

aufgefallen ist das Phänomen beispielsweise an einem Report von Akquinet, der eine SEPA Lastschriftdatei erzeugt. Externe DLLs scheinen dort nicht direkt verwendet zu werden. Allerdings werden in diesem Report viele weitere Objekte aufgerufen, wie beispielsweise die XML DOM Management Codeunit, in der wiederum DotNET-Variablen benutzt werden.

Grundsätzlich muss das Problem aber in den Griff zu bekommen sein. Es kann doch nicht sein, dass der Aufruf eines Reports manchmal (aber nicht immer) den kompletten Server lahmlegt.

FG
Thomas

Bei dem trat dann das Problem auf nehme ich an. Ursache kann aber auch etwas Ganz anderes sein.

Richtig. Es ist auch nur ein Report von potentiell mehreren, bei dem das Phänomen eben besonders deutlich aufgefallen ist, und es lässt sich, wie gesagt, nicht reproduzieren.

Um mal noch etwas mehr Informationen zu geben:
In unserem Fall wurden/werden sehr viele Berichte als PDF versendet. Um das Problem großer DataSets zu umgehen haben wir eine DLL genutzt, um direkt aus dem RDLC Barcode-Bilder zu erzeugen und zu drucken.

Dadurch musste der NAV Server zwangsläufig eine eigene AppDomain erstellen (Sicherheit, "unbekannte" DLL usw.) und der Datenaustausch zwischen NAV Server und diesem anderen Prozess geschieht über Marshalling, also letztendlich Konvertierungen. Große Datenmengen = viele Konvertierungen.

Auch wenn Microsoft das nicht bestätigen konnte, dass bei diesem Prozess Speicherlecks auftreten, da es primär um gähnende Performance ging, konnten wir das Problem umgehen, indem wir, was wir eigentlich nicht wollten, die Barcode-Bilder im C/AL erzeugt und im DataSet übergeben hatten.

Dadurch lief auch der ReportViewer in der AppDomain des NST und das Problem taucht aktuell nicht mehr auf. Hohe Speicherauslastung und dadurch hervorgerufen (konnte ebenfalls nicht wirklich technisch bewiesen werden) Probleme beim Kompilieren von Objekten (csc.exe). Aber auch ohne Beweis läuft es nun problemlos.

Hmm, ich denke nicht, dass dieses Problem bei uns zutrifft.

Auf welchem Wert steht denn die CacheSynchronizationPeriod in der CustomSettings.Config auf dem Server?

Code:

  <add key="CacheSynchronizationPeriod" value="0:00:30" />

Vorgabe ist also 30 Sekunden, die kann man natürlich auch ändern, dann dauert es aber länger bis Änderungen zwischen den Instanzen durchgereicht werden.
http://www.comporsys.de/dynamics-nav-blog/dynamics-nav-server-versteckter-parameter-cachesynchronizationperiod/

Wenn wir den dann schon dabei sind, wieviel Speicher hat der Server auf dem der NAV Server läuft, was läuft sonst noch (mehrere NST?) und welchen Wert haben Data Cache Size und Metadata Provider Cache Size?

Auch wenn es aktuellen Fall wohl nicht möglich ist und falls es wirklich das XML DOM sein sollte:
XML-Dateien kann man auch in C/AL elegant direkt erzeugen.
Das ist zwar schreibintensiver, aber am stabilsten.
Die Werte schreibt man in einen Stack (Indexvariable), und die Tags werden mit 'Push' gebildet und und 'Pop' geschlossen.
Das Prinzip wird hier erklärt:
http://freecode.com/articles/build-your-own-xml-parser
So ist man autark unterwegs, frei von Fremd-Dlls und .NET-Dschungel .

Hallo Kai,

der Hinweis auf die XML DOM war nur ein Beispiel, was in dem Report noch alles aufgerufen wird. Ich könnte allerdings nicht guten Gewissens den Finger drauf legen und sagen "Jepp, das ist der Übeltäter!".

Der Server selbst hat 8 GB RAM und es ist ein NST für 3 User eingerichtet. Da der Server eigens für den Betrieb des NST eingerichtet wurde, läuft dort nichts anderes. An der Default Konfiguration habe ich nichts geändert (bis auf den Datenbanknamen natürlich). Die Data Cache Size liegt bei 9, die Metadata Provider Cache Size bei 150.

FG
Thomas

Das Problem scheint sich soweit erledigt zu haben ... das Problem mit der Speicherauslastung ist offenbar aus unerfindlichen Gründen nur in den ersten Tagen aufgetreten und danach nicht mehr.