NAV 2015 Performance Probleme

Hallo zusammen,

mein Name ist Manuel und ich arbeite als IT-Systemadministrator in einem mittelständigen Unternehmen.

Wir haben vor kurzem ein Upgrade durchgeführt von Navision 2009R2 auf Navision 2015.
Dieses Upgrade wurde durch unseren Dienstleister durchgeführt. Dieser übernimmt bei diesem Projekt die Projektführung und alle Programmierarbeiten.

Die Infrastruktur wurde durch uns gestellt und sieht wie folgt aus:

3 HP ESXi Server v. 6.0
Storage ist ein Raid 10 Verbund mit 16K rpm 300GB Festplatten
Alle Server sind visualisiert.
Alle virtuellen Server sind mit einer 10Gbit/s Netzwerk Verbindung angebunden.

Zugeteilte Hardware Ressource in VMware:

SQL Server
2 virtuelle CPUs @2,60Ghz
16384MB RAM
30GB C:\ OS
500GB D:\ SQL Datenbank
150GB E:\ SQL Logs

NST1
2 virtuelle CPUs @2,60Ghz
8192MB RAM
40GB C:\ OS & Navision Middle Tier Service

NST2
2 virtuelle CPUs @2,60Ghz
8192MB RAM
40GB C:\ OS & Navision Middle Tier Service

NST3
4 virtuelle CPUs @2,60Ghz
4096MB RAM
40GB C:\ OS & Navision Middle Tier Service

NST4 (NAS Dienste)
2 virtuelle CPUs @2,60Ghz
8192MB RAM
30GB C:\ OS & Navision Middle Tier Service

NST5 (Test NST)
2 virtuelle CPUs @2,60Ghz
8192MB RAM
30GB C:\ OS & Navision Middle Tier Service

Auf NST1,2 und 3 läuft ein Network Load Balancer, um die eingehenden User Sessions zu verteilen.
Alle NSTs besitzen 2 IP-Adressen, eine lokale und eine NLB Adresse über die die User Sessions eingehen.

Unsere Navision 2009R2 ist sehr stark angepasst auf unsere Bedürfnisse.

Die Datenbank wurde vor ca. 2 Wochen konvertiert und wird jetzt als Produktiv Datenbank genutzt.

Leider haben wir jedoch seit dem ersten Tag an erhebliche Performance Probleme. Diese kommen und gehen.
Am Anfang war immer nur einer der NSTs gut von der Performance. Mittlerweile hatten wir Tage, an denen alle NSTs sehr große Probleme hatten.

Das Problem gestaltet sich wie folgt:
Beim Klicken durch die Artikel/Debitoren/Kreditor oder sonstiges Karten gibt es immer wieder Lags.
Ich klicke z.B. 3-5 mal auf "nächster" und nach ca. 30-40 sec. hat der Client dann den 3. bzw. 5. Artikel erreicht.

Teilweise ist es so schlimm, dass der Client einfriert und für mehrere Minuten keine Rückmeldung mehr gibt.

Wir haben bereits mehrere Dienstleister und Microsoft befragt, aber haben bis jetzt keine Lösung gefunden.

Nach einem Neustart wird es kurzzeitig besser, aber nicht lange, dann kommt das Problem wieder zurück.

Auf dem SQL Server waren keine größeren Abfragen festzustellen. Es wurden keine blockierenden Abfragen gefunden. Die Hardware ist größtenteils nicht mal zu 20% ausgelastet.

Nach einer frischen Installation eines NST konnte ich feststellen, dass die Performance wirklich extrem gut ist. Leider ist dies auch nur von kurzer Dauer, dann kommen die Lags wieder.

Wir wissen gerade absolut nicht weiter. Hat jemand bereits ähnliche Erfahrungen gemacht?

VG
Manuel

Hallo Manuel,

zunächst herzlich willkommen im Forum.

Zunächst ein paar Fragen:
1. wieviele NAV- Benutzer habt Ihr?
2. wie groß ist eure NAV- Datenbank (Datenteil !!)
3. welches NAV 2015 Build setzt ihr ein?

Gruß Fiddi

Das Problem gestaltet sich wie folgt:
Beim Klicken durch die Artikel/Debitoren/Kreditor oder sonstiges Karten gibt es immer wieder Lags.
Ich klicke z.B. 3-5 mal auf "nächster" und nach ca. 30-40 sec. hat der Client dann den 3. bzw. 5. Artikel erreicht.
Teilweise ist es so schlimm, dass der Client einfriert und für mehrere Minuten keine Rückmeldung mehr gibt.

