MySQL Deadlock error

[Crafter]

Hallo zusammen,

in unserem xt 6.3.3 Shop kommt es immer mal wieder zu SQL Fehler in denen ein Deadlock gemeldet wird.

Den Part nach "customer" habe ich in der Meldung entfernt, da ich nicht ganz sicher war ob dort sensible user daten drinne stehen könnten.

Die letzte Meldung sieht so aus:

(2022-01-28 10:26:44) mysqli error: [1213: Deadlock found when trying to get lock; try restarting transaction] in EXECUTE("UPDATE xt_sessions2 SET expiry=NOW() + INTERVAL 1440 SECOND, sessdata='_USE_CACHE_COUNTRIES%7Cb%3A0%3B_USE_CACHE_LANGUAGE_CONTENT%7Cb%3A0%3Bcustomer[...]', expireref= '',modified=NOW() WHERE sesskey = 'gakvvsfna1fs7inig5f786925z'")
#0 /home/user/shop/xtFramework/library/vendor/adodb/adodb-php/adodb.inc.php(1329): ADODB_Error_Handler(...)
#1 /home/user/shop/xtFramework/library/vendor/adodb/adodb-php/adodb.inc.php(1269): _Execute(...)
#2 /home/user/shop/xtFramework/library/adodb-xt/adodb-session2-xt.php(745): Execute(...)
#3 (): write(...)
#4 (): session_write_close(...)
------------------------------------------------------------
(2022-01-28 10:26:44) probably detected recursion for last exception in xt's adodb error handler. up following exception was
    mysqli error: [0: ] in EXECUTE("SELECT * FROM xt_stores  ORDER BY shop_id")

 

Jemand eine Idee woran das liegen könnte?

 

[mjuergens]

Das Problem hatte ich auch. Das liegt daran, dass die Tabelle "xt_sessions2" zu gross wird und dann kommt ein Timeout von der Datenbank beim Zugriff auf die Tabelle.

Das Problem tritt meistens auf, wenn ein angemeldeter Benutzer sich wieder abmeldet. Dann wird anscheinend versucht die Session-Daten wieder aus der Tabelle zu löschen und das läuft auf ein Timeout wenn die Tabelle zu viele Datensätze enthält.

Temporär kann man sich damit helfen die Tabelle einfach zu leeren. Auf Dauer kann das aber nicht die Lösung sein.

Ich würde eigentlich davon ausgehen, dass alte Session-Daten irgendwann automatisch aus der Tabelle gelöscht werden aber das scheint entweder gar nicht so zu sein oder nicht zu funktionieren.

Falls das Problem nach dem neuen Update 6.4 (Was ja jeden Moment kommen dürfte, so wie es aussieht) immer noch besteht, dann werde ich mir wohl einen Cron-Job einrichten, der die alten Daten regelmäßig löscht.

[Alex@4tfm]

Haben wir in letzter Zeit auch wieder öfter beobachtet. Scheint mir fast, das da die Einträge in der Tabelle nicht gut gelöscht werden.

[mjuergens]

"Nicht gut gelöscht" ist aber sehr milde ausgedrückt. Ich hab zwei Shops wo die anscheinend gar nicht gelöscht werden, denn da wächst die Tabelle ziemlich schnell auf mehrere hunderttausend Datensätze.

[xt:Commerce]

Da muss man sich die Serverkonfiguration ansehen. 

Der shop registriert eine session garbage collection, welche von apache dann je nach traffic und einstellung getriggert wird.

session.gc_probability und session.gc_divisor

6.4 hat hier in der conf/config_sessioons.php auch noch eine eigene Einstellungsdatei dazu, wenn man das nicht über die php.ini setzen möchte.

Grundsätzlich muss man dies natürlich bei low traffic und high traffic seiten auch beobachten und entweder die werte genau auf den traffic einstellen, oder über einen cronjob leeren.

[Crafter]

Also lässt sich die Tabelle bedenkenlos leeren (bzw Einträge wo der Wert "expire" bereits in der Vergangenheit liegt regelmäßig löschen)?  

[netzzitrone]

Mit einer Umstellung des Session-Handlings auf einen Redis-Server besteht das Problem auch nicht mehr ;). Dies ist mittlerweile in xtCommerce ja auch per Konfiguration recht einfach steuerbar (einen Redis-Server vorausgesetzt)

[Krüger-Maritim]

DELETE FROM xt_sessions2 WHERE DATE(expiry) < DATE(NOW());

[alcado]

Hi zusammen,

das Problem liegt u.a. auch am Statement "/*! BINARY */". Sobald man das auf "/* BINARY */" ändert (also Ausrufezeichen "!" raus), läuft es...

Gruß,
Markus Zierhut

[Alex@4tfm]

On 12/13/2023 at 8:21 AM, alcado said:

 

das Problem liegt u.a. auch am Statement "/*! BINARY */". Sobald man das auf "/* BINARY */" ändert (also Ausrufezeichen "!" raus), läuft es...

 

Könntest du das genauer ausführen?

[alcado]

Das Problem hatten wir auch bei einer sehr großen Shop-Umgebung auf Basis eines anderen Forks von osCommerce...
Auch hier beim Kunden - ohne das Statement läuft es problemlos, mit dauernd Deadlocks ...

[joephill6543]

I'm also encountering this issue.

In our xt 6.3.3 shop, we occasionally encounter SQL errors in which a deadlock is reported. Moreover, if you want to download capcut then visit this site capcutproapk.org. The last message looks like this:

(2022-01-28 10:26:44) mysqli error: [1213: Deadlock found when trying to get lock; try restarting transaction] in EXECUTE("UPDATE xt_sessions2 SET expiry=NOW() + INTERVAL 1440 SECOND, sessdata='_USE_CACHE_COUNTRIES%7Cb%3A0%3B_USE_CACHE_LANGUAGE_CONTENT%7Cb%3A0%3Bcustomer[...]', expireref= '',modified =NOW() WHERE sesskey = 'gakvvsfna1fs7inig5f786925z'")
#0 /home/user/shop/xtFramework/library/vendor/adodb/adodb-php/adodb.inc.php(1329): ADODB_Error_Handler(...)
#1 /home/user/shop/xtFramework/library/vendor/adodb/adodb-php/adodb.inc.php(1269): _Execute(...)
#2 /home/user/shop/xtFramework/library/adodb-xt/adodb-session2-xt.php(745): Execute(...)
#3 (): write(...)
#4 (): session_write_close(...)
-------------------------------------------------- ----------
(2022-01-28 10:26:44) probably detected recursion for last exception in xt's adodb error handler. up following exception was
    mysqli error: [0: ] in EXECUTE("SELECT * FROM xt_stores ORDER BY shop_id")
 

Has anyone an idea what the problem might be?