IO-Killer
13. April 2010
Wir hatten hier einen Kunden, der es geschafft hat, mit einer zweistelligen Anzahl von Script-Aufrufen am Tag ein echter IO-Killer zu werden.
Wie er das gemacht hat? Mit seiner php_error.log.
Ja, wirklich. In einem seiner Scripte ist ein Loop, die php_error.log wuchs in nur einer Stunde auf 116 MB. Es werden megabytegroße Brocken bei jedem Script-Aufruf via NFS zu den Fileservern übertragen.
Nein das war es noch nicht. Man versuche sich nur einmal vorzustellen, was passiert, wenn der Surfer bei seinem Browser den Reload-Button drückt und die Datei vom anderen Prozess ja noch gelockt ist, weil der megabyteweise Fehlermeldungen schreiben will, bis er durch die Laufzeitbeschränkungen gekillt wird. So etwas kann sich wunderschön hochschaukeln. Hossa!
Wir bauen uns jetzt ein neues Accounting-Tool. Das Accounting von FreeBSD mit sa ist ja ganz nett, aber zum Erkennen von Übeltätern bei kurzen Lastspitzen von IO auf einem Load Balanced Cluster völlig ungeeignet. Was wir brauchen, ist eine Auswertung für frei wählbare Intervalle und verschiedene Kriterien (CPU, Anzahl der Aufrufe, Disk-IO und CPU Storage Integral) auf allen Servern insgesamt und nicht eine Gesamt-Auswertung bis zum letzten Rotation der Accounting-Datenbank auf einzelnen Webservern. Scheint auf den ersten Blick ziemlich einfach umzusetzen zu sein, wir rotieren einfach jede Minute und schreiben die absoluten Accounting-Daten in eine zentrale MySQL-Datenbank. Und die kann man ja dann ganz einfach nach Belieben abfragen, sortieren oder sogar zusammengefasste Verlaufskurven für einzelne Kunden auf dem gesamten Cluster erstellen.