Kleiner Tip, die Stammdaten-Karten-Pages enthalten ja viele FlowFields (auch in den Fact Boxes). Werf die doch mal testweise raus, ob's dann schneler geht. In der Art hatten wir schon Probleme.

(Allerdings würde ich im Windows Client auch nicht unbedingt durch die Karten blättern sondern durch die Übersicht/List-Pages.)

Hallo Manuel,

ich gehe mal davon aus dass die 2009er Version richtig lief, daher für den Einstieg ;)

-welche CPUs sind in den HP Servern?
-Sind noch andere Server die nicht für NAV arbeiten auf dem ESX? z.B. Fileserver, AD Server..
-sind eigene LUNS für die Partitionen definierert oder ist das eine große LUN für alle Server


Du kannst mittels perfmon auf den Servern (DB + NST) wichtige Indikatoren mitprotokollieren, u.a. CPU Auslastung, Seitenfehler, Netzwerk Wartezeit, Datenträger Wartezeit
Da siehst du dann schon ob es Hardwareseitige Probleme gibt.

Eine weitere wichtige Frage:
Wird die SQL Datenbank RICHTIG gewartet? Sprich werden alle Indizes und Statistiken regelmäßig neu aufgebaut.
Sind dem SQL Server die notwendigen Ressourcen zugeteilt.
Welche SQL Server Version?

mfg

Zumindest auf der Artikelkarte ist das Feld "Einstandspreis ist auf Sachkonten gebucht" ein absoluter Performancekiller. Es reicht übrigens auch nicht, die Felder auf Visible = No zu stellen. Die Felder müssen richtig aus der Page gelöscht werden.

Hallo,

wir hatten kurz nach dem Update auf NAV 2015 so ziemlich dieselben Probleme. Bei uns war es nur das Blättern in der Artikelkarte, das nach paar
Wochen unerträglich langsam wurde.

Schuld waren 1 oder 2 Felder im Artikelstamm. Natürlich Flowfields. Bestimmte Tabellen, die zur Berechnung der Flowfields benötigt werden, waren
nicht optimal indiziert. Diese werden seitdem explizit wöchentlich indiziert.

Ich würde vorschlagen eine kastrierte Artikelkarte zu erstellen und schauen, ob diese zu den Zeitpunkten, wo es Performanz-Probleme gibt,
im Gegensatz zur Standard-Artikelkarte besser läuft. Wenn diese problemlos läuft, dann hängt es an einzelnen Flowfields.

Andi

Häufig sind die Performance- Probleme auch durch Optimierung der FlowField- Abfragen zu verbessern.

Je nach Arbeitsweise (mit Sammelrechnung, bzw. viel Text in den Belegen) wird z.B. die Übersicht der gebuchten Rechnungen im NAV extrem langsam (das öffnen der Übersicht dauert 1 Minute)

Hier hilft z.B. die Optimierung das man die Amount- Flowfields im Rechnungskopf um die Filterung auf (Type <>Type::"")und ('"No." <>'''). Danach ist alles wieder normal schnell.

Zumindest auf der Artikelkarte ist das Feld "Einstandspreis ist auf Sachkonten gebucht" ein absoluter Performancekiller. Es reicht übrigens auch nicht, die Felder auf Visible = No zu stellen. Die Felder müssen richtig aus der Page gelöscht werden.

Das kann es aber eigentlich nur dann sein, wenn die Lagerregulierung nie auf Sachkonten gebucht wird.

Gruß Fiddi

Zumindest auf der Artikelkarte ist das Feld "Einstandspreis ist auf Sachkonten gebucht" ein absoluter Performancekiller. […]

Das kann es aber eigentlich nur dann sein, wenn die Lagerregulierung nie auf Sachkonten gebucht wird.

Die automatische Lagerbuchung ist ja nur optional. Dass besonders die Flowfields, die nach nicht-existierenden Datensätzen suchen, nach einem Upgrade von einer NAV 2009 extreme Performanceeinbrüche verursachen können, habe ich auch schon von anderen großen Installationen gehört.

Zu der vielen Änderungen bei der Flowfieldtechnologie ab NAV 2013 (SmartSQL, MARS statt Datensatzcursor usw. ) ist hier auch ein Artikel:
Microsoft Dynamics NAV: Faster than ever

