Gelöst Upload WaWi -> Shopware bricht immer ab

[SeFi]

Hallo an alle, ich bitte dringend um eure Hilfe, da wir mit unserem Latein absolut am Ende sind.

Zur Ausgangslage:
Wawi-Version : 1.3.17.1
Shopware-Version : 5.2.2
Connector-Version : 2.0.11

Shop-Serverinfo:
Memory Limit 512MB
Execution Time 3600sek (aus lauter Verzweiflung)

Beim Shopabgleich:
Upload WaWi -> Shopware bricht immer ab
Import Shopware -> WaWi läuft dagegen problemlos

Wir haben vorgestern mehrere Kategorieänderung in JTL-WaWi durchgeführt, welche nicht zum Shop-Übertragen werden, da scheinbar Shopware zu lange braucht (>240 Sek) um den Kategoriebaum neu zu berechnen (wir haben ca. 350 Kategorien). Der Abgleich bricht ab, da die Kategorien zuerst übertragen werden, Bestandsänderungen sind damit seit vorgestern nicht mehr übertragen worden!!!

Wir haben aus lauter Verzweiflung bereits
- Integrity-Check zum Connector auf der Seite durchgeführt -> bis auf ein paar Einträge unauffällig
- den Shop auf eine Testdomain kopiert und den Connector umgeleitet
- Connector neuinstalliert
- sämtliche Kategorien gelöscht im Backend von Shopware
- danach Komplettabgleich angestoßen -> am Anfang werden die Kategorien schnell übertragen, das berechnen des Kategoriebaums dauert aber in Shopware ab ca. 150-200 Kategorie sehr lange, irgendwann bricht er immer ab, da 240 Sek überschritten werden?!?!
- da ich nicht weiß, wo man dieses Zeitlimit einstellt, haben wir Übertragungsparameter des Connectors in der WaWi umgestellt, damit weniger Kategorien gleichzeitig hochgeladen werden und Shopware schneller den Kategoriebaum berechnen kann
- Paketgröße von 10 auf 5 pro Upload-Paket -> leider werden trotzdem 10 gleichzeitig übertragen (vermutlich durch den mal angestoßenen Komplettabgleich mit Paketgröße 10???)
- Komplettabgleich auch nochmal nach vollem Rücksetzen des Connectors + Shopware-Kategorien löschen angestoßen -> bleibt bei 10 -> Shopware braucht zu lange -> Abbruch!!!

Hier kommen wir absolut nicht mehr weiter.

Die Logdateien nach dem letzten Anstoß eines Komplettabgleich habe ich beigefügt. Ich vermute, dass der Abgleich von der WaWi nach 240Sek neu angestoßen wird (>>> core.connector.auth), obwohl Shopware noch nicht fertig ist. Nach 10 erfolglosen Übertragungsversuchen des Kategorie-Pakets bricht der Abgleich mit Fehler ab.

Bitte, bitte helft mir, das Ding MUSS laufen. Es ist nur eine Frage der Zeit bis uns die unzähligen Falschbestellungen um die Ohren fliegen, da die Bestände nicht abgeglichen werden...


Dateianhänge:

• Wawi Abgleichlog
• Connector Debug Logs

Fragende und bittende Grüße,
Sebastian

Nachtrag: Support-Anfrage läuft auch unter Ticket#2019031410001815

 

[utuz]

Bei mir hat es schlicht am selbst Server gelegen.
Die Werte von dem Dedicated Server waren alle astrein und von der Hardware sehr gut ausgestattet.
Ich hatte sogar den Server gewechselt, aber nichts ging. Immer das gleiche Problem.
Irgendwann nach Monaten des probierens und einschaltens des Supports sowohl von JTL als auch den des Servers, habe ich dann aus Verzweiflung quasi als letzten Versuch dann den Servertyp gewechselt. weg von einem AMD Server hin zu einem Intel Server und schon ging die Luzi ab wie eine Rakete. Muss man erstmal darauf kommen.
Ob das nur an der CPU gelegen hat, oder die komplette Konfiguration des Servers der Auslöser war, das es nicht funktioniert hatte, weiß ich nicht. Ist aber letztendlich auch egal.
Ob meine Lösung auch für Dich gilt, kann ich nicht sagen. Es gibt viele Möglichkeiten woran das liegt.
Gruß Joachim

 

[SeFi]

Hallo Joachim, besten Dank für deine schnelle Rückmeldung.

Ich hatte das Problem jetzt eher bei der WaWi vermutet, ich ja gerne die Paketgröße runterstellen würde, dies allerdings nicht umgesetzt wird, da der Komplettabgleich irgendwie priorisiert mit alten Einstellungen (Paketgröße 10) abgearbeitet wird. Warum Shopware so lange für die Kategorien braucht ist natürlich auch eine Frage, die ich mir stelle. Bei 350 Kategorien sollte das eigentlich doch noch problemlos ablaufen. Andere haben da >10.000.

