NSTs blockieren Arbeitsspeicher

Hallo zusammen,

ich habe eine Frage zur Speicherverwaltung eines Servers in Verbindung mit Service Tiers.
Wir haben einen Server, auf welchem mehrere NSTs (NAV 2015 CU25) parallel laufen. Auf jedem Servicetier arbeiten ungefähr gleich viele
Personen. Leider ist es jetzt so, daß nach ca. 3 -4 Tagen immer ca. 80% der 32 GB Arbeitsspeicher von den NSTs belegt sind und
noch immer weiter Speicher allokiert wird. Wir starten die NSTs dann immer neu.
Könnt ihr mir sagen ob es möglich ist, daß die NSTs den Speicher auch selbständig wieder frei geben? Oder ist das eventuell ein Bug?

Vielen Dank.

Hallo,

was steht bei dir in der Datei Microsoft.Dynamics.Nav.Server.exe.config auf der ServiceTier unter

<NetFx40_LegacySecurityPolicy enabled="true"/>?

Steht da "true" oder "false"?

Hallo Patrick,

da steht TRUE.
Was bedeutet der Eintrag?

Viele Grüße

wir hatten/haben deswegen dasselbe Problem.

Wir haben da auch ein Supportfall bei MS. Aber ob das geändert wird, steht in den Sternen.

Was die Einstellung genau macht, steht hier https://blogs.msdn.microsoft.com/nav/2016/05/20/rdlc-report-and-performance-in-microsoft-dynamics-nav-2015-and-2016/

Wir haben da auch ein Supportfall bei MS. Aber ob das geändert wird, steht in den Sternen.

Ich müsste mich schon sehr irren, aber ich tippe auf "nein".
RDLC ist sehr alt und wurde niemals runderneuert. Deshalb fasst das wahrscheinlich auch niemand an, wenn da nicht eine Firma mit 100.000en Arbeitsplätzen betroffen ist und druck macht.

Generell haben wir das gleiche Problem . Nach einigen Tagen läuft der Speicher unserer NSTs voll (Dynamics NAV 2015, CU23).
Obiger Artikel analysiert das Verhalten recht gut, zeigt aber leider keine Lösung auf, wenn man Daten im Kopf oder Fuß vorhalten muss. Falls da also jemand eine geniale Lösung hat, abgesehen davon keine Shared-Variablen zu verwenden, ich höre gerne zu.

Es gibt auch noch mindestens ein anderes Speicherleck bis einschließlich 2015 CU 30, gefixt mit CU 31: Speicherlecks bei Nutzung von Record-Varianten, also Variant Parameter die Records übergeben bekommen. Das kann auch recht schnell eskalieren, bei exzessiver Nutzung innerhalb von Minuten.
Mit der Korrektur ist der Speicherhunger bei Nutzung von Record-Varianten immer noch hoch, aber der Garbage Collector sammelt fleißig und gibt frei, wenn notwendig.
Workaround ohne Update ist die Zuweisung von Records auf Varianten VOR aufruf einer Funktion und Übergabe der zugewiesenen Variante anstatt des Record direct.

Eine Anekdote: Der Titel des Variant-Falls bei Microsoft lautete "Server eating memory like Cookie Monster"