Gelöst MYSQL hat eine sehr hohe CPU Last

[Stephs182]

Hallo zusammen,
vielleicht kann mir jemand bei dem Problem Aufschluss geben. Wir sind in der letzten Woche vom Shop 3.20 auf den aktuellen Shop 4.05 Build 3 umgestiegen. Vorher war unsere Last im Server unauffällig. Seit dem Umstieg geht uns die CPU Last im MYSQL durch die Decke. Grundlast liegt bei 30%-40% zu Spitzenzeiten geht es auch mal gen 100%.

Ich habe rausbekommen, dass es die Abfrage zum Xsell ist, die das ganze hochtreibt in dem in den MYSQL-Slow- Log geschaut habe.

# Query_time: 9.370473  Lock_time: 0.000400 Rows_sent: 4  Rows_examined: 387157
SET timestamp=1505028691;
SELECT 3883 AS kArtikel,
                        IF(tartikel.kVaterArtikel = 0, txsellkauf.kXSellArtikel, tartikel.kVaterArtikel) AS kXSellArtikel,
                        SUM(txsellkauf.nAnzahl) nAnzahl
                    FROM txsellkauf
                    JOIN tartikel ON tartikel.kArtikel = txsellkauf.kXSellArtikel
                    WHERE (txsellkauf.kArtikel IN (
                            SELECT tartikel.kArtikel
                            FROM tartikel
                            WHERE tartikel.kVaterArtikel = 3883
                        ) OR txsellkauf.kArtikel = 3883)
                        AND IF(tartikel.kVaterArtikel = 0, txsellkauf.kXSellArtikel, tartikel.kVaterArtikel) != 3883
                    GROUP BY 1, 2
                    ORDER BY SUM(txsellkauf.nAnzahl) DESC, rand()
                    LIMIT 4;

Ist die Abfrage die uns beschäftigt. (Hier ein Spitzenreiter mit über 9Sek.)
Unsere Datenbank ist mittlerweile über 400 MB groß.

Ich habe also die Performance geprüft indem ich das X-Sell in den Artikeldetails ausgeschaltet habe und dann war alles wieder ruhig. Aber das kann nicht die Lösung sein.

Nun dachte ich, dass bei dem Upgrade vielleicht ein Index nicht richtig in der Datenbank steht. Also habe ich dies mit einer frischen 4.05er Datenbank verglichen in den Tabellen tartikel und txsellkauf = Alles ok.

Habt ihr vielleicht einen Ansatzt, was ich noch machen kann oder kennt jemand diese Problematik? Wir betreiben übrigends einen eigenen Server im Rechenzentrum auf dem der Shop liegt, also die Hardware sollte reichen, zumal sie zuvor sich ja auch eher gelangweilt hat.

Viele Grüße
Stephan

 

[css-umsetzung]

Habt ihr einen aktiven cache?
Redis ist ja hier die erste Wahl, insbesondere weil ihr einen eigenen Server habt.

Bei den Kunden, bei denen ich auch die Server in der Hand habe, liegt die MySQL last im normalen Bereich, da sind mir bisher noch keine wirklich extreme Performance Probleme aufgefallen.

Von welcher Artikel Anzahl sprechen wir hier.

 

[Stephs182]

Vielen Dank für die Antwort.
Wir haben zunächst keinen Cache genutzt. Testweise die File Cache Methode, leider ohne Erfolg. Ich habe nun mal den Redis installiert und seit einer Stunde zu laufen. Die CPU ging zwar zunächst runter, doch nun scheint es wieder hoch zu gehen, zumindest leicht.

Wie lange lasst ihr die Lifetime vom Cache? Ich habe jetzt mal ne halbe Stunde gesetzt.

Wir haben knapp 10t Artikel wobei nur etwa 1500 Artikel Väter sind.

 

[css-umsetzung]

Der cache ist standardmäßig ein Tag, warum wollt Ihr den jede halbe Stunde erneuern?
10000 Artikel ist NIX

 

[Stephs182]

Ja klar ist das nicht so viel... deshalb verstehe ich die Reaktion auch nicht. Das sollte der Server problemlos wegstecken... auch weil er es ja im Shop3 auch gekonnt hat.

Redis läuft nun 2h ... die MySQL-CPU Last ist nun nicht mehr so sprunghaft, aber immernoch über 30%.

 

[FPrüfer]

Hallo,

...Habt ihr vielleicht einen Ansatzt, was ich noch machen kann oder kennt jemand diese Problematik?

Kannst du mal ein EXPLAIN auf die Problematische Abfrage machen und das Ergebnis posten!? Versuch auch alternativ mal die betroffenen Tabellen einem ANALYZE zu unterziehen. Also auf der DB ein

ANALYZE TABLE tartikel;
ANALYZE TABLE txsellkauf;

absetzen.

 

[Stephs182]

Vielen Dank für deinen Hinweis @FPrüfer . Ich habe das mal versucht. Grundsätzlich kommt bei einer Simulation das Ergebnis. Is ja ne "Select Abfrage". Das passt auch. Analyze brachte jeweils ein ok.

Was mich wundert, gestern abend um 20 Uhr habe ich den Cache installiert, wie von css-umsetzung geraten. Gegen 0 Uhr hat sich das SQL beruhigt und läuft seit dem sehr ruhig, wie wir es gern hätten. In der Anlage mal die Diagramme... Am Dienstag (5.9.) war das Update von Shop 3 auf Shop 4. Gut zu erkennen... in der zweiten Grafik sieht man die letzten 24h... Baut der Cache sich solange auf?

Die MySQL Slow Log ist heute auch wieder weitestgehend leer geblieben.

 

[Stephs182]

Hier ist noch die Auswertung bei dem Befehl mit "Messen" im Phpmyadmin:

 

[css-umsetzung]

Es ist ja nicht so das der cache eingeschaltet wird und schwups ist er da.
Der Cache baut sich langsam aber stetig, mit jedem neuen Aufruf auf, es kann also sein das eine Seite im Shop oder ein Artikellisting noch nicht im cache ist weil es einfach noch nicht aufgerufen wurde.

Je länger der Shop also läuft umso besser sollte die Performance werden, auch die indexe bauen sich ja langsam auf und sind nicht schwups auf einmal da (behaupte ich, bin da ziemlich sicher in der Aussage)
Dadurch das die einzelnen caches zu unterschiedlichen Zeiten aufgebaut werden, werden Sie auch nicht alle auf einmal erneuert, was ebenfalls der Performance zugute kommt.

 

[Stephs182]

Ich wollte nochmal Feedback geben, dass die Performance sich deutlich verbessert hat und der Shop nun besser läuft. Dadurch hat man auch wieder einen Schupp bei der Conversion Rate gespürt. Ich denke das Thema kann nun geschlossen werden.

 

[ag-websolutions.de]

-- closed