.Tar.gz: Gibt es einen Zusammenhang zwischen der Zeit zum Komprimieren und Dekomprimieren?
430
radschapur
Ich komprimiere ein Backup eines mongodb (~ 500 GB) in ein .tar.gz-Archiv, was einige Stunden dauert. Ich versuche, diese Datenbank zu Testzwecken auf verschiedenen Maschinen zu sichern, und ich würde gerne schätzen, wie lange dies pro Maschine dauert.
Meine Frage ist: Gibt es eine Möglichkeit, die Zeit für die Dekomprimierung des Archivs abzuschätzen, je nachdem, wie lange die Komprimierung gedauert hat?
Vielen Dank
Einige [Benchmarks] (https://www.rootusers.com/gzip-vs-bzip2-vs-xz-performance-comparison/). Unterschiede in der Hardware zwischen Quell- und Zielcomputern können jedoch dazu führen, dass das Ergebnis stark variiert.
xenoid vor 6 Jahren
1
Interessante Ergebnisse, danke für den Link. Die meisten Maschinen, mit denen ich zu tun habe, haben ähnliche Hardware, so dass ich immer noch eine Idee haben kann. Ich mache mir hauptsächlich Sorgen über die Dekompression, daher scheint mir gzip die beste Option für mich zu sein, wobei die Dekomprimierung etwa zehnmal schneller ist als die Komprimierung.
radschapur vor 6 Jahren
1
Ich würde erwarten, dass Festplatten-E / A in beiden Prozessen der Engpass ist. Das Schreiben ist tendenziell schneller als das Lesen, da durch das Zwischenspeichern der Writer nicht auf die Festplatte warten muss.
Barmar vor 6 Jahren
1
2 Antworten auf die Frage
0
Stennie
Mir ist kein Standard-Verhältnis von Komprimierung zu Dekomprimierung bekannt, da dies wirklich von Ihren Daten und Serverressourcen abhängt. Unter der Annahme, dass alle anderen Ressourcen gleich sind, ist die Dekomprimierung im Allgemeinen schneller, da weniger Rechenaufwand erforderlich ist. Ihre ungünstigste Schätzung entspricht möglicherweise der anfänglichen Kompressionszeit.
Für einen einfachen Gewinn würde ich jedoch die Verwendung empfehlen pigz, da eine parallele Implementierung gzipmehrere Prozessoren und Kerne nutzt. Wenn Sie nicht nur einen einzigen Kern zur Verfügung haben, pigzsollten Sie die Zeit für die Komprimierung und Dekomprimierung erheblich reduzieren.
Verwendungsbeispiel mit tar:
tar -c --use-compress-program=pigz -f data.tgz /path/to/data
Danke für die Information. Ich habe pigz zur Kompression verwendet. Leider beabsichtige ich, die Datenbank nur einmal zu komprimieren, um sie auf vielen anderen Servern zu replizieren. Daher ist die Dekomprimierung das Hauptanliegen. Pigz scheint dort nicht viel zu verbessern.
radschapur vor 6 Jahren
0
@radschapur Vielleicht ist `bzip2` und` pbzip2` (parallel bzip) eine bessere Option? Das `bzip`-Format scheint der parallelen Dekomprimierung pro Diskussion unter https://github.com/madler/pigz/issues/36 förderlicher zu sein.
Stennie vor 6 Jahren
0
0
TOOGAM
Es gibt kein festes Verhältnis für dieselbe Maschine, und die Verwendung mehrerer Maschinen (unterschiedlicher Typen) kann durchaus Auswirkungen haben. Komprimierung und Dekomprimierung umfassen aktiv Datenspeicherung (z. B. eine "Festplatte" oder "SSD"), einen Prozessor und andere Komponenten wie Speicher.
Als eine Verallgemeinerung ist das Dekomprimieren ziemlich schnell und kann sogar schneller sein als das Kopieren der unkomprimierten Datenmenge. Das Komprimieren kann auch ähnlich schnell sein, und für so etwas wie die RLE-Komprimierung kann es sein. Bei zip und gzip sind gängige Implementierungen langsamer als die Dekomprimierung. Wenn Sie sich für aggressivere Komprimierungsoptionen entscheiden, die 2-4 mal so lange dauern können, können Sie häufig eine weitere Komprimierungseffizienz von 5% bis 15% erzielen.
Der Unterschied besteht hauptsächlich darin, dass die Komprimierung einige Tests beinhaltet (manchmal als "Vermutung" gedacht) und einige Tests ohne Erfolg sind. Im Gegensatz dazu folgt die Dekomprimierung im Allgemeinen nur einem zuvor festgelegten Prozess, so dass dies relativ schneller geht.