Als ich gestern gegen Nachmittag auf meinem Blog vorbeischaute, fiel mir auf, dass es alles andere als rund lief. Die Ausgabe von top förderte eine durchgehende hohe Last von über 3 zu Tage, obwohl meine Prozesse die CPU langweilten – so ist das nun mal bei Shared-V-Servern 🙁
Es kam aber noch besser, als wenige Minuten später meine Maschine völlig vom Netz ging und nicht mehr zu erreichen war, auch das „Rescue“-System war offline.
Nach einiger Zeit habe ich vom Support erfahren, dass mein V-Server die CPU voll ausgelastet hätte, und deswegen deaktiviert wurde. Ich konnte nach einigem Hin und Her den Mitarbeiter überzeugen, dass der Ursprung des Übels nicht von meiner Kiste ausgeht. Nach dem Neustart des Systems sollte ich die Aktivitäten des Servers überwachen, was ich auch tat. Ich fand nix auffallendes.
Die ganze Aufregung habe ich dann genutzt um auf der Maschine etwas aufzuräumen. Zunächst habe ich begonnen alte Clamav und Spamassassin-Installationen eines alten Mail-Systems zu entfernen, im Anschluss war ein apt-get upgrade meines Debiansystems fällig. Das förderte auch etliche Pakete zu Tage, welche ein Update erfahren durften.
Die Bloggsoftware WordPress hat durch den Apache2-Webserver, seine PHP-Dynamik und der MySQL-Datenbank als Backend hohe Systemanforderungen, diese zu optimieren war also der nächste logische Schritt.
Die Standardeinstellung für den Apache2 sieht nur 5 – 10 Prozesse für jeden möglichen Request vor, dies kann bei wenigen gleichzeitigen Seitenabrufen schon zu merklichen Verzögerungen führen. Die Erhöhung der „Request“-Prozesse ist daher sinnvoll:
MinSpareServers 15
MaxSpareServers 30
Für den MySQL-Server sollten unbedingt der Query-Cache um häufige Abfragen zwischenzuspeichern und zur Diagnose log_slow_queries eingeschaltet werden:
query_cache_size = 16M
log_slow_queries = /var/log/mysql/mysql-slow.log
long_query_time = 5
Zu guter Letzt wäre da noch PHP zu optimieren – am Besten gelingt dies durch den Einsatz von eAccelerator , einem Apache-Modul, das zur Laufzeit Skripte kompiliert, zwischenspeichert und so eine X-Fach höhere Ausführungsgeschwindigkeit erreicht.
Die Optimierung ist deutlich spürbar, und sollte auch in näherer Zukunft ausreichend sein – solange der Nachbar nicht grade wieder seine Videos rendert 🙂