MSDynamics.de

Hallo,

ich habe zur Zeit auf einem Server das Problem, dass ein Programm, das in der Jobqueue im Minuten-Takt aufgerufen wird, oder die Jobqueue selbst, einen Windows Server nach wenigen Tagen bis zum "Out of Resources"- Crash bringt, weil der komplette verfügbare Arbeitsspeicher vom- Servicetier der Jobqueue verbraucht wird.

Das gleiche Programm hat unter NAV 2013 ohne Änderungen über Monate problemlos funktioniert.

Eingesetzt wird z.Zt. Build (8.00.46293), der das ganze - subjektiv - eher noch verschlimmert hat!?

Gruß Fiddi

Hallo fiddi,

Normalerweise stellst du diese Fragen: Was genau macht der Job? Wird mit vielen temporären Daten gearbeitet? .NET?

Wir haben ca. 15 wiederkehrende Jobs die von einigen Sekunden bis zu 5-6 Stunden laufen. Dann auch einige 100 Einmal-Jobs, alles ohne diese Art von Problemen. Nachdem wir, hatte ich schon öfter erwähnt, externe DLLs bzw. Die Eigenschaft UseExternalAssemblies auf No gesetzt hatten. Vorher war es ähnlich: OOM, Compilerfehler etc.

Normalerweise stellst du diese Fragen: Was genau macht der Job? Wird mit vielen temporären Daten gearbeitet? .NET?

ich wollte die Fragen bzw. Antworten nicht von vornherein in eine bestimmte Richtung lenken.

Also ich habe bisher festgestellt, das ein Jobqueue- Servicetier unter NAV2015 mit der Zeit immer mehr Speicher verbraucht, auch wenn er nur eine leere Codeunit aufruft, der zusätzliche Speicherverbrauch pro Tag hält sich dann allerdings in Grenzen.

Im konkreten Fall läuft eine CU , die per Dotnet SQLConnection/SQLCommand einen extern SQL- Server abfragt bzw. aktualisiert. Das bringt dann pro Tag etwa 2GB an Speicherverbrauch, wenn die CU alle Minute ausgeführt wird.

Gruß Fiddi

Dann schlage ich vor, dass du ein Repro mit einfachen temporären Daten machst, so dass es schneller geht und das Ganze an Microsoft meldest.
Ich würde aber sicherstellen, dass es mit purem C/AL auch zu Ressourcenfehlern kommt.

Ich würde aber sicherstellen, dass es mit purem C/AL auch zu Ressourcenfehlern kommt.

das Problem bei der Sache ist, das man nicht so genau feststellen kann, ob das normales Caching ist, oder ein anderer Speicherfresser.

Gruß Fiddi

Ich weiss

@SilverX

kennst du ein brauchbares Tool um den verwendeten Arbeitsspeicher eines Prozesses zu analysieren?

Gruß Fiddi

PerfMon? ... (musste noch Zeichen einbauen, da es mindestens 10 sein müssen)

Hallo,

ich habe das ganze noch mal ein wenig getestet, und den JOB noch mal so geändert, das nicht mehr SQLConnection und SQLCommand verwendet werden, sondern die ADODB- Equivalente.

Damit scheint das Speicherzuwachs jetzt nicht mehr so groß zu sein!?

Gruß Fiddi

Hallo Fiddi,
ich habe eure Konversation zu diesem Arbeitsspeicher-Problem gelesen.
Ich habe dieses Problem zwar nicht (bis jetzt), aber weil ich deinen letzten Beitrag mit dem Hinweis "ADODB" gelesen habe, würde mich ein kleines Code-Beispiel dazu interessieren.

ich habe eine DotNet-Variable (ADODB.Connection) angelegt und wollte damit auf eine externe SQL-Tabelle zugreifen.
Die Variable besitzt lt. Symbol Menu keinen Constructor.
Wenn ich dann aber mit Open eine Verbindung öffnen möchte, erhalte ich den Fehler, dass noch keine Instanz der DotNet-Variablen erstellt wurde.

Hallo,

Entschuldigung, hätte mich schon mal dazu melden sollen. Die Ursache scheint nicht AdoDB oder SQL-Dotnet zu sein ,sondern der Parameter "Data Cache Size" des Servers, der war zu hoch eingestellt.

Stellt man den auf realistische Werte für den Server ein, bleibt der Speicherbedarf in Grenzen. Das kann sogar weniger sein 9 was 2^9 = 512 MB im Default entspricht, wenn man weiß, das da immer neue Werte produziert, sprich eingefügt, werden.
Das Problem war nur, das sich der NAV2013 völlig unauffällig benahm, und der NAV 2015 gleich richtig zugeschlagen hatte.

Gruß Fiddi