Eigentlich wollte ich mir diesen Test für nach dem Server-Umzug aufheben, aber wenn der alte vServer bereits beim Ziehen des Backups zu sportlichen Aktivitäten auffordert und zum Komprimieren von 3 GB Nutzerdaten geschlagene 2 Stunden benötigt, dann ruft dass gerade zu danach, dass man die Komprimierung der andren Datenverzeichnisse parallelisiert.
Gesagt, getan. Wie hoch bekommt man auf einem vServer die Last durch einfches Komprimieren eines Backups? Die Grundauslastung des Servers liegt bei etwa 0.20 bis 0.50 und laut /proc/cpuinfo werden mir von dem QuadCore-Opteron des Hostsystems 220MHz mit einem Core zur Verfügung gestellt (heißt hochgerechnet, dass der Anbieter da wahrscheinlich um die 50 vServer auf einer Maschine hostet … aber gut).
Also gut. Auf geht’s: /home wird normal mit
tar -czf ziel.tar.gz /quelle
gepackt … die CPU des Systems beschäftigt sich alle paar Sekunden ein wenig mit dem Arbeiten und schläft ansonsten. Da ist also noch Spielraum für das Backup. Nehmen wir /var dazu. Gleiche Vorgehensweise, nur auf einer weiteren Screen-Konsole. Auch hier ist er nur sporadisch am Arbeiten, was also andeutet, dass noch Platz für mehr Backup-Operationen sind. /etc und /usr noch ergänzt und siehe da: die CPU hat nun auch etwas zu tun. Nebenbei liefen die normalen Services normal weiter (Brauchte hauptsächlich ein Backup zum Vorbereiten der Installation auf dem neuen Server. das eigentliche Kopieren der Daten wird dann bei abgeschalteten Diensten geschehen).
Und nun: was kam dabei raus: Mit 4 mal Backup komprimieren und normal laufenden Hintergrunddiensten (die wahrscheinlich etwas träger wie normal reagiert haben dürften), kam der Server auf eine Durchschnittslast von sportlichen 9.27 im 15 Minuten-Durchschnitt. Eindeutig zu viel, um insgesamt etwa 4,5 GB Daten zu komprimieren, was geschlagene zweieinhalb Stunden benötigt hat.
Aber gut, war in gewisser Hinsicht auch etwas verzerrend, gerade aber, wenn man solche Werde liest, auch wieder nicht:
# time tar -czf home.tar.gz /home tar: Entferne führende „/“ von Elementnamen real 104m41.106s user 4m53.859s sys 0m22.261s
Die anderen Kompressionsvorgänge sahen nicht wesentlich anders aus von den Zahlenverhältnissen …
Dafür ging die Server-zu-Server-Kopie anschließend richtig flott von der Hand (mit atemberaubenden 800 KB\s). Selbst von meiner DSL-Leitung bin ich besseres gewohnt!
Du kannst hallt (noch) nicht alles haben kleiner man.
Kommentar by neo — 03.03.2009 @ 20:18:18
[…] dem ich ja bereits im Vorfeld des Umzuges gezeigt habe, wie man einen vServer an die Kotzgrenze treibt, war ich regelrecht positiv davon überrascht, als auf der neuen Hardware Seitenaufrufe mindestens […]
Pingback by BenBE’s humble thoughts » Serverumzug: Änderungen unter der Haube — 08.03.2009 @ 19:07:59