Datenbank lahmgelegt

Hallo zusammen,

uns hat es die komplette Datenbank lahmgelegt. Nach Analyse von unserem hoster wurde uns folgendes mitgeteilt:

Wie besprochen, sende ich Ihnen hier die Qureys, welche die Betreffende DB lahmgelegt haben:

13423523 p223246 172.17.37.104:49733 usr_p223246_4 Query 3417 statistics SELECT SQL_CALC_FOUND_ROWS product.id as __product_id, variant.id as __variant_i
13425440 p223246 172.17.37.104:53263 usr_p223246_4 Query 3023 statistics SELECT SQL_CALC_FOUND_ROWS product.id as __product_id, variant.id as __variant_i

Leider k├Ânnen wir hiermit gar nichts anfangen, wollen aber nat├╝rlich verhindern, das so etwas nicht noch einmal vorkommt.

Hat einer eine Idee, wie wir herausfinden k├Ânnen, woher dieser Aufruf kam? Ob von einem Plugin oder ├Ąhnliches? Die Plugins sind ja verschl├╝sselt und man hat hier ja keine Einsicht um vllt die Fehlerquelle zu finden.

 

Vielen Dank f├╝r eure Vorschl├Ąge!

 

Hi,

das k├Ânnte diese Stelle sein:┬á\Shopware\Bundle\SearchBundleDBAL\QueryBuilderFactory::createProductQuery

Die wird benutzt, um die Produktlisten zu generieren / Kategorieseiten. Entsprechend kommt das bei Suchen, Filterungen und normalen Listings zum Einsatz. Ob das ein reines Core-Problem ist, ist schwer einzusch├Ątzen, da dies auch eine ├╝bliche Stelle f├╝r Erweiterungen ist. Entsprechend sollte hier zun├Ąchst gepr├╝ft werden, ob ggf. Plugins aktiv sind, die an diesen Stellen eingreifen. Sowas kann beispielsweise schon durch Funktionen wie ÔÇ×Filter direkt ausf├╝hrenÔÇť passieren, da dann die Anzahl der Filter-Anfragen massiv steigt.┬á

Weiterhin skaliert das insgesamt in MySQL nur in gewissen Grenzen, weswegen wir ab bestimmten Artikelmengen die Nutzung eines Elasticsearch-Suchservers empfehlen. Je nach Last, Server-Konfiguration und Variantenanzahl kann das ab Artikelmengen um die 80.000-140.000 Artikeln erforderlich sein.

Eine weitere Ma├čnahme stellt die Pr├╝fung des Performance-Moduls dar: Hier k├Ânnen bestimmte Funktionen deaktiviert werden, die sich negativ auf die Geschwindigkeit auswirken. Das sind meines Wissens insbesondere Preis-Filter und -Sortierungen. Da k├Ânntest du einfach mal die Optionen in dem Modul durchgehen und m├Âglicherweise nicht ben├Âtigte Funktionen deaktivieren.

Besten Gru├č,

Daniel

1 Like

Hi Daniel,

vielen Dank f├╝r deine schnelle Antwort.

Die wird benutzt, um die Produktlisten zu generieren / Kategorieseiten. Entsprechend kommt das bei Suchen, Filterungen und normalen Listings zum Einsatz. Ob das ein reines Core-Problem ist, ist schwer einzusch├Ątzen, da dies auch eine ├╝bliche Stelle f├╝r Erweiterungen ist. Entsprechend sollte hier zun├Ąchst gepr├╝ft werden, ob ggf. Plugins aktiv sind, die an diesen Stellen eingreifen.

Welche M├Âglichkeiten habe ich denn, um die Plugins zu testen?┬áDie sind ja alle verschl├╝sselt und kein Quellcode einsehbar.

Weiterhin skaliert das insgesamt in MySQL nur in gewissen Grenzen, weswegen wir ab bestimmten Artikelmengen die Nutzung eines Elasticsearch-Suchservers empfehlen. Je nach Last, Server-Konfiguration und Variantenanzahl kann das ab Artikelmengen um die 80.000-140.000 Artikeln erforderlich sein.

Okay. Dann sollten wir hier keine Probleme mit knapp 3.000 Artikeln haben. 

Eine weitere Ma├čnahme kann das Performance-Modul sein: Hier k├Ânnen bestimmte Funktionen deaktiviert werden, die sich negativ auf die Geschwindigkeit auswirken. Das sind meines Wissens insbesondere Preis-Filter und -Sortierungen. Da k├Ânntest du einfach mal die Optionen in dem Modul durchgehen und m├Âglicherweise nicht ben├Âtigte Funktionen deaktivieren.

In dem Performance-Modul ist unter Filter nur der Hersteller und der Eigenschaften Filter aktiviert. Sortierung und Preisfilter sind hier gar nicht aktiv. Und den Herstellerfilter k├Ânnten wir auch noch raus nehmen.

Hi,

bzgl. der Plugins: Das sollte sich ja schon aus dem Einsatzzweck ergeben. Gefragt ist halt alles, was in Listing / Filterung / Suche eingreift, w├╝rde ich erstmal denken. Habt ihr da was?

Ansonsten m├╝sste man echt nochmal ├╝ber die Dimensionierung des Datenbanksystems nachdenken. Es ist schon so, dass die Abfragen nicht ganz trivial zu berechnen sind - das Ausma├č, das du beschreibst, erscheint mir aber doch etwas heftig. Da gibt es hier ein paar Tipps:┬áShopware 5 performance guide for system administrators

Besonders die innodb_buffer_pool_size sollte passend gesetzt sein.

Besten Gru├č,

Daniel

Hey,

das einzige Plugin, welches da in Frage kommt ist denke ich dieses: http://store.shopware.com/dreisc01025/endlos-scrollen-mit-infinite-scroll.html

Da wir noch Shopware 5.1.6 mit einem Shopware 4 Template laufen haben, ben├Âtigen wir das Plugin noch und augenscheinlich funktioniert es auch korrekt. Zumindest werden die Produkte so nachgeladen wie unter Shopware 4.

 

Bei der Datenbank m├╝sste ich dann selber einmal nachfragen. Die Datenbank liegt bei Mittwald (MySQL 5.6 - SSD). Sollte ja eigentlich recht schnell sein. Bin jetzt aber davon ausgegangen, dass das bei Mittwald schon alles f├╝r Showpare optimiert ist, wenn man das System ├╝ber die Agenturtoolbox laufen l├Ąsst.