wir lassen bei unserem Kunden nachts diverse Cronjobs laufen. U.a. Thumbnail-Generierung, Cache-Aufwärmen, Produkt-Feed-Exporte etc.
Bei fast jedem dieser Cronjobs kommt an der einen oder anderen Stelle ein “MySQL server has gone away in […]/data/vendor/doctrine/dbal/lib/Doctrine/DBAL/Connection.php on line 828”.
Meistens dann, wenn ein Cronjob gerade lange Zeit irgendetwas getan hat (z.B. knapp zwei Stunden lang URLs aufgewärmt). Im Falle des Cache-Aufwärmens habe ich z.B. gesehen, dass die Connection außerhalb der foreach-Schleife, in der die einzelnen Shops durchlaufen werden, aufgebaut wird; beim zweiten Shop nach zwei Stunden also dieselbe Connection verwendet wird. Bei den anderen Cronjobs wird es denke ich ähnlich sein.
Sollte Shopware hier nicht einen Mechanismus einbauen, der prüft, ob die Connection noch aufrecht ist, und falls nicht sie neu aufbauen? Das Problem zieht sich wie gesagt über alle Cronjobs hinweg, die in irgendeiner Form etwas längere Arbeit verrichten.
Das wait_timeout auf über 2 Stunden setzen ist vermutlich nicht so cool…
Hat jemand eine Idee, wie man die vielen Fehlermeldungen wegbekommt? Kann mir nicht vorstellen, dass ich der einzige mit dem Problem bin…
Ihr könntet zwischen den einzelnen Prüfungen die Verbindungen manuell kappen und neu aufbauen, außerdem gibt es am Server gewisse Einstellungen, wie lange Verbindungen aufrecht erhalten werden, welche Datenmengen pro Aufruf maximal übertragen werden dürfen, Maximallaufzeit für Skripte usw. Einige dieser Einstellungen sollten für Cronjobs nicht zählen, aber einen Versuch ist’s wert.
Fraglich ist auch, ob man die Skripte nicht irgendwie optimieren kann, damit diese nicht mehr so lange brauchen… das reduziert die Chance auf Abbruch natürlich auch nochmal zusätzlich.
Bei einigen Skripten wäre es vermutlich tatsächlich möglich; z.B. könnte man das Cache aufwärmen für jeden Shop einzeln starten. Andere Cronjobs wie z.B. der Produktexport erlauben das nicht und führen am Ende der Bearbeitung noch einmal einen Query aus, der dann aufgrund mangelnder Verbindung scheitert.
Max allowed packet und die timeouts haben wir eigentlich alle schon erhöht. Die wait_timeout von MySQL auf über 2 Stunden stellen würde ich ungern. Genau, die Skriptlaufzeit ist unter CLI eh aufgehoben und dürfte mit der reinen MySQL-Connection ja auch nichts zu tun haben.
Optimieren kann man beim Cache-Aufwärmen wenig. Sind halt über 7000 Links pro Shop (4 Shops), das dauert seine Zeit
Okay, sehe es also richtig, dass es hier seitens Shopware keine Vorkehrungen gibt? Habe auch schon (recht alte )Issues dazu gefunden, die aber nicht gescheduled sind. Schade
Bau dir doch eine run.php welche dein Skript für jeweils einen Shop startet und rufe dann die run.php mit Parameter per Cronjob auf, so kannst du die Shops nach und nach oder sogar parallel durchlaufen lassen und hast immer eine eigene Verbindung.
Dadurch kannst du auch recht schnell neue Shops hinzufügen oder alte Shops deaktivieren, das passiert dann nämlich nur noch über Angabe des Shops in der run.php.
Kurze Rückmeldung: Das Hochsetzen des wait_timeout auf 30 Minuten hat erstmal Abhilfe geschaffen.
Erkenntnis: Das Aufwärmen für die Shops innerhalb eines Shell-Skripts nacheinander starten hat „nicht“ funktioniert. Ich nehme an weil hier eine Art Singleton für den Cache-Warmer benutzt wird und das dann wieder ein und dasselbe Connection-Objekt ist. Was aber ging: Das Aufwärmen direkt in der crontab um eine Minute zeitversetzt für jeden Shop zu starten! Einfach weil die wait_timeout dann noch nicht abgelaufen ist.
