Probleme mit der Load durch MySQL - Ausgabe des MySQL-Status

Probleme mit der Load eines Servers, die auf den MySQL Dienst schließen lassen, lassen sich nicht unbedingt in den Queries in MySQL sehen, die man über die MySQL Prozessliste abruft.

Du siehst z.B. via ps -auxf dass der SQL 300% CPU fordert, aber die SQL-Prozessliste ist überschaubar. Leider trügt Dich der Schein, denn die SQL Prozessliste kann Dir immer nur eine Momentaufnahme liefern.

Um zu sehen, womit der Server, oftmals in Sekundenbruchteilen, beschäftigt ist, bietet es sich an, die Ausgabe des MySQL-Status zu checken:

- Logge Dich hierzu via SSH als User "root" auf dem betreffenden Server ein und nutze fologenden Befehl

mysqladmin -u admin -p`cat /etc/psa/.psa.shadow` -i2 status

• Dieser Befehl gibt im 2 Sekunden Rhytmus (-i2) den MySQL Status aus. Beende die Augabe mit Strg+C wenn Du genügend Daten gesammelt hast.

- Du bekommst dann beispielsweise folgende Ausgabe

Uptime: 548218 Threads: 5 Questions: 333058910 Slow queries: 0 Opens: 5127974 Flush tables: 1 Open tables: 10240 Queries per second avg: 607.530

Uptime: 548220 Threads: 12 Questions: 333061816 Slow queries: 0 Opens: 5128132 Flush tables: 1 Open tables: 10240 Queries per second avg: 607.533

Uptime: 548222 Threads: 9 Questions: 333064522 Slow queries: 0 Opens: 5128226 Flush tables: 1 Open tables: 10240 Queries per second avg: 607.535

• Die Uptime sind die Sekunden seit dem Start des SQL-Services.
  
• Die Questions sind die SQL-Queries seit diesem Zeitpunkt.
  
• Durch das Bilden der Differenz aus zwei "Questions"-Werten aus zwei Statusausgaben, findest Du die Anzahl der Queries, die tatsächlich verarbeitet wurden.
  

- Was machst Du nun mit diesen Werten, was sagen Sie Dir?

Wie Du im obigen Beispiel siehst, sind innerhalb von 4 Sekunden ~5.500 Queries pro Sekunde durchgeführt worden (333064522 - 333058910).

Dieser Wert ist einem unserer momentan sehr unter Beschuss stehenden shared Server mit nicht einmal Vollbelegung entnommen! (40 Abonnements)

Fazit: 5.500 Queries pro Sekunde entspricht keiner Lebensrealität, die mit unseren Shared Servern dauerhaft oder regelmäßig ausdauernd abgebildet werden kann. Hier dürfte ein PHP-Script sehr sehr viele Anfragen abfeuern, die kaum notwendig sind. Hier kommt am ehesten ein von Kunden eingesetztes System in Betracht. Vermutung nach eingehenden Checks derjenigen Kunden, die stets zuerst betroffen sind und exakt die gleiche Software in der gleichen Version nutzen, lässt auf Gambio GX4.2.0 und 4.2.0.1 schließen. (In den error_log Dateien der Kunden finden sich entsprechend viele PHP-Errors)
Ich habe mich mit Dogado kurz geschlossen. Alfahosting hat sich für Gambio nie recht durchgesetzt, so dass wir hier einen exzellenten Vergleich einer Shared Maschine ohne Gambio machen konnten. Absolute Spitze (und die packen Ihre Server sehr viel voller als wir), sind dort mal 900 Queries pro Sekunde.

Probleme mit der Load und der Performace dürften vor allem in diesem Bereich entstehen.

Ein Workaround dürfte im Moment am ehesten darin bestehen, den Kunden auf ein Update zu GX4.2.1 zu bewegen. Laut Gambio wurden hier einige Schwachstellen in der Verarbeitung des Frontend Style Edit geschlossen.