Zeit, sehr große (100G) Dateien zu komprimieren
Ich muss eine Reihe sehr großer Dateien (80-ish GB) komprimieren, und ich bin überrascht über die (fehlende) Geschwindigkeit, die mein System aufweist. Ich bekomme ungefähr 500 MB / min Konvertierungsgeschwindigkeit; Mit top
scheine ich eine einzelne CPU zu ungefähr 100% zu verwenden.
Ich bin mir ziemlich sicher, dass es nicht (nur) die Geschwindigkeit des Festplattenzugriffs ist, da das Erstellen einer tar
- Datei (so wurde die 80G-Datei erstellt) nur wenige Minuten dauerte (vielleicht 5 oder 10), aber nach mehr als 2 Stunden mein einfaches gzip befehl ist immer noch nicht erledigt.
Zusammenfassend:
tar -cvf myStuff.tar myDir/*
Dauerte
gzip myStuff.tar
Dauerte zwei Stunden und 10 Minuten, um eine 55G ZIP-Datei zu erstellen.
Meine Frage: Ist das normal? Gibt es bestimmte Optionen in gzip
, um die Dinge zu beschleunigen? Wäre es schneller, die Befehle zu verketten und tar -cvfz
zu verwenden? Ich sah Verweis auf pigz
- Parallele Implementierung von GZip - aber leider kann ich keine Software auf dem von mir verwendeten Computer installieren, also das ist für mich keine Option. Siehe zum Beispiel diese frühere Frage.
Ich beabsichtige, einige dieser Optionen selbst auszuprobieren und sie zu planen - aber es ist sehr wahrscheinlich, dass ich nicht auf "die magische Kombination" von Optionen stoße. Ich hoffe, dass jemand auf dieser Seite den richtigen Trick kennt, um die Dinge zu beschleunigen.
Wenn ich die Ergebnisse anderer Versuche zur Verfügung habe, werde ich diese Frage aktualisieren - aber wenn jemand einen besonders guten Trick zur Verfügung hat, würde ich mich sehr freuen es. Vielleicht dauert das gzip nur mehr Verarbeitungszeit als mir klar wurde...
UPDATE
Wie versprochen habe ich die folgenden Tricks ausprobiert: Ändern Sie die Komprimierungsmenge und ändern Sie das Ziel der Datei. Ich habe die folgenden Ergebnisse für einen Tar erhalten, der ungefähr 4.1 GB war:
flag user system size sameDisk
-1 189.77s 13.64s 2.786G +7.2s
-2 197.20s 12.88s 2.776G +3.4s
-3 207.03s 10.49s 2.739G +1.2s
-4 223.28s 13.73s 2.735G +0.9s
-5 237.79s 9.28s 2.704G -0.4s
-6 271.69s 14.56s 2.700G +1.4s
-7 307.70s 10.97s 2.699G +0.9s
-8 528.66s 10.51s 2.698G -6.3s
-9 722.61s 12.24s 2.698G -4.0s
Also ja, das Ändern des Flags vom Standard -6
zum schnellsten -1
gibt mir eine 30% ige Beschleunigung, wobei sich (für meine Daten) kaum an der Größe der Zip-Datei ändert. Ob ich benutze die gleiche Festplatte oder eine andere macht im Wesentlichen keinen Unterschied (ich müsste dies mehrmals ausführen, um eine statistische Signifikanz zu erhalten).
Wenn jemand interessiert ist, habe ich diese Timing-Benchmarks mit den folgenden beiden Skripten generiert:
#!/bin/bash
# compare compression speeds with different options
sameDisk='./'
otherDisk='/tmp/'
sourceDir='/dirToCompress'
logFile='./timerOutput'
rm $logFile
for i in {1..9}
do /usr/bin/time -a --output=timerOutput ./compressWith $sourceDir $i $sameDisk $logFile
do /usr/bin/time -a --output=timerOutput ./compressWith $sourceDir $i $otherDisk $logFile
done
Und das zweite Skript (compressWith
):
#!/bin/bash
# use: compressWith sourceDir compressionFlag destinationDisk logFile
echo "compressing $1 to $3 with setting $2" >> $4
tar -c $1 | gzip -$2 > $3test-$2.tar.gz
Drei Dinge zu beachten:
- Mit
/usr/bin/time
anstelle vontime
, da der eingebaute Befehl vonbash
viel weniger Optionen hat als der GNU-Befehl - Ich habe nicht verwenden Sie die Option
--format
, obwohl dies das Lesen der Protokolldatei erleichtern würde - Ich habe ein Script-in-a-Script verwendet, da
time
nur mit dem ersten Befehl in einer Piped-Sequenz zu funktionieren schien (also ließ ich es wie einen einzigen Befehl aussehen...).
Bei all dem Gelernten sind meine Schlussfolgerungen
- Beschleunigen Sie die Dinge mit dem Flag
-1
(akzeptierte Antwort) - Es wird viel mehr Zeit damit verbracht, die Daten zu komprimieren, als von der Festplatte zu lesen
- Investieren Sie schneller Komprimierungssoftware (
pigz
scheint eine gute Wahl zu sein). - Wenn Sie mehrere Dateien komprimieren müssen, können Sie jeden
gzip
Befehl in einen eigenen Thread einfügen und mehr von der verfügbaren CPU verwenden (poor man ' spigz
)
Danke allen, die mir geholfen haben, all das zu lernen!
4 answers
Sie können die Geschwindigkeit von gzip ändern mit --fast
--best
oder -#
wobei # eine Zahl zwischen 1 und 9 ist (1 ist am schnellsten, aber weniger komprimiert, 9 ist am langsamsten, aber mehr komprimiert). Standardmäßig gzip
läuft auf Stufe 6.
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/techietown.info/template/agent.layouts/content.php on line 61
2013-05-03 17:45:48
Der Grund, warum tar im Vergleich zu gzip so wenig Zeit in Anspruch nimmt, ist, dass das Kopieren Ihrer Dateien in eine einzelne Datei nur sehr wenig Rechenaufwand erfordert (was es tut). gzip auf der anderen Seite verwendet tatsächlich Komprimierungsalgorithmen, um die TAR-Datei zu verkleinern.
Das Problem ist, dass gzip (wie Sie festgestellt haben) auf einen einzelnen Thread beschränkt ist.
Geben Sie pigz ein, das mehrere Threads verwenden kann, um die Komprimierung durchzuführen. Ein Beispiel für die Verwendung wäre werden:
tar -c --use-compress-program=pigz -f tar.file dir_to_zip
Es gibt eine schöne kurze Zusammenfassung der Option --use-compress-program auf einer Schwesterseite.
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/techietown.info/template/agent.layouts/content.php on line 61
2017-05-23 12:41:42
Ich scheine eine einzelne CPU bei ungefähr 100% zu verwenden.
Das bedeutet, dass es kein E/A-Leistungsproblem gibt, sondern dass die Komprimierung nur einen Thread verwendet (was bei gzip der Fall sein wird).
Wenn es Ihnen gelingt, den Zugriff/die Vereinbarung zu erreichen, die für die Installation anderer Tools erforderlich ist, unterstützt 7zip auch mehrere Threads, um Multi-Core-CPUs zu nutzen, obwohl ich nicht sicher bin, ob sich dies sowohl auf das gzip-Format als auch auf das eigene erstreckt.
Wenn Sie stecken bleiben um vorerst nur gzip zu verwenden und mehrere Dateien zu komprimieren, können Sie versuchen, sie einzeln zu komprimieren - auf diese Weise verwenden Sie mehr von dieser Multi-Core-CPU, indem Sie mehr als einen Prozess parallel ausführen. Achten Sie jedoch darauf, es nicht zu übertreiben, denn sobald Sie sich der Kapazität Ihres E/A-Subsystems nähern, sinkt die Leistung steil ab (auf weniger als wenn Sie einen Prozess/Thread verwenden würden), da die Latenz der Kopfbewegungen zu einem erheblichen Engpass wird.
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/techietown.info/template/agent.layouts/content.php on line 61
2013-05-09 14:23:21
Man kann die Anzahl der in pigz verfügbaren Prozesse ausnutzen, was normalerweise eine schnellere Leistung ist, wie im folgenden Befehl
Tar cf - Verzeichnis Archiv | pigz -0 -p largenumber > mydir.Teer.gz -
Beispiel - tar-cf - patha | pigz -0 -p 32 > patha.Teer.gz -
Dies ist wahrscheinlich schneller als die im Beitrag vorgeschlagenen Methoden, da-p die Anzahl der Prozesse ist, die ausgeführt werden können. Nach meiner persönlichen Erfahrung schadet das Setzen eines sehr großen Wertes der Leistung nicht, wenn das zu archivierende Verzeichnis besteht aus einer Vielzahl kleiner Dateien. Sonst ist der betrachtete Standardwert 8. Bei großen Dateien empfehle ich, diesen Wert als Gesamtzahl der auf dem System unterstützten Threads festzulegen.
Beispiel Das Setzen eines Wertes von p = 32 im Falle einer 32-CPU-Maschine hilft.
0 ist für die schnellste Pigz-Komprimierung gedacht, da es das Archiv nicht komprimiert und sich eher auf die Geschwindigkeit konzentriert. Der Standardwert ist 6 für die Komprimierung.
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/techietown.info/template/agent.layouts/content.php on line 61
2020-06-12 13:48:39