Antwort #17 am: 28. Januar 2015, 12:36:01
Hallo ihr Guten,
Mir fallen da 2 Sachen ins Auge:
Ein weiterer Dienst füttert im Hintergrund die Datenbank regelmäßig mit neuen Daten, den haben wir auch schon optimiert.
und
Zu den 14 Sekunden muss ich auch sagen, dass dies nur die Startseite betraf, wo alle Neuheiten (bis zu 1.000 Artikel) angezeigt wurden. Einzelne Kategorie- und Detailseiten mit weniger Artikeln waren schneller, doch teilweise auch bis zu 4 Sekunden, was deutlich zu lange ist.
1. Bist Du sicher, dass der Hintergrund-Dienst nicht die offenen DB-Verbindungen erzeugt? Führt der u. U. zu Datensatzsperren, welche sich natürlich auf den Shop auswirken?
Der Hintergrund-Dienst schließt seine Verbindung(en) zur Datenbank wieder. War ein Teil der Optimierung.
An die Sperren hab ich noch gar nicht gedacht, sehr guter Hinweis. War mir im slow_query.log bisher noch gar nicht aufgefallen ist, bei mehr als der Hälfte steht "State: Waiting for table level lock". Muss ich mich noch mal genauer mit befassen.
2. Nur neue Artikel? Wie werden die rausgesucht? Fehlt da am Ende ein Index?
Anhand des 'products_date_available' innerhalb der letzten 52 Tage. Indizes gibt es für 'products_id', 'products_date_added' und 'products_date_available'.
Wir können nichts explizites als Ursache erkennen. Einziger Anhaltspunkt den wir aktuell haben, ist dass sobald von den Jungs im Rechenzentrum der MySQL-Dienst neu gestartet wurde beziehungsweise manuell die offenen Anfragen gekillt werden alles vergleichsweise flott läuft.
Heißt das, dass alle eure Querys in unter 0.05s durchgehen?
Alles darüber sollte die Ausnahme sein, z.B. die Suche.
Kann ich leider keine genaue Auskunft drüber geben da mir bisher vom Rechenzentrum nur ein Log der langsamen Queries zur Verfügung gestellt wurde.
Was auch noch eine Möglichkeit wäre, gerade wenn auf der Startseite schon 1000 Produkte angezeigt werden, das Query umzubauen. Statt über eine while-Schleife immer wieder die einzelnen products_id abzufragen, die WHERE-Klausel mit products_id IN () zu beschelunigen.
Sollten wir keine bessere Lösung finden würden wir dies mittels AJAX lösen, da die ca. 1.000 neuen Artikel eh in Blöcken anhand des Labels/Kategorie zusammen gefasst sind. Werde diese Lösung aber mla im Hinterkopf behalten.
Je länger ich darüber nachdenke, glaube ich dass das nicht mal unbedingt an Abfragen, Indizes oder Shop liegt, sonder eher an der Config von Apache und mysql.
Was ist immer gleich, wenn die Zugriffe langsam werden? Es gibt offene Verbindungen. Sobald die aber gekillt werden ist es wieder flott. Was ich mir vorstellen könnte, ist das im Hintergrund die max. Anzahl an Verbindungen erreicht ist und der Server wartet bis der Garbage-Collector sich bequemt mal wieder eine Verbindung zu schließen. Manchmal hatl nicht rechtzeitig und es timeouted.
Wenn ich das richtig im Kopf habe, dann gibt es Verbindungslimits für mysql, httpd und max open files. wenn eine davon zu niedrig ist, dann blockt das den Rest. Aber für sowas gibt es ja Profi-Apachen.
Klingt auch alles logisch. Wie bereits gesagt handelt es sich um einen managed Cloud-Server. Ich habe dieses nicht ausgesucht und hatte auch keinen Einfluss bei der Entscheidung wo und welcher Server mit welchem Dienst verwendet wird. Aber wo kommen wir denn hin wenn man sich nicht mal auf die "Profis" im RZ verlassen kann?
Wir hatten mal ähnliche Probleme und eine Ursache waren die Session Einstellungen, liegen bei dir die Sessions in der Datenbank?
Ja, die Sessions liegen in der Datenbank. Werde mal mit meinem Ansprechpartner klären ob das unbedingt relevant ist.
Das Verbindungen nicht geschlossen werden ist nichts neues. Der Garbage Collector wird auf aktuellen Debian basierenden Systemen jeweils 9/39 nach ausgeführt und bis dahin verweilen alle Verbindungen als offen, es sei denn der Garbage Collector von MySQL (Default: wait_timeout = 28800) greift ein. Da das Problem seit der "1&1 Administratoren Invasion" anno 2005 im alten Projektforum bekannt ist, gibt es auf unseren Servern in der
/etc/mysql/my.cnf
die Einstellung:
wait_timeout = 30
Da habe ich leider keinen Zugang. Werde es aber den entsprechenden Personen weiter leiten. Vielen Dank für diesen Hinweis.
Und auch an alle anderen ein dickes Dankeschön für die Beteiligung an unserem Problem. Ihr scheibt hier schneller als ich antworten kann, daher ist dieser Post etwas länger geworden.
Besten Gruß,
Timo
