Offen Immer wieder WaWi Absturz, Deadlock

[Bird-Box]

Ich bin noch auf 1.5.47.4 und hatte nun länger keine deadlocks mehr.

 

[deliman]

Wir haben 1.5.49.1 mit der Hoffnung, das es besser wird aber zumindest an meinem Arbeitsplatz (bin im Adminstatus angemeldet) habe ich seit rund 3-4 Wochen ständig Abstürze die nicht erklärbar sind, noch nachgestellt werden können. Meistens wenn ich gerade gar nicht in der Wawi arbeite. Der Support kann auch nicht wirklich helfen, da die gesendeten Fehlerprotokolle zu groß/umfangreich sind und ich eben auch nicht erkenne, warum die Wawi bei "Inaktivität" einfach abstürzt. Vorher waren da eher die Mitarbeiterinnen betroffen...

 

[Gambionike]

Wir haben 1.5.49.1 mit der Hoffnung, das es besser wird aber zumindest an meinem Arbeitsplatz (bin im Adminstatus angemeldet) habe ich seit rund 3-4 Wochen ständig Abstürze die nicht erklärbar sind, noch nachgestellt werden können. Meistens wenn ich gerade gar nicht in der Wawi arbeite. Der Support kann auch nicht wirklich helfen, da die gesendeten Fehlerprotokolle zu groß/umfangreich sind und ich eben auch nicht erkenne, warum die Wawi bei "Inaktivität" einfach abstürzt. Vorher waren da eher die Mitarbeiterinnen betroffen...

Du hast Recht, die Fehler-Reporte sind so lang, dass unser Mailprogramm die noch nicht einmal an JTL senden kann. Da kommt es dann auch zur Fehlermeldung. Hoffentlich nimmt sich dort mal jemand dieses Problems an.

 

[musikfast]

Ich hatte aktuell keine Abbrüche mehr gehabt, bzw. wurden kurz nach Senden des Fehlerprotokolls behoben.
Ich habe noch die Version 1.5.49.2
Das aktuelle Update 1.5.50 ist zwar sehr interessant, aber man hat schon so seine persönliche Schwierigkeiten, solch gewaltige Updates zu installieren. Welche Probleme werden dann auftauchen?

 

[Stephan K.]

In der 1.5.49.2 kommen die auch noch vor. Gefühlt sein ein paar Updates ist das so.

Manchmal ganz unverhofft, indem man einfach nur irgendeine Transaktion anklickt oder sonstwas.
Und sonst passiert da gar nix. Keine Tools, nada. Das ist JTL-intern. Wahrscheinlich mit dem Worker oder sonstwas.

 

[lx777__]

Selbes Problem hier

Wir hoffen auf eine Lösung ....

 

[schnitzel112]

Dito. Auch in der 1.5.50.2
Habe Angst vor Weihnachten

 

[TobiasC]

Hi,

wir haben leider auch immer wieder Probleme mit Deadlocks. Das ganze ist auch ab einer gewissen Wawi Version aufgetreten.

Vom Support gab es ein paar Hinweise auf die Konfiguration des SQL Servers, jedoch auch eine, die zwar die Deadlock Problematik löst, aber zu anderen Problemen führen kann. (geht um das Snapshot Isolation Level). Da es viel um Bestandsbuchungen bei den Deadlocks geht, haben wir das mit dem Snapshot Isolation Level wieder auf den Urpsrungszustand gesetzt.

Ebenfalls haben wir auf Anraten des Supports die Paralellität stark runtergeschraubt, was zu Verbesserungen geführt hat.

Besonders betroffen ist der Mobilserver von der Deadlockthematik. Die WMS Clients auf den Tablets laufen ganz regelmäßig in die Deadlock-Situationen. Durch das Feintunen der Paralelität hat sich das aber auch gebessert.... ganz verschwunden ist es jedoch nicht.

 

[HMS_IT]

Besonders betroffen ist der Mobilserver von der Deadlockthematik. Die WMS Clients auf den Tablets laufen ganz regelmäßig in die Deadlock-Situationen. Durch das Feintunen der Paralelität hat sich das aber auch gebessert.... ganz verschwunden ist es jedoch nicht.

Das muss nichtmal unbedingt etwas mit der Datenbank zu tun haben, sondern kann ein Netzwerk (WLAN)-Problem sein. Wir hatten am Anfang ein Fritzbox-Mesh-Netzwerk aus 3 Repeatern, die Probleme wurden mit steigender Netzwerklast bei den Tablets immer schlimmer.

Haben dann ein paar Wanddurchbrüche gebohrt und LAN-Kabel gezogen, 2 WLAN-Accesspoints von Ubiquiti per PoE an den Switch und seitdem ist Ruhe. WMSmobile rennt gefühlt doppelt so schnell auf dem Tablet und ich merke nicht mal mehr, wenn ich die Halle (anderer AP) wechsel.

