RackBlogger

Am Wochenende schrie eine MySQL4-Datenbank über Nagios um Hilfe: die Server-Last war auf knapp über 10 angestiegen. Also - kurz per SSH auf den Server und Problem lokalisiert: mit “show processlist” zeigt MySQL eine Liste aller aktiven Prozesse (klingt irgendwie einleuchtend)

Nun, in dieser Liste befanden sich etwa 15 Instanzen der selben Abfrage: select count(*) from xxx where month(date)=5 and year(date)=1997 and textfeld = ‘yyy’; (Spaltennamen geändert)

Also habe ich mir die Tabelle mal näher angesehen. Darin sind etwas über 200.000 Einträge verzeichnet - aber kein Index. Das heißt, die o.g. Abfrage durchsucht jedesmal alle 214.361 Datensätze (nennt sich dann “Full Table Scan”). Ganz leicht lässt sich das sehen, wenn man sich den Ausführungsplan für den SQL-Befehl ausgeben lässt (einfach ein DESCRIBE vor das SELECT setzen).

Ich war dann mal so frei, einen Index über die Spalte mit den Textschlüsseln zu erzeugen. Ergebnis: die Abfrage kann komplett über den Index bearbeitet werden - es ist nur noch ein Zugriff auf die Datensätze notwendig (für den Zieldatensatz). Das entspricht einer Optimierung von 214361:1

Der Kunde freute sich dann auch über meine ausführliche Mail zu dem Thema:

sorry und gleichzeitig vielen Dank für Ihre Erklärung.

Was wäre ich nur ohne Sie. Sollte mir vielleicht irgendwann mal etwas professionelle Unterstützung suchen.

Ach - dafür sind wir doch gerne da. Der vom Kunden angebotene Dienst wächst aber auch erheblich - ich vermute mal dass zum Zeitpunkt der Erzeugung o.g. Tabelle nicht abzusehen war, dass diese mal so anwächst…

Vorhin traf eine KK-Anfrage für eine .de-Domain ein, deren Kunden wir nicht erreichen können (die Postanschrift ist inzwischen ungültig, eine aktuelle Mailadresse oder Telefonnummer liegt uns auch nicht vor) und bei dem die letzten zwei Lastschriften auch geplatzt sind.

Naja, nun lassen wir uns mal vom KK-Antragsteller die Authorisierung des Domaininhabers schicken, geben die Domain dann wunschgemäß frei und schicken die Rechnungen gleich hinterher…

Beim fröhlichen Patchwochenende ist mir wieder aufgefallen, dass Debian Linux ein Problem damit hat, wenn man für das /tmp-Verzeichnis das noexec-Flag setzt. Dieses sorgt dafür, dass keine Dateien in diesem Verzeichnis ausgeführt werden dürfen - eine durchaus gängige Sicherheitsmaßnahme gegen Rootkits & Co.

Manche Pakete entpacken allerdings das eine oder andere Script ins /tmp-Verzeichnis und wollen es dort ausführen, was dann zu hässlichen Fehlermeldungen bei APT führt.

Einziges Workaround: zum Beginn einer Wartung das /tmp-Verzeichnis ohne noexec-Flag remounten, dann Software aktualisieren, dann wieder mit noexec mounten…

Keine Ahnung was das für eine Sprache ist, in der folgender Spam formuliert ist:

Ich glaube sogar, dass das nicht einmal russisch ist. Und was will diese Dame da?

Was mich aber mehr schockiert als der Blick der Dame ist die Tatsache, dass der Spamfilter dieser Mail kaum Aufmerksamkeit geschenkt hat. Sie ist - im Gegensatz zum meisten Spam - sauber programmiert und geschickt versendet worden; von einer “normalen” Mail also praktisch nicht zu unterscheiden.

Sobald jeglicher Spam diese Qualität erreicht hat, können wir die Mailboxen dicht machen.

Ein etwas größeres Tuning an den Mailman-Mailinglisten ist nun auch (fast) abgeschlossen. Wenn nun alles stabil in der Testumgebung läuft, werden die bestehenden Mailinglisten in Kürze umgezogen.
Es sei nur so viel gesagt: Mailman lässt sich auch prima in Exim integrieren (wer braucht schon Postfix), virtuelles Hosting mit gleichnamigen Mailinglisten in unterschiedlichen Domains ist nur unmöglich solange man nicht den Code patcht und nun sind auch alle Prozesse automatisierbar.