it-swarm.com.de

bzip2 zu langsam. Es stehen mehrere Kerne zur Verfügung

Ich führe diesen Befehl aus:

pg_dumpall | bzip2 > cluster-$(date --iso).sql.bz2

Es dauert zu lange. Ich betrachte die Prozesse mit top. Der bzip2-Prozess dauert ungefähr 95% und postgres 5% eines Kerns. Der Eintrag wa ist niedrig. Dies bedeutet, dass die Festplatte nicht der Engpass ist.

Was kann ich tun, um die Leistung zu steigern?

Vielleicht kann bzip2 mehr Kerne verwenden. Der Server verfügt über 16 Kerne.

Oder eine Alternative zu bzip2 verwenden?

Was kann ich tun, um die Leistung zu steigern?

33
guettli

Es gibt viele Komprimierungsalgorithmen und bzip2 Ist einer der langsameren. Plain gzip ist in der Regel deutlich schneller, bei normalerweise nicht viel schlechterer Komprimierung. Wenn Geschwindigkeit am wichtigsten ist, ist lzop mein Favorit. Schlechte Kompression, aber ach so schnell.

Ich beschloss, ein bisschen Spaß zu haben und ein paar Algorithmen zu vergleichen, einschließlich ihrer parallelen Implementierungen. Die Eingabedatei ist die Ausgabe des Befehls pg_dumpall Auf meiner Workstation, einer 1913 MB großen SQL-Datei. Die Hardware ist ein älterer Quad-Core i5. Die Zeiten sind Wanduhrzeiten nur der Komprimierung. Parallele Implementierungen verwenden alle 4 Kerne. Tabelle sortiert nach Komprimierungsgeschwindigkeit.

Algorithm     Compressed size        Compression          Decompression

lzop           398MB    20.8%      4.2s    455.6MB/s     3.1s    617.3MB/s
lz4            416MB    21.7%      4.5s    424.2MB/s     1.6s   1181.3MB/s
brotli (q0)    307MB    16.1%      7.3s    262.1MB/s     4.9s    390.5MB/s
brotli (q1)    234MB    12.2%      8.7s    220.0MB/s     4.9s    390.5MB/s
zstd           266MB    13.9%     11.9s    161.1MB/s     3.5s    539.5MB/s
pigz (x4)      232MB    12.1%     13.1s    146.1MB/s     4.2s    455.6MB/s
gzip           232MB    12.1%     39.1s     48.9MB/s     9.2s    208.0MB/s
lbzip2 (x4)    188MB     9.9%     42.0s     45.6MB/s    13.2s    144.9MB/s
pbzip2 (x4)    189MB     9.9%    117.5s     16.3MB/s    20.1s     95.2MB/s
bzip2          189MB     9.9%    273.4s      7.0MB/s    42.8s     44.7MB/s
pixz (x4)      132MB     6.9%    456.3s      4.2MB/s     7.9s    242.2MB/s
xz             132MB     6.9%   1027.8s      1.9MB/s    17.3s    110.6MB/s
brotli (q11)   141MB     7.4%   4979.2s      0.4MB/s     3.6s    531.6MB/s

Wenn die 16 Kerne Ihres Servers inaktiv genug sind, um alle für die Komprimierung zu verwenden, führt pbzip2 Wahrscheinlich zu einer erheblichen Beschleunigung. Aber Sie brauchen noch mehr Geschwindigkeit und können ~ 20% größere Dateien tolerieren. gzip ist wahrscheinlich die beste Wahl.

pdate : Ich habe brotli (siehe TOOGAMs Antwort) Ergebnisse zur Tabelle hinzugefügt. Die Einstellung für die Komprimierungsqualität von brotli hat einen sehr großen Einfluss auf das Komprimierungsverhältnis und die Geschwindigkeit. Daher habe ich drei Einstellungen hinzugefügt (q0, q1 und q11). Der Standardwert ist q11, Ist jedoch extrem langsam und immer noch schlechter als xz. q1 Sieht allerdings sehr gut aus; das gleiche Kompressionsverhältnis wie gzip, aber 4-5 mal so schnell!

pdate :lbzip2 (Siehe gmathts Kommentar) und zstd (Johnnys Kommentar) zur Tabelle hinzugefügt und nach Komprimierungsgeschwindigkeit sortiert. lbzip2 Bringt die bzip2 - Familie wieder ins Rennen, indem sie dreimal so schnell wie pbzip2 Mit einem hervorragenden Komprimierungsverhältnis komprimiert! zstd sieht ebenfalls vernünftig aus, wird jedoch von brotli (q1) sowohl im Verhältnis als auch in der Geschwindigkeit übertroffen.

