KeyHelp Community

Nachdem jetzt jahrelang 2 JTL Shops ohne Probleme auf einem älteren Server mit Liveconfig liefen habe ich sie jetzt auf einen neuen Server mit Keyhelp migriert.

Jetzt ist dummerweise die Performance unterirdisch und der komplette Server geht in die Knie. Hauptproblem scheinen Querys zu sein die endlos laufen.

Mittlerweile wurden die Shops auf die neusten Versionen geupdatet, alles mögliche an den Php Limits durchprobiert und an den Einstellungen vom Mariadb rumgeschraubt. bspw kann man ja ein Limit einführen das die Querys nach X Sekunden abgeschossen werden. Geholfen hat davon nichts.
Das einzige was Einfluss hatte war die Aktualisierung auf die neuste Version des Shops, hat aber nur Kurzfristig etwas gebracht und es hat sich wieder auf eine hohe Auslastung hochgeschaukelt.


Nun war meine einzige Idee die übrig blieb es auf einen Server mit ner älteren Debian Version zu migrieren (nur kurzfristige Lösung) aber gebracht hat das auch nix.



Hat jemand eine Idee? Mir gehen langsam die Ideen aus. Das sind auch kleine Shops ohne viel Aufrufe und alle Bots habe ich schon abgewürgt, daran liegts leider auch nicht. Die Server sind auch mehr als ausreichend augestattet (Ryzen 9 5950X/128GB Ram)




Server:

-----------------
Liveconfig
MariaDB 10.3.36
Debian GNU/Linux 10.13
------------------
Auf dem Lief es Jahrelang ohne Auffälligkeiten.



-----------------
Debian 13.4 (64-bit)
MariaDB 11.8.6
KeyHelp 25.3
---------
Debian 12.13 (64-bit)
MariaDB 10.11.14
KeyHelp 25.3
-----------------
Auf den beiden läuft es katastrophal. Keyhelp läuft auf beiden ohne Änderungen. An JTL wurde abseits vom Design auch nichts geändert.

Immer dieselbe Frage: Was sagen die Logs?

Wie kommst Du darauf, dass es an den Queries liegen könnte? Sonst ggf. mal das Slow-Query-Log anschalten und anschauen, ob es dort Auffälligkeiten gibt,

Oder ganz banal: Du schreibst „migriert“. Vielleicht hat es dabei eine Datenbanktabelle beschädigt (irgendwelche Temp-Tabellen trifft sowas gerne mal)? Dabei spielt so ein Datenbanksystem gerne auch mal verrückt. Analysieren, optimieren und ggf. reparieren kann da Wunder bewirken.

Ist es dann im Shop überhaupt zu bemerken und nicht nur eine "gefühlte" Überlastung? Der Graph unten ist nämlich relativ harmlos und keine Erklärung für Performance-Probleme. Der CPU-Load berechnet sich pro Kern, sprich: Erst bei dauerhafter Auslastung von 32 oder mehr wäre der Server überlastet (und selbst dann spielen da noch andere Faktoren rein und man muss es nicht mal unbedingt merken). 8 ist da doch sehr harmlos, die CPU ist nach wie vor im Status „Langeweile“.

Die Logs sagen nichts relevantes bzw auch nichts was irgendwie verwertbar wäre, mehr als das gibt es nicht.

Die Execution Time hochzustellen war meine erste Idee. Aber es läuft sich halt einfach tot auch wenn man sie auf 30min setzt. Und würde auch nicht das Problem lösen. Die bleiben einfach stehen.

Das einzige was die JTL Shop von anderen unterscheidet sind ewig laufende Querys. Optimize und Co hat genauso wenig ein Ergebnis gebracht wie das neue überspielen der Datenbanken.

Und ja die Überlastung drückt sich dadurch aus das der Shop irgendwann nicht mehr zu erreichen ist und auch alles andere auf dem Server nicht wie zb Keyhelp.

Der Graph sollte eigentlich nur zeigen das man genau darstellen kann ab wann die Shops auf dem Server liefen. Die kaum existenten Kurven vorher stammen zb von einem Shopware 5 der ungefähr 50 mal so viele Aufrufe hat wie die beiden JTL zusammen.

Der Plötzliche Abfall rührte daher das beide Shops auf die neuste Version geupdatet wurden. Was halt kurios ist weil ich dachte es wäre damit erledigt.
Aber auch das experimentieren mit verschiedenen PHP Versionen und dem Caching verhalten der Shops haben nichts gebracht.

Im Moment läuft ein Versuch damit die PHP Dateien auf dem neuen Server laufen zu lassen und die Datenbank remote auf dem alten Server. Das lief ein paar Minuten echt gut(wenn auch langsamer) aber mittlerweile steht es wieder komplett. Schade, ich dachte ich könnte das Problem auf ne inkompatible Mariadb Version eingrenzen.