Neu Geschwindkeit: Artikelanlage mit Varianten

[RuloR]

Guten Morgen,
seit geraumer zeit ist der Speichervorgang eines neuen Artikels mit Varianten extrem lange.

Der Kollege legt einen neuen Artikel an, gibt diesem die Variation Größe und dazu einen Verlauf von z.b XS-2XL.
Jetzt noch der klick auf "Nicht vorhandenen Kombinationen erstellen" und Speichern.

Jetzt läuft die Uhr- hier gehen locker mal 5 Minuten ins Land.

Andere Dinge wie z.b Lagerbestand buchen, Artikelbeschreibung ändern oder Lieferadressen in Aufträgen ändern geht ohne probleme. Es ist lediglich die Artikelanlage die extrem viel Zeit benötigt.

Mit dem Programm "debugview" konnte ih sehen das jeder INSERT in die Datenbank bis zu 4 Sekunden dauern. Was definitiv zu viel ist.

Im System sind ca 15k Artikel + dazugehörige Varianten.
DB Server Lokal im Netzwerk.
DB liegt auf SSD.

Ein Ticket hat nicht viel gebracht. Hier wurde nur gesagt das bereits sowieso an der Artikelanlage geschraubt wird.
Eine Installation auf 1.4.30 hat keine Besserung bewirkt.

 

[Pinkman]

Guten Morgen,
ich gehe mal davon aus, dass die Artikel auch Merkmale haben, richtig?

Gruß
Michael

 

[RuloR]

Richtig, Merkmale, Beschreibung, Preise,
Aber selbst wenn der Artikel ziemlich Nackt ist und kaum Daten angegeben sind ist die Ladezeit relativ lange.

 

[Pinkman]

Versuch mal testweise einen Artikel ohne Merkmale...

 

[RuloR]

ohne Merkmale genauso langsam, auffällig ist das die CPU Auslastung steil nach oben geht beim Server.

 

[Pinkman]

okay, das ist dann merkwürdig. Bei uns geht das sauschnell und wir nutzen die 1.4.29
Es gibt nur bei gleichzeitiger Nutzung von Merkmalen ein Problem. Wir haben über 2,2 Mio Artikel, nur einen Miniserver mit wenig RAM und kein SSD.

 

[ksw]

Hab mich weiter auf fehlersuche gemacht.
Mir ist nicht ganz klar wieso die ebay Attributte neu geschrieben werden müssen bei einem neuen Artikel.

Ich werde weiter auf fehlersuche gehen.

 

[Pinkman]

Hallo ksw,
genau das ist der Fehler, Du brauchst nicht weiter zu suchen
Wird in einer der nächsten Versionen behoben. Wir haben das auch deaktiviert

 

[RuloR]

Hm ok. Woher weißt du das es behoben wird ?!

 

[Pinkman]

Weil ich den Fehler schon vor etwas über einer Woche zusammen mit dem JTL Support festgestellt habe und einen guten Kontakt dazu habe.

 

[ksw]

Ok dann schonmal Danke bis hierher, werden den Trigger deaktivieren und das ganze mal beobachten.

 

[Mike.K]

Hallo Leute,
wir müssen Euch darauf hinweisen das wir dringend davon abraten Trigger in der Datenbank eigenmächtig zu deaktivieren oder sonstige Eingriffe in der Datenbank vorzunehmen.
Fehler welche durch das deaktivieren der Trigger hervorgerufen werden können, zerstören im schlimmsten Fall eure Datenbanken.
Wir hatten nun bereits mehrere Kunden welche anfingen in der Datenbank Trigger zu deaktivieren und nun teilweise mit massiven Problemen in der WAWI zu kämpfen haben.

 

[ksw]

Uns ist schon bewusst das dies nicht gut gehen kann.
Jedoch ist es ebenso unbefriedigend wenn man für 1 Artikel 15min und länger benötigt (nur für den Speichern Vorgang). In dieser Zeit explodiert die CPU Auslastung beim Server und der Arbeitsablauf ist massiv gestört.
Wir können jetzt nicht auf die Anlage neuer Artikel verzichten bis in Tagen oder Wochen das ganze gelöst ist.

 

[Freakbiz]

Eiegntlich war für morgen das 1.3 auf 1.4er Update geplant.

@Mike.K
kann dieses Problem von JTL per Fernwartung in meiner Datenbank gelöst werden, sofern es nach einem Update auf die 1.4 entstehen sollte? Oder gibt es dazu zeitnah eine neue 1.4er Version, die diesen Fehler behebt?

 

[hula1499]

@Freakbiz

Hier wurde bereits nach der DB Lösung - ohne deaktivieren - gefragt:
https://forum.jtl-software.de/threads/wawi-nach-update-auf-1-4-29-1-langsam.120646/post-659176