Vielleicht hat noch jemand einen Ansatz für mich?

Viele Grüße,
Sebastian

 

[utuz]

Kennst Du denn die Konfiguration von Deinem Server?
Nach meinen Erfahrungen liegt es eher nicht an der WaWi.
Das können dann Einstellung direkt am Server sein. Da kann man mit den Limits experimentieren.
Eventuell ist ja Deine Verbindung auch mies.
Was auch sein kann, wäre, das Deine Kiste nicht genug Power hat, also nicht genug Arbeitsspeicher. um mit der Datenbank richtig arbeiten zu können.
Dazu kann es an der Datenbank auf Deiner Kiste auch liegen. Oder eben Online, je nachdem was für einen Server wo gemietet hast.
Gruß Joachim

 

[SeFi]

Wir haben einen selbstgehosteten Intel Xeon mit 8Gb RAM, Debian 8 64bit, PHP7.0.33-0+deb9u3. Die Internetverbindung ist mit 16MBit nicht die Beste, aber sollte eigentlich auch ausreichend sein. Auch der WaWi-Server ist ausreichend dimensioniert.
Datenbankprobleme kann ich natürlich nicht ausschließen, da fehlen mir nur die Ansätze wonach ich suchen muss. Einziges Symptom momentan ist der Abbruch da Zeitlimit zu niedrig bzw. Berechnungsdauer des Kategoriebaums zu lang + Abbruch der Verbindung.

Gruß,
Sebastian

 

[utuz]

Hüstel!! Muss zwar nichts mit dem Problem zu tun haben, aber 8GB ist recht dürftig. Da ist die Kiste doch nur mit sich selber beschäftigt. Normal hat man da alleine schon für die Datenbank 10-12 GB. Gängig für einen Server wären so um 32 GB, damit man auch noch was für die Zukunft an Puffer hat.
Selbstgehostet?? Was habt Ihr denn für eine Anbindung? Glasfaser 1 GB?
Gruß Joachim

 

[gre000]

Wie steht die MySQL Einstellung:
innodb_flush_log_at_trx_commit

Stell Mal auf 2 daran lag es bei einem Kunden

 

[Immanuel]

Hallo @SeFi,

welches Dateisystem kommt auf der Partition auf der die Datenbank liegt zum Einsatz? Falls das ext4 ist, dann könnte das Mounten dieser Partition mit der nobarrier Option helfen die Schreib Performance der Datenbank zu verbessern. Das wiederum würde das Bauen des Kategoriebaumes wahrscheinlich stark beschleunigen.

 

[SeFi]

ähm, sorry, selbstverwalteter Root-Server bei Strato. Hm, bisher waren wir mit der Leistung des Servers absolut zufrieden. Laut unserem Server-Admin ist das System auch mehr als ausreichend.

Danke @gre000 und @Immanuel für die Ansätze. Dann haben wir erstmal wieder was zum probieren.

Viele Grüße,
Sebastian

 

[gre000]

Wie viele Kategorien hab hier denn insgesamt? Ab ca. 3.000 wird es echt langsam (dafür gibt es schon ein Ticket)

Aber bei weniger Kategorien läuft das selbst auf einen billig Server sehr schnell.

Ich hatte das Problem bei einem Kunden nach einem Hoster Wechsel vorher Kategorieabgleich OK schnell nach dem Wechsel ist er nach gut 10 Stück abgebrochen. Mit Sessiontimeout
Mit ändern des innodb_flush_log_at_trx_commit Wertes von Default 1 auf 2 hat sich die Geschwindigkeit verhundertfacht.

 

[dolfy]

Auf eine eigen Server würde ich erst mal alles loggen lassen was eben geht, php,mysql system etc.
In irgend ein Log sieht man dann vielleicht ein hinweis auf Timeout oder der gleiche.

Fehlersuche ist nicht immer einfach. Am Anfang hatte ich auch ein Problem gehabt das ein neue Artikel mit 13000 Variationen sich nicht übertragen lässt.
Auch immer abgebrochen.
Mein hoster (Nginx shared hosting extra für Shopware angepasst) hat teilweise die Timeouts für mich hochgesetzt, im Log war angeblich keine Fehler zu sehen.
PHP logs würde auch hochgesetzt, angeblich auch nichts zu sehen.
JTL könnte in meine Logs auch nicht finden, so ging es immer hin und hier zwischen JTL und Hoster.

