Leistungsproblem

Hallo,
wir testen gerade NAV17 bzw. haben ein Testupdate von NAV13R2 auf NAV17 (CU5) gemacht.
Es funktioniert zwar alles, aber es ist doch um einiges langsamer im RTC.

Wir haben ca. 30.000 Artikel und da merkt man schon den Unterschied beim Laden der Page.
Aber am schlimmsten ist es bei den Reports. z.B. im alten braucht das Ding ca. 7 Minuten und im neuen min. 15 Minuten.
Wir haben auch eine Codeunit die im alten System ca. 6 Minuten braucht und diese braucht im neuen ca. 7 Minuten.

Wobei das alte und neue System auf jeweils eigene Server (Windows 2012) installiert ist. Auch der Datenbank-Server ist neu und hat 48 GB Speicher.
Alles läuft in einer VMWare Umgebung und im neuen System ist aktuell nur ein User angemeldet.
Auch ist alles auf SSD-Platten installiert.

Wo sollte ich hier ansetzen um das Problem zu finden.

Besten Dank
stony

Hallo,

als erstes würde ich mal damit anfangen, dem SQL-Server optimale Arbeitsbedingungen zu schaffen, und die Statistiken der Datenbanken optimieren.
Desweiteren muss der SQL-Server "Warm" laufen. D.h. man sollte so einen Test nicht mit einer gerade gestarteten Maschine machen.
Ähnliches gilt für den Servicetier. Sind die Einstellungen identisch?
Nutzen die VMS identische Netzwerkadapter siehe z.B. hier.

Gruß Fiddi

Du solltest zunächst einmal herausfinden, wer der Flaschenhals ist. Ist es der SQL Server oder der NST Server oder das Netzwerk oder die VMWare?

Hi,
habe auf dem Tier-Server folgenden Fehler (und diese massenhaft bei Auswertung mit einem Query)

Server instance: DynamicsNAV100
Category: Sql
ClientSessionId: 53b9c989-aa6d-4480-a70e-08a11eaaa37a
ClientActivityId: 1a3c9d5d-1f92-48b2-91d4-b589fdab184b
ServerSessionUniqueId: 00000000-0000-0000-0000-000000000000
ServerActivityId: 00000000-0000-0000-0000-000000000000
EventTime: 12/14/2017 09:28:57
Message <ii>Threshold Trace Tag. Execution Time = 2522 milliseconds
Long Running SQL statement Task ID:3
SELECT TOP (1) "timestamp","Entry No_","Item No_","Posting Date","Entry Type","Source No_","Document No_","Description","Location Code","Quantity","Remaining Quantity","Invoiced Quantity","Applies-to Entry","Open","Global Dimension 1 Code","Global Dimension 2 Code","Positive","Source Type","Drop Shipment","Transaction Type","Transport Method","Country_Region Code","Entry_Exit Point","Document Date","External Document No_","Area","Transaction Specification","No_ Series","Document Type","Document Line No_","Order Type","Order No_","Order Line No_","Dimension Set ID","Assemble to Order","Job No_","Job Task No_","Job Purchase","Variant Code","Qty_ per Unit of Measure","Unit of Measure Code","Derived from Blanket Order","Cross-Reference No_","Originally Ordered No_","Originally Ordered Var_ Code","Out-of-Stock Substitution","Item Category Code","Nonstock","Purchasing Code","Product Group Code","Completely Invoiced","Last Invoice Date","Applied Entry to Adjust","Correction","Shipped Qty_ Not Returned","Prod_ Order Comp_ Line No_","Serial No_","Lot No_","Warranty Date","Expiration Date","Item Tracking","Return Reason Code","Item Sub Group Code","Wood Type Code","Quality Code","Oberflächentypencode","Profil Code","Fasencode","Bodentypencode","Prägungscode","Farbencode","Qualitätsuntergruppencode","Stärke (Verrechnung)","Breite (Verrechnung)","Länge (Verrechnung)","Einlagerungs Nr_","Bestell Nr_","Lieferschein Nr_","Positions Nr_","Job No_ 2","Bonus","Zeit","Sales Rrepresentative Code","Salespers__Purch_ Code","Hauptvertreter","Bemerkung","Schicht","Artikelbuchblatt BelegNr_","OF-Bearbeitungscode","Mittel-Unterlagecode","Deckschichtstärke","Lieferanten Nr_","Zertifikat","Zukauf","Kollektion","Farbe","Färbetechnik","Oberflächengruppe","Aktion","Weiterverarbeitungshinweis","Agenturcode","Produktdicke","Fertigungsauftragsnr_",DATALENGTH("Symbol"),"Commission Sign","Source Name","Sell-to_Buy-from No_","Sell-to_Buy-from Name","Our EU Country_Region Code" FROM "Live".dbo."Holzindustrie mbH$Item Ledger Entry" WITH(READUNCOMMITTED) WHERE ("Document No_"=@0 AND "Lot No_"=@1) ORDER BY "Entry No_" ASC OPTION(OPTIMIZE FOR UNKNOWN)</ii>
ProcessId: 6996
Tag: 000007L
ThreadId: 13
CounterInformation:


Bin aktuell der einziger Benutzer vom System.

Wo sollte ich hier weiter suchen.

Danke und lg
stony

Du hast keine ausreichende Berechtigung, um die Dateianhänge dieses Beitrags anzusehen.

Hallo,

ist kein Schlüssel für die Chargennummern ("Lot No.") in den Artikelposten aktiviert?

Gruß Fiddi

Kannst du während du mit dem User die Statments sendest mal auf dem SQL Server den Profiler im "Tuning" Modus starten und einen Filter mit >10 Millisekunden anwenden ?

1. SQL Server
Es gibt dort 2 Szenarios:
Viele kleine Abfragen oder wenige große. Sieh dir auch die teuersten Abfragen auf dem SQL Server an.

Falls du entdeckst das Flowfields langsam berechnet werden prüfe mal "Max. Grad an Parallelität" das sollte keinesfalls = 1 sein.
Die Faustformel ist etwa die hälfte der Prozessoren/Kerne vom Server.(Persönlich lasse ich es auf 0 aber das hängt von der Wichtigkeit und Ausstattung des Systems ab.)

2. Service Tier
Wenn du nichts beim SQL Server findest prüfe das Service Tier.
Ram Benutzung, zuwachs und Auslastung vom Prozessor / Netzwerk.

3.Wenn dort nichts ist, evtl. Netzwerk ?

Und zum Schluss evtl. die CUs durchsehen. Ich hatte zuletzt irgendwo gelesen das in einem CU ein Performance Fix drin war aber ich glaube mit CU5 bist du da schon weiter.

Gruss Nody

Hallo,

ich gebe dir einen Tip: wende dich an stryk. Es dauert ggf. eine kleine Weile, bis du einen Termin bekommst, jedoch bekommst du unglaublich belastbare Informationen.

...Falls du entdeckst das Flowfields langsam berechnet werden prüfe mal "Max. Grad an Parallelität" das sollte keinesfalls = 1 sein.
Die Faustformel ist etwa die hälfte der Prozessoren/Kerne vom Server.(Persönlich lasse ich es auf 0 aber das hängt von der Wichtigkeit und Ausstattung des Systems ab.)

Für NAV sollte da nicht 0 stehen sondern eher 2.