Dass besonders die Flowfields, die nach nicht-existierenden Datensätzen suchen, nach einem Upgrade von einer NAV 2009 extreme Performanceeinbrüche verursachen können

In diesem Fall sucht er aber wahrscheinlich nicht nach einem nicht existierenden Datensatz, sondern in sehr vielen Datensätzen (für jeden Wertposten einen). Da in diese Tabelle immer ein Datensatz geschrieben wird, bis die Daten verbucht sind.

Gruß Fiddi

Hallo,

ich habe auch zwei Hinweise:
1.) Einstellung an der ServiceTier: MetaData Provider Cache Size - Dieser Wert steht standardmäßig auf 150. Das bedeutet es befindet sich maximal 150 Objekte im Cache. Das Szenario ist einfach: Eine Service Tier hat maximal 150 Objekte im Cache und wirft alte Objekte wieder aus dem Cache. Meiner Meinung nach sollte der Wert auf 5000 gesetzt werden, vor allem wenn mit vielen unterschiedlichen Modulen gearbeitet wird
2.) Wenn man die Performanceprobleme direkt an Beispielen nachvollziehen kann, dann sollte man eine eigene Service Tier erstellen und dort mit nur einem Benutzer das Problem reproduzieren. Mit dem SQL Server (SQL Provider) kann man dann die fehlenden Indexe ermitteln oder auch sehen welche Abfragen dem SQL Server Schwierigkeiten bereiten. Es kann auch sein, dass der SQL Server mit der Abfrage keine Last verursacht, aber sehr lange braucht um die Daten abzurufen.

Die Hinweise der Vorposter sollte man auch anschauen. Zu viele individuelle Flowfields oder vor allem FlowFields ohne richtige Indexierung lösen solche Probleme natürlich auch aus.

LG
Robert

Hallo zusammen,

ich hatte Manuel (erfolglos) schon direkt angeschrieben, da wir ein ähnliches, wenn nicht das gleiche Problem in einer unserer Umgebungen haben und ich einen Erfahrungs- oder Lösungsaustausch vorantreiben wollte.

Zu dem Zeitpunkt hatten wir allerdings noch keine Ideen, was sich mittlerweile aber geändert hat.
Unser voraussichtliches Problem, das wird sich morgen Vormittag dann hoffentlich beweisen, liegt offenbar in einem VMware Bug begründet: After upgrading a virtual machine to hardware version 11 network dependent workloads experience performance degradation (2129176).
Der ursprüngliche Thread dazu ist dieser: vmxnet3 adapter on windows server 2012 with MSSQL server bottleneck problem.

Die Kurzfassung in Englisch:

•You notice a performance degradation for some client/servers workloads
•Packets have up to a 0.5 second delay over the expected arrival in the application

This issue is observed under the below conditions:

◦The guest operating system is Windows Server 2012, Windows 8 or later
◦The virtual machine is on hardware version 11/ ESXi 6.0 compatibility
◦The virtual NIC is vmxnet3 and the driver version is 1.6.6.0
◦The Receive Side Coalescing (RSC) feature is enabled globally and on the vmxnet3 adapter
◦This issue is more prevalent when:
1.Running Microsoft SQL/TDS based workloads
2.When using Jumbo Frames

Ein weiterer Workaround scheint zu sein, den E1000E anstatt des vmxnext3-Treibers zu nutzen (der aber einen höheren Ressourcen-Overhead hat). Bei uns kommt noch dazu, dass dieses Verhalten offensichtlich noch verstärkt wird, wenn eine Version 11 Cluster VM mit einer Version 10 VM kommuniziert.

Wir werden, anstatt der vorgeschlagenen Workarounds, heute Abend einen Downgrade auf V10 machen und dann morgen prüfen.

Ich wollte das aber schon mal hier zur Verfügung stellen, falls jemand ein ähnliches Problem hat.

Hi Namensvetter ,

ich weiß, der letzte Eintrag ist schon etwas her, aber seid ihr in der Richtung weitergekommen?
Ist für mich ein interessantes Thema, da wir ein ähnliches Problem bei einem Kunden haben.

Viele Grüße
Carsten (No. 2)

Hallo Carsten,

Ja, genau wie beschrieben konnten wir das Problem durch ein VMware downgrade lösen.