Vor einer Woche staunte ich nicht schlecht als ich tagsüber den Server routinemäßig kontrollierte. Der Serverload lag bei 1.0 (das entspricht ungefähr der Auslastung eines Kerns, wobei eigentlich noch der I/O Wert zu beachten ist). Ein kurzer Blick in die Prozessliste förderte bzip2 als „Übeltäter“ zu Tage. Da konnte nur der Backupprozess in Frage kommen, doch eigentlich sollte dieser zu jener Tageszeit schon längst beendet worden sein. Wieso lief bzip2 also nicht rund? Eine schnelle Ursache konnte ich nicht finden und habe das ganze erst einmal weiter beobachtet. Doch auch in den Folgenächten besserte sich die Situation nicht. Es ging also ins Detail. Nebenbei untersuchte ich gleichzeitig Möglichkeiten, um den Backupprozess zu beschleunigen. Die weitere Ursachenforschung brachte letztendlich das wahre „Problem“ zum Vorschein: die Größe der zu sicherenden Daten belief sich auf über 250 GB – da konnte etwas nicht stimmen! Und siehe da, das Problem war ein hausgemachtes. Ich hatte bei der letzten Migration auf die neusten Softwareversionen der LAMP-Umgebung die MySQL Replikationslogs in ein zu sicherendes Verzeichnis mitverschoben und diese hatten nunmal einen Umfang von mehr 200 GB (was ohnehin unnütz ist, aber so leert sich nun auch ein weiterer Punkt auf der ToDo Liste..). Nach der Entfernung dieser Dateien gestaltete sich der Backupprozess auch wieder ähnlich flott wie zuvor. Die parallelen Optimierungsarbeiten am Backupscript hatten auch ihre gute Seite: bzip2 wird fortan durch pbzip2 ersetzt, das nun alle Kerne nutzt.