In eine loklae VMware habe ich ein debian vm aufgesetzt und ein Kopie vom Shop erstellt, allerdings unter apache.
Dort hat der Sync von Wawi->Shopware einwandfrei funktioniert. Also muss es am Hoster oder "langsame" Internet liegen, wir haben auch 16MBit.
Wo das problem war oder ist weiß ich nicht, den Artikel packe ich nicht mehr groß an. Preise aktualiserend funktioniert aber.
Ich habe damals alles in der VM fertig übertragen, backup gemacht und beim Hoster eingespielt, html und sql.
So könnte ich auf der schnelle erstmal wieder weiter machen.

Der VM ist jetzt meine Testkiste, alle Updates wird erst dort eingespielt, vorher natürlich aktuelle status spiegeln.
Erst dann kommt der Live system an der reihe.
Alle großere Änderungen werden auch immer am Testsystem durchgespielt um nicht nachher da zu stehen mit probleme.
Macht zwar viel mehr arbeit und war bisher immer unnötig, aber sicher ist sicher.

Ich an eure Stelle würde erstmal ein Testsystem im lokal netz oder als VM aufsetzten und dort testen.
So kann man wenigstens schauen ob der Fehler mit wandern, wenn ja lässt es sich an ein Testsystem viel besser experimentieren,

 

[SeFi]

@gre000: Dein Tip mit innodb_flush_log_at_trx_commit Wertes von Default 1 auf 2 war schonmal goldrichtig. Das hat schonmal deutlich die Geschwindigkeit erhöht. Vielen Dank dafür!

Wir haben jetzt auch das Kernproblem gefunden:
Unser Admin hat den Server vor kurzem auf Debian 9 inkl. MariaDB geupdated, allerdings MariaDB sträflicherweise auf der Standard-Konfig belassen. Damit lief die Datenbank auf niedrigster Sparflamme und hat sich wirklich hauptsächlich mit sich selber beschäftigt. Beim normalen Abgleich (Bestellungen abrufen, Bestände abgleichen, etc.) ist da nichts aufgefallen. Nun kam der erste Kategorie-Abgleich am Dienstag mit gleich mehreren Änderungen gleichzeitig und das System war mit der Neuberechnung des Kategoriebaums in Shopware total überfordert -> damit Timeout + Leidensgeschichte siehe oben.

Wer also das gleiche Problem hat, sollte sich zuerst um seine Datenbank-Geschwindigkeit kümmern -> zuerst per Konfiguration, wenn ausgereizt dann Hardware...

Ich werde hier nachher noch die wichtigsten Server-Konfig-Variablen eintragen, die dem System auf die Sprünge geholfen haben.

An dieser Stelle ein richtig dickes Danke an alle fürs mitdenken

Nun hab ich zwar noch einen Komplettabgleich vor mir, da ich zuviel mit dem Connector rumgespielt habe, aber nun läufts ja auch.

@dolfy: nach dieser Operation am offenen Herzen (Debian 8 -> 9 ohne Test) halte ich deinen Vorschlag mit dem kompletten Testsystem für sehr, sehr sinnvoll und wir werden das umsetzen! Danke auch dafür

Beste Grüße,
Sebastian

 

[SeFi]

Hi, hier auch noch ein paar Hinweise vom Admin zur Konfiguration, vielleicht hilft es ja jemandem mal irgendwann:
_______
Bei dem Upgrade zu Debian 9 wurde der MySQL Server gegen MariaDB ausgetauscht, einem Fork von MySQL. Die Migration aller Daten klappte problemlos. Nur die Konfiguration der Datenbank unter /etc/mysql/ wurde falsch umgelegt. Es entstanden neue Dateien für MariaDB und die alten Dateien vom MySQL wurden durch Standardeinstellungen ersetzt. Bei dem Versuch innodb_flush_log_at_trx_commit auf 2 zu setzen stellten wir fest dass keine MariaDB-Konfiguration geladen wurde. Nach einigen Tests stand fest dass MariaDB weiterhin die my.ini lädt. Dort waren minimale Werte für die Caches und Puffer hinterlegt. Nach dem erhöhen der Werte (und zusätzlich auch innodb_flush_log_at_trx_commit auf 2) rennt der jtl-connector wieder mit voller Geschwindigkeit.

Von der Standardkonfiguration wurden folgende Werte verändert:

innodb_buffer_pool_size = 1G (vorher default bei 32M)

key_buffer_size = 1G (vorher 32M)

query_cache_limit = 4M (vrher 2M)

query_cache_size = 64M (vorher 32M)


Damit läuft der Connector. Puffergrößen sollten später noch an den richtigen Bedarf angepasst werden nachdem der Server ein paar Tage fehlerfrei lief. (siehe zB RIBPS)
________
Viele Grüße,
Sebastian

P.S.: Wie schließe ich ein Support- Ticket? Wie markiere ich bzw. irgendwer ein Problem als gelöst?