Optimierungsorgie Teil 2

Wie vorhin schon mal erwähnt, habe ich in den letzten zwei Wochen einige Optimierungsarbeiten an unserer MySQL-Datenbank vorgenommen.

Unsinn hoch Drei – Probierphase

Interessanterweise waren viele der Maßnahmen völlig für den Eimer – das habe ich aber erst seeeeehr spät festgestellt.

Beispiele

  • mysqltuner.pl immer wieder laufen lassen, der mir stoisch eine Erhöhung der tmp_table_size (und damit auch max_heap_table_size) empfiehlt.
  • Empfehlung, den innodb_buffer_pool_size auf 80% des installierten Arbeitsspeichers in den Wind geschlagen (20% für PHP? Nie im Leben) und gegen 50 und 60% getauscht.
  • query_cache an – und wieder aus – und wieder an – und wieder aus – man ist sich da im Expertennetz nicht einig: Einige verteufeln, andere bringen wieder den Standardspruch „your milage may vary“.
  • diverse Buffer hoch und wieder runter – meistens hoch

Irgendwann war dann die Datenbank so aufgeblasen, dass nur noch 2 oder 3 PHP-Instanzen ausführbar gewesen wären, wenn meine NAS mich das denn hätte so stark begrenzen lassen. Da ich für php mal sportlich

memory_limit = 300M

vorgesehen hatte (man weiß ja, WordPress mag es gerne ausufernd – falsch… aber das wusste ich da noch nicht) und in der Tat sich die PHP-Prozesse gerne mal so um die 200M reingetan haben, war irgendwann auch für den Mathe-Versager Mirko klar: Das passt alles nicht rein.

Hier liefen also ein halbes Dutzend PHP-Prozesse, eine Datenbank, mit der ich vermutlich die Deutsche Bank hätte versorgen können, ein OpCode-Cache, in den sämtlich 15.000 PHP Scripte reingepasst haben und noch diverse andere Dinge, die zusammen vermutlich so 12 bis 16GB Arbeitsspeicher hätten haben wollen – und ein paar lustige CPU-Kerne gleich noch oben drauf.

Katastrophenalarm – Wir werden geDDOSed.

Eines Morgens so gegen 11 dann der wahrgewordene Alptraum: Unser Webserver wird angegriffen!!!1eins

Wir verzeichnen dutzende Anfragen gleichzeitig, alle landen in getrennten PHP-Prozessen (soso, plötzlich können da auch 20 Prozesse gespawned werden, obwohl die Begrenzung viel niedriger lag). Die Datenbank braucht für Ömmelsabfragen plötzlich 70 Sekunden und mehr (vorher: Bruchteile einer Sekunde!).

Also ich per SSH in den Server (wie praktisch, dass ich auf dem Server ein renice-Script laufen habe, dass mir alle paar Minuten die SSH- und anderen kritischen Prozesse auf bequemere Prioritäten schiebt) und mit sehr viel Geduld im Minutenbereich die Datenbank freundlich um Beendigung gebeten. Daraufhin dann auch gleich den Webserver (der sowieso ohne Datenbank lustige Ausfälle zeigt bis hin zum Verzweiflungsselbstmord).

Puh. Intrusion Prevention auf die NAS gebügelt, irgendwer muss mal den Türsteher machen (Firewall wäre naheliegend, aber mit dem Käse läuft dann grad mal gar nix mehr so richtig – auch eine Möglichkeit Ruhe zu haben…). Die wiederum lutscht sich auch knapp 600 bis 800MB Arbeitsspeicher, wovon wir bekanntlich eigentlich schon im Zehnerpotenzbereich zu wenig haben.

Dann war Ruhe.

Nächster Tag – geht schon wieder los!

Am nächsten Morgen, wieder so gegen 11 – der nächste Angriff.

Da ich zwei Tage vorher eine Hoax-Mail mit der Bitte um Überweisung eines frechen Betrags erhalten habe mit der Ankündigung mir im Gegenzug das Geschäft dann nicht zu zerstören, habe ich langsam bisschen Muffensausen bekommen. Ich dachte „ok, das war kein Hoax, die A-Geigen meinen das so“.

Also wieder gleiches Programm. Mit Geduld und Spucke in die NAS und alles totgelegt. Auch gleich mal einen Neustart der NAS gemacht (nach wochenlanger Uptime… ich bekam feuchte Augen, echt) und die letzten Sicherheitsupdates installiert.

Aber dann hatte ich einen Idee… zwei Tage hintereinander, zwei mal praktisch dieselbe Uhrzeit… das klingt doch verdächtig nach „Cron“.

cron um 11
cron um 11

Und was sehe ich da? Da läuft ein Backupscript von mir höchstpersönlich.

Was macht das… isset Schuld?

ya-backup
ya-backup

Naja. Also…. wenn das jetzt den Server derartig überlastet, dann weiß ich auch nicht.

Dann fiel mir ein, was ich die Tage davor gemacht habe.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.