[GELÖST] Arbeitsspeicher läuft voll in NAV 2018 CU14

[MichaelK]

Hallo,

wir haben das Problem, dass der NST den Arbeitsspeicher nicht freigibt. Der Server hat schon über 60 GB Arbeitsspeicher. Nach ca. zwei Wochen ist der Speicher aufgebraucht und der Dienst muss neugestartet werden. Wir haben bis zu CU27 die Einträge angeschaut. Nirgendwo wird dort über ein Speicherproblem berichtet.

Kennt jemand von euch dieses Problem? Gibt es da schon eine Lösung?

Gruß

Michael

Zuletzt geändert von MichaelK am 12. Mai 2020 08:31, insgesamt 2-mal geändert.

Mh das ist natürlich ziemlich viel.

Was steht denn im Dienst bei "Data Cache Size"?

hi,

was macht der NST? Werden viele Reports gedruckt --- Stichwort Archivierung?

Hallo,

DataCacheSize = 11

Es kann schon sein, dass da viele Reports gedruckt werden. Was hat das aber damit zu tun, dass der Dienst zwei Wochen lang den Speicherplatz nicht freigibt, so dass der Arbeitsspeicher voll läuft?

Gruß

Michael

11 ist ok, wenn ich das noch richtig in Kopf habe. Das sind 2 GB. Ich kenne das Phänomen, allerdings nur bis 10-11 GB und unter NAV 2017. Dort waren es tatsächlich Memory Leaks durch Reports mit globalen shared Variablen. Aber 60 GB pro NST hört sich heftig an, zumal unter 2018 mit eigener AppDomain für die Berichte gearbeitet wird.

Hallo Carsten,

wie kann man solche Memory Leaks aufspüren?

Gruß

Michael

Es kann schon sein, dass da viele Reports gedruckt werden. Was hat das aber damit zu tun, dass der Dienst zwei Wochen lang den Speicherplatz nicht freigibt, so dass der Arbeitsspeicher voll läuft?

sorry, aber ich wollte nur helfen, wenn du aber die Fragen nicht beantworten willst, dann kann ich auch nix machen

Hallo Stephan,

tut mir leid, wenn ich den Eindruck erweckt habe, als ob ich deine Hilfe nicht benötige.

Geht es im Zusammenhang deiner Frage um Memory Leaks wie sie von Carsten beschrieben wurden? Ich habe im Moment nicht wirklich die Übersicht ob viele Reports über diesen NST laufen. Wenn es aber wichtig ist, dann kann ich mich da gerne schlau machen.

Gruß

Michael

Hallo,

wichtig wäre es erst mal die Frage nach der "Database Cache Size" zu beantworten.

Wenn da ein großer Wert drin steht (gerechnet wird 2^WERT MBytes für den Speicher), dann ist das u.U. O.K.

Gruß Fiddi

...wichtig wäre es erst mal die Frage nach der "Database Cache Size" zu beantworten.

Hat er oben schon. > 11

@Michael - kein Problem ;) -> hatte vorhin noch keinen Kaffee :P
worum es mir geht - ist das ein "normaler NST" oder einer, mit aktiviertem TaskScheduler?
wieviele NSTs sind im Einsatz?
gibt es abweichende Einstellungen zum "standard" NST DataCache ist zwar angepasst, aber im üblichen Rahmen (11)
wieviele User laufen über den NST?

So wie es aussieht ist das ein bekanntes Problem, welches erst in BC14 vollständig gefixt wurde. In NAV 2017 CU39 findet man folgenden Fix:

The NAV Server memory consumption keeps growing if you print a lot of reports in Microsoft Dynamics NAV.

In NAV 2018 CU 26 ist das wie folgt vermerkt:

Memory improvements from newer versions.

Danke für eure Unterstützung.

Kannst du mal kurz einen Erfahrungsbericht posten, inwiefern das CU geholfen hat? Danke.

Hallo Horst,

bei dem Hotfix ging es darum, dass die folgenden Parameter aus BC bis auf NAV 2017 übernommen werden.

https://cloudblogs.microsoft.com/dynamics365/it/2019/05/15/rdlc-report-performance-enhancements-in-dynamics-365-business-central/

Mit diesem Parametern muss man herumspielen damit das Speicherproblem behoben wird.

Gruß

Michael

Danke für die Info.

Ich verstehe das so, dass das theoretisch nicht nur bei Reports auftreten kann, sondern das eigentlich mit sämtlichen .NET-Aufrufen passieren kann, die nicht isoliert sind und die in der CAS Policy laufen. Kann das jemand bestätigen oder hat schon Erfahrungen damit gemacht?

Also ich habe von MS folgende Erklärung erhalten, warum man diesen Fix eingebaut hat:

In this hotfix we managed memory leak within Dynamics NAV. We had a memory leak reported by taking a memory dump file the root cause could be analyzed and resolved. It turns out that they come from a SendTraceTag which will eventually save all the strings.
This should be an issue on any object that has any of the following commands:

COMMIT
StopSession
StartSession

Macht für mich erstmal viel mehr Sinn als die Sache mit dem .NET Code in RDLC Reports. Was meint ihr? Oder hat evtl. jemand damit schon konkrete Erfahrungen gesammelt?

Wir haben bis zu CU27 die Einträge angeschaut.

Im aktuellen CU 30 ist ein Fix mit ID 344501 für „Out of Memory“.

Vielen Dank für den Hinweis.