Also schau auch mal in diese Richtung.

 

[TobiasC]

Hi,

danke für deinen Hinweis, aber das mag ich ausschließen. Wir haben das am Anfang auch gedacht.... und ein komplett neues WLAN Netz mit 14 APs von Ubiquiti aufgebaut. Die 3 Switches, die wir bei uns benutzen sind alle mit 10G verbunden und die APs sind da natürlich auch alle per LAN Kabel angeschlossen.
Nachdem die WLAN Optimierungen keinen Erfolg gebracht haben, haben wir neben unserem EPYC Server (von DELL, welcher als Anwendungsserver und auch SQL bis dahin funguerte) noch einen weiteren 2x XEON Gold (je 8 Core Prozessore mit hoher Taktrate), 10er RAID mit SAS SSDs und 196 GB RAM geholt (auch von DELL), welcher als dedizierter SQL Server fungiert.... hat leider auch nicht das Problem komplett abgestellt. Da ging es aber vorrangig auch nicht um Deadlocks.

Dann hatte sich JTL das damals angesehen und wir konnten das zwischenzeitlich deutlich verbessern. Abe einem gewissen Update hat das dann aber mit den Deadlocks begonnen. Davor waren nur einige Queries EXTREM langsam. Lag wohl an einem falschen Query Ablaufplan, der dann in einer JTL Version behoben worden ist.

Das mit den Deadlocks nervt total und es betrifft ja nicht nur die Mobilclients, sondern auch immer wieder die Arbeitsplätze, wodurch auch mal eine Rechnungskorrektur oder was anderes zerschossen wird und wir das dann in der DB "reparieren" müssen. Bei den Mobilclients verlieren die Mitarbeiter im Lager dann immer die Verbindung und müssen sich erneut einloggen. An stressigen Tagen kann das wirklich den Ablauf stören.

 

[SebastianB]

Hi,

vermutlich wurde Dir vom Support Read Commited Snapshot Isolation empfohlen - dazu würde ich in dem Fall dann auch raten es zu aktivieren. Ich wüsste jetzt nicht, zu welchen Problemen das führen sollte - wir haben das bei vielen Kunden aktiv.
Sonst schreibe mir mal eine PN, dann schauen wir am Montag nochmal drauf.

 

[TobiasC]

Hi Sebastian,

danke für deine Rückmeldung. Ich habe das mit den Read Commited Snapshot Isolation jetzt wieder aktiviert. Hatte dazu seit gestern und heute viel gelesen und teilweise wird in dem Kontext eben von abweichenden Ergebnissen bei Queries berichtet, je nachdem wie der Code aufgebaut ist.

z.B. https://www.brentozar.com/archive/2014/12/read-committed-snapshot-isolation-writers-block-rcsi/

Beim Support hörte es sich nicht so an, als wäre das bei vielen Kunden bereits am laufen, sondern eher eine besondere Sonderlösung. Beruhigt mich jetzt, wenn es schon bei einigen läuft und die Kunden dann ja scheinbar keine Probleme haben. Von der Grundidee bietet Read Commited Snapshot Isolation einige Vorteile und auch Read Commit ohne Snapshot Isolation hat ja gewisse Probleme, die mir gar nicht bewusst waren.

 

[TobiasC]

Hi,

unsere Deadlocks in Bezug auf den Mobilserver und die WMS Mobilclients sind seit der Umstellung auf Read Commited Snapshot Isolation definitiv verschwunden. Somit vielen Dank für die Hilfestellung. Es gab seit der Umstellung einen anderen Deadlock an einem Packplatz. Diese Art von Deadlock taucht bei uns auch immer wieder mal sporadisch auf und es wird dann keine Rechnung für den Kunden erstellt. Wir haben diesbezüglich aber nochmal ein weiteres Ticket aufgemacht.

Gruß
Tobias

 

[omni-handel]

gibt es schon Lösungen ?

jtl prozess id 77 absturz -
JTL Version 1.5.51.0

 

[omni-handel]

Hi,
habe jetzt alles versucht - auch JTL aus dem Netzwerk genommen - Zugriffe per Firewall gesperrt
- auch als lokale Maschine Abstürze nach unbestimmter Zeit
- Nach Neustart der JTL funktioniert es wieder einwandfrei ...
Gruß

 

[omni-handel]

Wenn man die JTL nach Abarbeitung von Bestellungen immer beendet
und erst dann wieder öffnet, wenn man wieder bearbeiten will - dann gibt es keine Fehlermeldung

liegt wohl am Worker ?

.... EGAL dann schließe ich Sie halt immer wieder und lasse sie nicht den ganzen Tag laufen