Ich habe heute an dem Problem weiter geforscht und wir haben etabliert, dass die Ursache nicht der Quelltext des betreffenden Diamond-Collectors sein kann.

Auf allen betroffenen Kisten habe ich dann gesehen, daß die entsprechenden Queries gegen Performance-Schema ein

CODE:mysql> select * from performance_schema.threads;

Empty set (0.01 sec)

zurück liefern.

Weitere Untersuchung stellt heraus: P_S ist aber an. Jedoch:

CODE:mysql> select * from performance_schema.setup_instruments;

Empty set (0.03 sec)

mysql> select * from performance_schema.setup_timers;

Empty set (0.01 sec)

mysql> select * from performance_schema.setup_consumers;

Empty set (0.02 sec)

…

Wir generieren eine neue Art von Materialized View mit dem bekannten Generator-Setup:

Materialized View-Generator

Das neue Setup unterscheidet sich in der Logik von denen, die wir bisher verwendet haben, und so kommt es beim Testlauf zu einem ungewöhnlichen und unerwarteten Ereignis:

Um 14:30: Ein Gigabit-Netzwerk mit 125 MB/sec ausgelastet.

Bei einem Probelauf gehen die Alarme los, weil der Gigabit-Netzwerkstrang zur Datenbank mit 125 MB/sec (Ein Gigabit/sec) vollständig ausgelastet ist. Wie man sehen kann, ist die Datenbank zu diesem Zeitpunkt nicht besonders beschäftigt:

Statements/sec - die Datenbank nimmt kaum die Hände aus den Hosentaschen.

Auch auf dem Binlog ist nichts besonderes zu …

"Hey, Kris! Wir haben zwischen 16:20 und 17:20 CEST einen Lasttest durchgeführt und kurz vor 17:00 Uhr einen unerklärlichen Spike und einen Leistungsabfall festgestellt. Kannst Du mal gucken?"

Klar kann ich. Wo ich arbeite machen wir etwas, das wir Testing in Production nennen.

Für Lasttests bedeutet das, daß wir einzelne Systeme im Loadbalancer so lange relativ höher gewichten bis sie Probleme bekommen und umfallen. Zur Kontrolle legen wir mit Apache Siege eine Reihe von Sensor-Requests in das zu testende System, nicht zur Lastgenerierung, sondern um zu sehen, wann die Latenz nach oben geht, also um Sättigung des zu testenden Systems zu bemerken bevor es Fehler zu generieren beginnt.

Wenn wir nahe an den Sättigungspunkt gelangen, erhöhen wir die Last in sehr winzigen Schritten, bis wir tatsächlich Systemversagen zu …

Als bekennender Linux-Fanboy habe ich eigentlich wenig Grund auf anderer Leute Betriebssysteme neidisch zu sein. Eine Ausnahme ist Solaris DTrace (PDF).

DTrace ist eine Kernel-Facility, die Programme dynamisch instrumentieren ("belauschen", aber auch "beeinflussen") kann. Dynamisch bedeutet in diesem Fall, daß die notwendigen Instrumentierungen (Breakpoints et al) nicht Teil des Programmes sind, sondern nur bei Bedarf eingebracht werden - DTrace beeinflußt die Default-Performance von Programmen also nicht, denn es ist im Normalfall nicht da. DTrace ist auch ein Sysadmin-Programm, mit dem man solche DTrace-Events abgreifen und auswerten kann. Dazu schreibt man Auswerte-Programme in einer Programmiersprache ("D"), die Events verwerfen, sortieren oder aggregieren kann, oder im Destructive Mode in die Ergebnisse von Aufrufen im Kernel oder im …