13. Februar 2017 12:08
Hallo zusammen,
wir haben gerade auf NAV 2016 umgestellt und die Performance wird mit der Zeit, in der der Server läuft, immer schlechter.
Der Server hat 64 GB und der SQL Server ist auf 48 GB RAM begrenzt. Der SQL nimmt sich auch den komplett zugewiesenen RAM.
Zusätzlich haben wir noch NAV Anywhere im Einsatz mit denen unsere Handscanner arbeiten und den Versand zu realisieren.
tasknavision.PNG
Hat da jemand einen Tipp für mich?
VG
Torsten
Du hast keine ausreichende Berechtigung, um die Dateianhänge dieses Beitrags anzusehen.
13. Februar 2017 12:18
Hallo Torsten,
herzlich Willkommen im Forum.
Zu deiner Frage: Dazu müsste man herausfinden welcher Prozess für die SQL-Server-Last verantwortlich ist. Das kann man entweder über den Taskmanager machen, um den Servicetier herauszufinden, der den Ärger macht. Und dann prüfen was der Servicetier ausführt (ich hoffe Ihr habt nicht nur den einen für alle eurer Dienste)
Zum anderen kann man versuchen mit den SQL-Server- Tools bzw. dem SQL-Server-Monitor herausfinden. Was der Servicetier da gerade auf dem SQL-Server triebt, und dann versuchen herauszufinden, welches Modul da der Übeltäter ist.
Gruß Fiddi
13. Februar 2017 12:29
Hallo Fiddi,
vielen Dank für Deine Antwort.
Vielleicht kannst Du mir noch kurz erklären was Du mit dem Prozess meinst? Evtl. das hier?
tasknavision1.PNG
wie stelle ich das denn am besten mit Aktivitätsmonitor im SQL an?
VG
Torsten
Du hast keine ausreichende Berechtigung, um die Dateianhänge dieses Beitrags anzusehen.
13. Februar 2017 14:23
Hallo.
du benötigst dafür das SQL-Server Managmentstudio. Aber wenn du keinerlei Erfahrung damit hast, dann sagen dir die Ergebnisse des Monitors gar nichts.
Gruß Fiddi
13. Februar 2017 14:33
Hi,
grundsätzlich ist doch der RAM-Verbrauch nichts schlechtes - RAM soll ja genutzt werden.
Wie macht sich denn der Performanceverlust bemerkbar?
-> ist ständig die Performance im Keller, oder nur bei bestimmten Operationen?
Am Servicetier können auch noch div. Einstellungen vorgenommen werden, die für die Performance entscheidend sein können.
Von welcher Version seid ihr gekommen? (2009 classic / RTC?)
Seit wann läuft die DB bei euch unter 2016?
Habt ihr Wartungsaufgaben für die SQL-DB (z.B.: Indexe etc. optimieren/neuerstellen)
13. Februar 2017 14:48
Der Client verliert die Verbindung zum Server, der ist halt total ausgelastet.
Ja, wir sind von 2009 gekommen, die Datenbank wurde dann durch alle nachfolgenden Versionen konvertiert.
Am Servicetier wurde in den Einstellungen nichts verändert, es ist alles so geblieben.
Die Datenbank läuft seit Anfang des Jahres unter 2016
Wartungsaufgaben gibt es, Integrität wird überprüft, Indizes werden eingeschlossen. Transaktionsprotokoll wird gesichert
13. Februar 2017 15:32
Torsten hat geschrieben:Der Client verliert die Verbindung zum Server, der ist halt total ausgelastet.
hmmm ok - also ausgelastet ist er nur im RAM - wobei bei 64Gb 48 vom SQL verwendet werden -> 16Gb übrig
NAV nimmt in deinem Fall weniger als 2Gb RAM --> rund gerechnet noch 14Gb übrig --> ~ 21% RAM frei - in deinem Screenshot sind aber wesentlich weniger frei - also verbraucht hier doch noch jemand anderes was, oder?
....ich nehme an, der Server fungiert als reiner SQL + NAV-Server und kein anderer macht dort was drauf?
13. Februar 2017 15:33
Passiert das auch wenn niemand angemeldet ist?
Verwendet ihr die Aufgabenwarteschlange?
Gruß Fiddi
13. Februar 2017 15:40
fiddi hat geschrieben:Verwendet ihr die Aufgabenwarteschlange?
oder ggf. die Änderungsprotokollierung?
13. Februar 2017 19:19
Ich habe heute einen Bug (min. 2015 bis 2017) ermittelt, der bei Nutzung des Variant-Datentyps als Parameter von Funktionen, im Laufe der Zeit den Speicherbedarf des NST bis zu einer Grenze hochtreibt, bis zu einem Punkt an dem dann eine ClientTerminatedException Auftritt und die Verbindung gekappt wird. Der Server ist dann zu nichts mehr zu gebrauchen (alles zäh), bis zum Neustart. Bei mir aufgefallen aufgrund eines Batch-Jobs über Dutzende von Tabellen.
Ich nehme an, dass das auch der Grund ist, warum im Regelbetrieb nach einigen Tagen der Speicher der Server volläuft. Garbage Collection hat darauf dann keine Auswirkung. Einzig Neustart hilft.
Auch wenn das aus der Beschreibung nur teilweise hervorgeht, äußert sich das Verhalten bei euch ähnlich?
14. Februar 2017 08:28
Guten Morgen zusammen,
der Server ist nur für Navision und Navision Anywhere zuständig.
Ja, wir verwenden die Aufgabenwarteschlange und Änderungsprotokollierung
In der Aufgabenwarteschlangeposten sind auch ziemliche viele mit Fehler, als Beschreibung NDAW WMS Posting, ist glaub ich von Anywhere.
Zu der Sache von SiverX, kann ich bis jetzt nicht bestätigen. Der Server läuft zwar voll und ist dann auch wieder träge, dann verlieren die Clients zu einem Zeitpunkt x die Verbindung und alle rufen an.
Der Zustand beruhigt sich dann wieder ein bisschen, aber der Server bleibt träge. Ich starte ihn dann meistens auch neu, so wie gestern Mittag. Auslastung ist z.Z. beim SQL 12 GB, also alles normal.
14. Februar 2017 09:58
Hallo,
dann stoppe doch mal die Aufgabenwarteschlangen, und schau mal, ob sich das System besser benimmt.
Es wäre auch eine gute Idee die Fehler in den Aufgabenwarteschlangen zu beseitigen.
Ein Problem könnte auch noch sein, wenn dort SQL-Server- DotNet- Clientkomponenten verwendet wurden, die haben auch die Angewohnheit zumindest in NAV 2015 den Speicher aufzufressen, und irgendwann den Server zu stoppen.
Gruß Fiddi
21. Juli 2017 12:13
Ich schlage mich mit Ähnlichem herum, bei uns ist u.a. anderem die Nutzung des Datetyps .NET das Problem.
Hier ein Workaround um das zu fixen.
https://blogs.msdn.microsoft.com/nav/2015/01/28/memory-usage-when-is-used-net-components/Allerdings hat es bei mir nur im Test geklappt, nicht mit unseren "echten" .NET Objekten (daher ist der Hinweis mit dem Datentyp Variant Wertvoll für mich um weiter zu suchen :) ).
Zusätzlich ist anzumerken, dass ich eine zweite CodeUnit nehmen musste zum Instanz erzeugen und dann ein Clear auf die Aufgerufene CU (dann klappt es mit dem Beispiel).
Powered by phpBB © phpBB Group.
phpBB Mobile / SEO by Artodia.