ProjektEMProjektEM MemberComments: 12 Received thanks: 0 Member since: March 27

Hallo,

Wir haben 600.000 Artikel im Shop (Testumgebung, Community-Edition, ). Den Cache komplett aufzuwärmen oder nur die Produkte klappt nicht, übers Backend bleits hängen, per CLI wird der Auftrag ohne Meldung beendet. Bei den 513 Hersteller-Einträgen dauert es im CLI mit

php bin/console sw:warm:http:cache -b 10 -m

30 Minuten. Manchmal läuft es durch, manchmal gibt es schon nach 5 Minuten eine Meldung (z.B. wenn ich -b auf 1 setze):

In DBALException.php line 131:
An exception occurred while executing 'SELECT main_id FROM s_core_shops WHERE active = 1 AND id = ?' with params [1]:
SQLSTATE[HY000]: General error: 2006 MySQL server has gone away

In Connection.php line 847:
SQLSTATE[HY000]: General error: 2006 MySQL server has gone away

HTTPCache ist freilich aktiviert. PHP7.2.

Mysql Ver 14.14 Distrib 5.6.43-84.3:

connect-timeout                   0
max-allowed-packet                16777216
net-buffer-length                 16384
select-limit                      1000
max-join-size                     1000000

wait_timeout liegt momentan bei 120.

Zugriff auf my.cfg gibt es nicht. Gibt es eine andere Möglichkeit wait_timeout  hochzuschrauben, außer über die my.cfg? Das scheint ja in anderen Fällen geklappt zu haben. Was wäre bei dieser Artikelmenge ein sinnvoller Wert? 28800?

Answers

  • MurmeltierMurmeltier MemberComments: 905 Received thanks: 162 Member since: April 2017

    Tja, das kenne ich nur zu gut!

    Wir haben etwas über 300.000 Artikel und ein managed Server... und trotzdem kackt das Ganze immer wieder ab! Entweder schraubst Du die Hardware hoch oder Du wirst immer wieder solche Probleme haben, also gerade bei einer solchen Menge an Artikeln! Shopware ruft ja jede einzelne Seite auf um sie zu cachen...

    Thanked by 1ProjektEM
  • ProjektEMProjektEM MemberComments: 12 Received thanks: 0 Member since: March 27

    Dann wird mir wohl nichts anderes übrigbleiben.

  • ProjektEMProjektEM MemberComments: 12 Received thanks: 0 edited October 29 Member since: March 27

    Der Hoster meint dazu:

    [...] wäre die wahrscheinlichste Erklärung, das das wait-timeout (Standardwert sind 120 Sekunden) des MySQL-Dienstes erreicht wird. Der Fehler kann durchaus erst eine knappe Stunde später zum skriptabbruch führen, wenn Shopware erst nach dieser Zeit die einmal geöffnete MySQL-Session weiter für die Kommunikation zum MySQL nutzen will. Eine globale Anpassung des wait_timeout-Wertes ist leider nicht möglich, allerdings kann der Wert vom Skript selbst bei Öffnen der Verbindung für die jeweilige Session auf einen gewünschten wert angepasst werden. Dies lässt sich jedoch nur im Skript realisieren, da hier die Variable von Shopware an den MySQL-Dienst übergeben werden muss. [...]

    Soviel zum Thema "managed Hosting". Ist es ratsam/möglich hier in Shopware Hand anzulegen? Ein Umzug auf einen anderen Server/Hoster macht wieder einen Batzen Arbeit ...

  • ProjektEMProjektEM MemberComments: 12 Received thanks: 0 edited October 29 Member since: March 27

    Ich habe jetzt auf einem anderen Server, auf dem ich die Serverkonfiguration selbst anpassen kann, getestet.

    max_allowed_packet in der my.cnf maximieren (z.B. 1G)
    wait_timeout in der my.cnf maximieren (z.B. 28800)
    interactive_timeout in der my.cnf maximieren (z.B. 28800)

    dann per CLI

    php -d memory_limit=4G bin/console sw:warm:http:cache -c -b 100 -p

    Es brät und brät ... und läuft jetzt den schicken Warmup-CLI-Statusbalken hoch: 25 Tage (!!!) solls dauern Gasp... Da mach ich mir zwischenzeitlich mal einen Tee. Falls das tatsächlich durchlaufen sollte, wäre ein munteres "Cache löschen" sinnfrei, zumal per Cronjob eigentlich jede Nacht der Cache gelöscht und neu aufgebaut werden sollte.

  • ProjektEMProjektEM MemberComments: 12 Received thanks: 0 Member since: March 27

    Also es hat 5 Tage gebraucht und ist durchgelaufen. D.h. für mich entweder weniger Artikel oder Server aufbohren.

Sign In or Register to comment.