Performaceeinbruch bei dump

K

kruemelmonster

Keksfreund
Hallo zusammen!

Folgendes Szenario: System FreeBSD 6.1 mit patches auf Athlon 64/3200+. Das FS einer 250G-Platte, (UFS, GBDE), soll auf eine 300G-Platte (UFS, GELI) gedumpt werden. Prozessor ist pratisch ständig auf Vollast (klar, vom Ent- und Verschlüsseln), keine Kompression. Dateien sind von 2-3 GB großen Archiven bis zu HTML-Bäumen mit tausenden Mini-Dateien verteilt, die meisten dürften aber zwischen 2 und 7 MB liegen. Während des Backup liefen keine weiteren Programme (außer ssh und gelegentlich top/gstat), während dump greifen keine Prozesse auf die Daten zu.

Das Problem: Anfangs hatte ich Datenraten um 10 MB/s (laut gstat), dump meinte, es braucht 10 Stunden. Im Lauf der Zeit ist die Datenrate immer mehr eingebrochen und zum Schluß waren grade mal 800 kB/s übrig - der gesamte dump (ca 200G Daten) hat 31 Stunden gedauert, mitlere Datenrate 1,7 MB/s.

Hat jemand eine Idee woran das liegen könnte bzw. kennt jemand eine Abhilfe? Habe gesucht aber nichts nenneswertes gefunden.

Vielen Dank!
Stefan
 
Da GBDE nicht nur jeden Block mit einem anderen Schluessel verschluesselt, sondern AFAIK auch noch die Zurodnung logisch -> physikalischer Block nichtlinear ist. Koennten die Zahlen schon stimmen. Du musst Bedenken, dass dump(8) sehr viel an Metadaten anfasst. Und wirklich schnell ist es so oder so nicht.

Ich kann hier mit dump(8) auf ein LTO-3 mit knappen 60-70MB/s schreiben. Derweil liest jedoch die Platte mit 90-100MB/s. Das scheint also alles Overhead von dump(8) zu sein.

Wenn du die GBDE-Partition nicht mehr brauchst, koenntest du da ja mal ein GELI drauf tun, und dann nochmal zurueckdumpen.
 
Wer ist denn nun eigentlich Schuld an der schlechten Übertragungsrate?
GELI, GBDE, die Hardware? Plane gerade die Neukonfiguration eines
Servers und verschlüssele die Jails und die Backup-Partition mit GELI,
kann ja mal berichten wie schnell oder langsam das dump-Backup damit läuft.
 
GBDE, aber Schuld kann man das nicht nennen. GBDE schreibt Dateien nicht sequentiell auf die Platte sondern verteilt. Das ist kryptografisch toll, in Sachen Performanz tötet es aber moderne Platten, die auf möglichst sequentielle Reads ausgelegt sind.
 
Vielen Dank für die Antworten! Mir war klar, dass die Verschlüsselung Geschwindigkeit kostet. Aber warum die Leserate derart absinkt (800 kB/s, das ist ungefähr ein 4x CD-ROM...), ist mir schleierhaft. Eigentlich müßte die Rate doch mit ein paar Schwankungen relativ konstant bleiben, oder?

Viele Grüße
Stefan
 
Du verwechselst Lese- und Schreibrate. Wie bereits geschrieben, liest dump(8) wesentlich mehr Daten, als es schreibt. Beim naechsten Mal also iostat(8) und gstat(8) im Auge behalten.

Desweiteren musst du dir verdeutlichen, dass die Festplatte beim Lesen ueber GBDE Folgendes machen muss: 512 Bytes Lesen, Seek an bel. Stelle der Platte, 512B Lesen, Seek, 512B, Seek, 512B, Seek ...

Wenn du wirklich mal Spass haben willst, dann mache ein 2048-Blocksize GBDE-Image von ca. 600MB und schreibe das auf eine CD-ROM. Und dann die CD (unverschluesselt) auslesen ...
 
MrFixit schrieb:
Du verwechselst Lese- und Schreibrate.
Zum Vergrößern anklicken....
Inwiefern? Das Device (/dev/ad6.bde) hatte jedenfalls laut gstat zu Beginn des Backups eine Leserate von ca 10MB/s, sank stetig ab und hatte gegen Ende ca 800kB/s. Und nach meinem Verständnis sollte die Leserate einigermaßen konstant bleiben und nicht von Stunde zu Stunde weniger werden, oder? Entweder mein System ist von Anfang an langsam (mit hin-und-her-seeken und Ver- und Enschlüsselung) oder nicht - aber dass es immer langsamer wird? Speicherverbrauch war konstant, Prozessorlast ständig auf Anschlag (92-98%)... Ich kann es mir halt einfach nicht erklären...
 
Ah sorry. Du sparchst oben nur von Datenraten, nicht ob lesend oder schreibend. Ich dachte du orientierst dich an der Ausgabe von dump(8), welches effektiv nur den Schreibdurchsatz ausgibt.
 
Das absinken der Raten kann mit der Strategie von dump zusammenhängen, gegen Ende mehr kleine Dateien, eventueller Fragmentierung des GBDE Volumes oder wenn auf dem Rechner sonst nichts gemacht worden ist, kann es auch sein, dass deine Entropiequelle erschöpft wurde.
Das is n Schuss ins blaue, ich weiss nicht genau wo diese in dem Szenario zum Zug kommen könnte, aber das wäre eine vorstellbare Möglichkeit.
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben