Neu SQL Server Optimierung - Wawi/WMS SEHR langsam

[Shopworker.de]

z.B. per Windows-Aufgabenplanung und ein Script könntest du das zeitgesteuert aufrufen ...

 

[mvh]

Moin.
Ich frage mal auch. Wir fahren jeden Tag den Script, ABER: s.Bild


danach geht es zwar sehr schnell zu 50%-30% und der Rest zu 2%-0%

ABER die ersten 50 Zeilen, wurden diese Indizes vergessen ?

Mit freundlichen Grüßen, Ihr MVH-Team

 

[Dom@H1]

Hi,

wir haben große Performance-Probleme mit unserem SQL Server. Wir hatten bis vor kurzem einen Dell PowerEdge R7515 mit einem AMD EPYC 7302P 3GHz, 16C/32T, 128M Cache (155W) DDR4-3200. 128 GB Ram, SAS-SSD Raid auf dem 5 VMs liefern (Anwendungsserver für den JTL Worker sowie den Mobile Server, Backupserver, Domänencontroller, VMware und SQL Server)

Der SQL-Server (SQL 2019 - Standard) hatte hierbei 8 Cores und 48 GB RAM zugewiesen. Wir waren mit der Performance grundsätzlich zufrieden, jedoch gab es immer massive Einbrüche an Montagen. Ab ca. 1000+ Aufträgen kommt es hier zu großen Performanceeinbrüchen.

Bei uns arbeiten ca. 50 Personen (bald 60) und wir setzen komplett auf die Wawi und WMS. Wir haben ca. 65 Rechner (mit Wawi + WMS) über unsere Fläche verteilt (Bürorechner, Lagerrechner, Packtische, Notebooks.) Die Clients sind natürlich nicht alle gleichzeitig an. Zusätzlich haben wir ~25 Mobilclients (Tablets und andere Mobilgeräte für WMS).

Durch die Unzufriedenheit mit der Performance haben wir uns jetzt einen dedizierten Server allein für den SQL Server zugelegt. Es ist ein Dell PowerEdge R740 Rack-Server mit 2x Xeon Gold 6250 (je 8 Cores + Hyperthreading) und 196 GB Ram geworden. Dazu ein Raid 10 mit 6x 800 GB mixed use SAS SSDs. Auf dem AMD Epyc läuft jetzt der AW und die anderen VMs.
Der Server läuft auch wieder virtualisiert mit VMWare (16 logische CPUs und 128 GB RAM). RAM wird vom SQL Server nur ~20 GB genutzt, der Rest steht frei zur Verfügung und wird vom SQL nicht abgerufen (obwohl er ~100 GB konfiguriert hat). I/O Zugriffe halten sich extrem in Grenzen. Das 10er Raid langweilt sich quasi.

Der Anwendungsserver ist mit dem SQL Server mit 10 GbE verbunden.

Mit dem neuen Server ist das System über die Woche sehr viel schneller (quasi instant Wechsel der Reiter und auch innerhalb von max. 1 Sek die Anzeige von den Artikelpos. unter Verkauf), jedoch an Montagen wieder sehr langsam. Der Wechsel der Reiter in der Wawi ist langsam und unter Verkauf => Aufträge dauert es gefühlte Ewigkeiten bis die Artikelpositionen angezeigt werden. Der Server langweilt sich zu diesen Zeiten mit ca. 3-10% CPU Auslastung und hat dabei noch 100 GB freien Arbeitsspeicher für den SQL Server.
Das Problem scheint größer zu werden, wenn mehr Clients auf die Wawi zugreifen. Wenn nur ein Client per Terminalserver ( RDP) auf die Wawi zugreift, ist es auch mit den Auftragsmengen von Montagen etwas erträglicher, aber auch nicht mehr schnell.
Beim Erstellen der Picklisten sieht man den SQL dann schon etwas arbeiten. Da geht er auf ~50% CPU Auslastung, erstellt die Picklisten dabei aber NICHT in Lichtgeschwindigkeit.

Wir sind jetzt ziemlich ratlos und es macht so langsam keinen Spaß mehr, denn die Auftragsmengen von Montagen sind ggf. schon in ein paar Monaten die Auftragsmengen von Dienstag - Freitag und damit wäre dann die Wawi/WMS jeden Tag extrem lahm. Das ist einfach nur noch ätzend.

Bei Cost Threshold for Parallelism haben wir aktuell den Wert 50. Höhere Werte führten beim AMD Rechner zu deutlichen Verzögerungen, kleinere Werte waren auch kein Performanceboost.

Bei Maxdop hatten wir auf dem Epyc 3 und haben jetzt nur 5 eingestellt, da uns der JTL Support mitgeteilt hat, dass bei vielen Clients usw. ein geringerer Maxdop deutlich besser wäre und sie sogar bei großen Kunden mit Maxdop 1 deutlich besser von der JTL Performance fahren würden. Ein kurzer Versuch mit Maxdop 7 (Anzahl Cores / 2 - 1) war etwas langsamer von der gefühlten Geschwindigkeit als die 5. Maxdop 1 war leider auch kein Zugewinn. Bei dem Wechsel der Reiter macht das alles aber wenig Unterschied von der Schnelligkeit.
Aktuell sind 8 Tempdb files angelegt.

Die Waitstats sehen an sich sehr unproblematisch aus (soweit wir das als Laien beurteilen können). Deuten aber unserer Meinung nach nicht auf ein Hardwareproblem hin?!
(Siehe Screenshots)

Wie sind eure Server eingestellt? An welchen Schrauben könnten wir bei uns noch drehen, damit es zügiger wird. Habt ihr mit ähnlichen Problemen zu kämpfen?

Die SQL Datenbank hat ca. 20 GB und wir haben viele Artikel mit Variationskombinationen (insgesamt haben wir 14.000 Artikel und davon ca. 60% Varkombis => ganz grob geschätzt)

Über Rückmeldungen würde ich mich sehr freuen.

Viele Grüße
Tobias

Hallo Tobias,

Jetzt bin ich auf die Nachher Werte gespannt. Im ersten Post hast du ja die Wait Stats hinzugefügt.
Wie sehen eure Wait Stats jetzt aus und wie häufig lasst ihr was genau laufen?
Ich fand die Standart einstellungen von Ola Hellengren nicht immer ideal sind.
Bei mir kam das Problem auf das die Log Daten groß wurden, mehr Speicherplatz nötig wurde und die Sicherung der Logs nun mehr Zeit benötigt hat.

Hier meine Einstellungen für MS SQL Server 2017 und 2019 Server auf denen JTL läuft:

• FragmentationLevel1 = 50%
• FragmentationLevel2 = 80%
• FragmentationMedium = ‘INDEX_REORGANIZE,INDEX_REBUILD_ONLINE ,INDEX_REBUILD_OFFLINE ’
• FragmentationHigh = ‘INDEX_REBUILD_ONLINE ,INDEX_REBUILD_OFFLINE ’

Index_Reorganize lasse ich auf den Servern zu unterschiedlichen Zeiten laufen. Kommt auf die Arbeitszeiten und Datenbankgröße an.

Gruß,
Dominik