Meine ursprüngliche Schlussfolgerung, dass schlichtes gzip die beste Wette ist, fängt an, fast albern auszusehen. Obwohl für die Allgegenwart, ist es immer noch nicht zu schlagen;)

51
marcelm

Verwenden Sie pbzip2.

Das Handbuch sagt:

pbzip2 ist eine parallele Implementierung des bzip2-Block-Sorting-Dateikompressors, der pthreads verwendet und auf SMP-Computern eine nahezu lineare Beschleunigung erzielt. Die Ausgabe dieser Version ist vollständig kompatibel mit bzip2 v1.0.2 oder neuer (dh alles, was mit pbzip2 komprimiert wurde, kann mit bzip2 dekomprimiert werden).

Es erkennt automatisch die Anzahl Ihrer Prozessoren und erstellt entsprechende Threads.

37
ThoriumBR

Sie haben kein Betriebssystem erwähnt. Unter Windows ist 7-Zip mit ZStandard (Releases) eine Version von 7-Zip, die geändert wurde, um die Verwendung all dieser Algorithmen zu unterstützen.

8
TOOGAM

Verwenden Sie zstd . Wenn es für Facebook gut genug ist, ist es wahrscheinlich auch für Sie gut genug.

Im Ernst, es ist tatsächlich ziemlich gut. Ich benutze es jetzt für alles, weil es einfach funktioniert und Sie Geschwindigkeit gegen Verhältnis in großem Maßstab eintauschen können (meistens ist Geschwindigkeit sowieso wichtiger als Größe, da Speicher billig ist, aber Geschwindigkeit ein Engpass ist).
Bei Komprimierungsstufen, die eine vergleichbare Gesamtkomprimierung wie bzip2 erreichen, ist dies erheblich schneller. Wenn Sie bereit sind, zusätzliche CPU-Zeit zu zahlen, können Sie fast Ergebnisse erzielen, die LZMA ähneln (obwohl es dann langsamer als bzip2 sein wird). Bei etwas schlechteren Komprimierungsverhältnissen ist es viel, viel schneller als bzip2 oder eine andere Mainstream-Alternative.

Jetzt komprimieren Sie einen SQL-Dump, dessen Komprimierung so peinlich trivial ist, wie es nur sein kann. Selbst die schlechtesten Kompressoren schneiden bei solchen Daten gut ab.
Sie können also zstd mit einer niedrigeren Komprimierungsstufe ausführen, die Dutzende Male schneller ausgeführt wird und dennoch 95-99% der gleichen Komprimierung für diese Daten erzielt .

Als Bonus können Sie, wenn Sie dies häufig tun und zusätzliche Zeit investieren möchten, den zstd -Kompressor vorab "trainieren", wodurch sowohl das Kompressionsverhältnis als auch die Geschwindigkeit erhöht werden. Beachten Sie, dass Sie, damit das Training gut funktioniert, einzelne Datensätze eingeben müssen, nicht das Ganze. Die Art und Weise, wie das Tool funktioniert, erwartet viele kleine und etwas ähnliche Beispiele für das Training, nicht einen großen Blob.

2
Damon

Es sieht so aus, als ob das Anpassen (Verringern) der Blockgröße einen erheblichen Einfluss auf die Komprimierungszeit haben kann.

Hier sind einige Ergebnisse des Experiments, das ich auf meiner Maschine durchgeführt habe. Ich habe den Befehl time verwendet, um die Ausführungszeit zu messen. input.txt ist eine ~ 250 MB große Textdatei, die beliebige JSON-Datensätze enthält.

Verwenden der Standardblockgröße (größte Blockgröße) (--best wählt lediglich das Standardverhalten aus):

# time cat input.txt | bzip2 --best > input-compressed-best.txt.bz

real    0m48.918s
user    0m48.397s
sys     0m0.767s

Verwenden der kleinsten Blockgröße (--fast Streit):

# time cat input.txt | bzip2 --fast > input-compressed-fast.txt.bz

real    0m33.859s
user    0m33.571s
sys     0m0.741s

Dies war eine etwas überraschende Entdeckung, wenn man bedenkt, dass in der Dokumentation Folgendes steht:

Die Komprimierungs- und Dekomprimierungsgeschwindigkeit wird von der Blockgröße praktisch nicht beeinflusst

1
Jakub Kukul