Leider gabs hier noch keine Info.

 

[Star Piercing]

Die ersten 2-3 Tage lief die Wawi 1.4.31.0 auch bei mir rasend schnell (Deutlich schneller als die alte), aber seit gestern schläft mir echt das gesicht ein. :-|
Ich habe ein Datenbank hosting (nicht bei JTL), soll ich da bei JTL ein Ticket machen oder bei meinem Hoster?

 

[rudlerrocks]

Wir konnten noch ein ganz anderes Problem mit den Varianten ausfindig machen!

Es ist auf einem AMD Ryzen 2950X nicht möglich, überhaupt Variatinsattribute zu vererben. Ein sehr Server Affiner Bekannter von mir, konnte das Problem aber doch sehr eingrenzen. Das Multithreading für JTL scheint extrem fehlerhaft zu sein. Sobald man über einen Numa Core hinaus geht, schmier die Software vollständig ab. Bei einem 32 Kerne ist also ab Core 17 Totalabsturz.

Wir konnten mit den Windows Boardmitteln JTL soweit wieder zum Laufen bekommen. Erstellt euch ein Batch Script, mit folgendem Inhalt: Alles über einem logischen Prozessor führ bei uns zum Absturz. Die software hängt. Mit einem Core haben wir zwar keine grafischen Ladebalken mehr, aber die Software ist schneller den je, alles läuft wie es soll.

Gerne könnt ihr auch noch mit anderen Werten arbeiten, die Microsoft Liste findet ihr hier:
https://blogs.msdn.microsoft.com/sa...ow-to-launch-a-process-with-cpu-affinity-set/

cd "C:\Program Files (x86)\JTL-Software\"
start /affinity 1 JTL-Wawi.exe
exit

Hier muss Seitens JTL der Fehler gefunden werden. Auch wenn ein Core ausreicht zum Arbeiten, wäre natürlich ein Multithread schon schicker.

Hier nochmal der Nachweis im Anhang: Core 2 raucht komplett ab! Ohne die Änderung über die Affinity nur 0 bis 1 zu nutzen, ist es uns nicht möglich mit JTL zu arbeiten.


Danke nochmal an meinen Freund, den ich hier leider nicht nennen kann - er wird es lesen

 

[Marc Völker]

Moin,
ich versuch mal aus sicht eines Entwicklers auf dieses Thema etwas einzugehen.
Zu beginn, dass Multithreading Verhalten der Wawi wurde hier natürlich nicht von hand irgendwie umgesetzt. So dass man dadurch in solche Probleme laufen kann, man nutzt hier daher schon etablierte Technologien, die das .Net Framework zur verfügung stellen.
Zum anderen, wenn jemand die Presse auf Golem / Heise / pcgameshardware die letzten Wochen verfolgt hat, wurde da auch von Problemen bei AMD Prozessoren in Bezug auf NUMA Knoten die Rede ist. Anbei mal 2 Links zu Artikeln
https://www.pcgameshardware.de/Ryze...-Verbesserungen-Windows-10-Scheduler-1272524/
https://www.golem.de/news/core-i9-1...ettet-sich-ueber-den-preis-1911-145162-2.html

Das Problem ist dabei eben der Windows Scheduler, der das ganze Koordiniert mit dem Multi Threading, und dieser hat wie es sich aus den Artikeln liest mit der Konstruktion der NUMA Knoten aktuell Probleme.
Unabhängig davon zur ersten Aussage noch mal zurück, müsste man hier auch auf entsprechende Updates seitens Microsoft hoffen, in welchen diese Problematiken angegangen werden.

Sollte jemand solche CPUs im Bereich des SQL Servers verwenden könnte das ganze auch noch größere Performance Probleme bedeuten.

P.S. Ein Core kann reichen, aber bitte rechnet damit, dass dies zu Einfrieren der Wawi führen kann. Gerade bei CPU Intensiven Aufgaben.

Ansonsten zu den Vorredner und Mike ist nicht viel zu sagen, da wurde soweit alles gesagt.
Oberer Beitrag von mir kann natürlich bei solchen Problemen auch auf den Server zeigen, auch können immer mal Updates seitens Windows, oder nur andere Software die installiert wurde, auch fehler oder verzögerungen verursachen, mit welchen man so nicht rechnen würde.

 

[rudlerrocks]

Ja, es ist in der Tat immer ein Core auf dem Numa 2. Also ausnahmsweise kann JTL doch nicht so viel dafür

Abhilfe schafft der Tweak, bis Microsoft hier nachgelegt hat. Bitte, gerne.
Wir können jetzt arbeiten, vorher war ja gar kein Arbeiten möglich.

 

[kutti]

Welcher CPU wird denn empfohlen???
Core = Nein ?
Ryzen = Nein ?
AMD = Nein ?