Übersicht über die wichtigsten Symptome, welche wir feststellen konnten:
- shopware 5.6 Backend Login nicht mehr möglich. Der Login-Fortschrittsbalken läuft ca. 20 Sekunden, dann verschwindet er und der Login-Screen bleibt leicht abgedunkelt.
- Bestellungen laufen bis zum letzten Schritt im Checkout Prozess. Der Kauf kann aber nicht durchgeführt werden.
- Es gibt Fehlermeldungen im Log auf Error und Warning Level
- Shop fühlt sich langsam an
- core.ERROR: exception 'PDOException' with message 'SQLSTATE[HY000]: General error: 1205 Lock wait timeout exceeded; try restarting transaction' in…
- table locks
- session locks
Hintergrund:
Bei einem Kunden trat plötzlich der Fall auf, dass man sich nicht mehr in das shopware 5.6 Backend einloggen konnte. Beim Eingeben von Benutzername und Passwort lief der blaue Fortschrittsbalken in einer Schleife von links nach rechts, dann irgendwann tat sich nichts mehr - TimeOut. Es wurde im Backend weder etwas verändert, noch ein Plugin aktualisiert oder etwas gelöscht. Das Problem trat sporadisch auf und so war das Frontend mal problemlos erreichbar und arbeitete schnell und zuverlässig. Auch Bestellung, Checkout-Prozess und Bezahlung konnten durchgeführt werden. Jedoch nur, wenn das Backend auch lief. Ebenfalls kamen die E-Mail-Bestätigungen schnell beim Besteller und auf der Shop-Betreiber Adresse an.
Backend Login plötzlich nicht mehr möglich: Die Konsole lieferte drei JavaScript Fehler aus, jedoch erwies es sich als nicht zielführend diese zu googlen oder zu verfolgen. Wenn man im Internet danach sucht, dass plötzlich kein Backend Login mehr möglich sei, gibt es in den Shopware Foren einige Einträge, jedoch verhält es sich bei jedem User anders und teilweise enden die Threads ohne Lösung.
Die Anzahl der gleichzeitigen Verbindungen der Datenbank war auf 900 Verbindungen begrenzt. Diese wurden zwar noch nicht überschritten, aber dennoch erhöhten wir die Anzahl auf 2.000 Verbindungen. Auch das brachte aber keine Veränderung.
Mit dem SQL-Befehl „show variables like "max_connections";” könnt ihr die Anzahl der maximalen Verbindungen auslesen.
Konkret konnten wir feststellen, dass beim Backend Login der Wert „lockeduntil“ in der Tabelle „s_core_auth“ nicht geschrieben wurde. Es gab table locks und session locks.
Wir haben Änderungen in der Tabelle „s_core_auth“ den Wert für sessionID erhöht und zwar auf VARCHAR(60). Weiter haben wir das Feld lockeduntil mit dem Wert „0000-00-00 00:00:00“ beschrieben. Ein Backend Login war dennoch nicht möglich. In unserem Fall war es spät in der Nacht und der Shop hatte keine Besucher, deswegen haben wir die noch laufenden mySQL queries gelöscht und dann herausgefunden, dass manche Tabellen gesperrt waren (table locks). Jedoch hat auch das entsperren der Tabelle nichts gebracht.
Die Lösung für shopware 5.6
Als kurzfristige und provisorische Lösungen konnten wir das Problem lösen, indem wir die Datenbank neu gestartet haben. Allerdings ist diese Lösung sehr mit Vorsicht zu genießen, da laufenden Prozesse gekilled werden. Sollte Ihr Webshop als kurzfristige Lösung ein Neustarten der Datenbank erfordern, vergewissern Sie sich vorher bitte genau, welche SQL-Abfragen laufen und beenden Sie diese mit Bedacht.
Als Endgültige Lösung haben wir einen REDIS Server installiert und die Sessions für Frontend und Backend zu REDIS ausgelagert.
Die Anpassung kann in der config.php (shopware root Verzeichnis oder /app Verzeichnis) vorgenommen werden:
'session' => array(
'save_handler' => 'redis',
'save_path' => "tcp://127.0.0.1:6379",
),
'backendsession' => array(
'save_handler' => 'redis',
'save_path' => "tcp://127.0.0.1:6379",
),
Per SSH kann ein Blick ins Monitoring geworfen werden. Der Befehl dazu lautet:
redis-cli -p 6379 MONITOR
Standardmäßig werden bei shopware die Sessions in der MySQL-Datenbank anstatt im Dateisystem gespeichert. Dies lässt eine wesentlich geringere Anzahl an Operationen pro Sekunde zu und ist somit deutlich in-perfomanter. Redis ist eine quelloffene In-Memory-Datenbank, welche in die Gruppe der NoSQL-Datenbanken einzuordnen ist. Die Datenhaltung erfolgt durch einen einfachen Key-Value-Store, wodurch ein extrem schneller Zugriff auf die im Arbeitsspeicher zwischengespeicherten Informationen ermöglicht wird. Es bietet dadurch die Performance, Skalierbarkeit und Stabilität, die notwendig sind, um große Webshops oder Web-Portale zu betreiben.
Die Anfragen an die Datenbank werden drastisch reduziert. Table- und Session-Locking Probleme haben wir seitdem nicht mehr.