bzip2 zu langsam. Es sind mehrere Kerne verfügbar

31

Ich führe diesen Befehl aus:

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

Es dauert zu lange. Ich schaue mir die Prozesse mit an top. Der bzip2-Prozess benötigt ungefähr 95% und postgres 5% eines Kerns. Der waEintrag ist niedrig. Dies bedeutet, dass die Festplatte nicht der Engpass ist.

Was kann ich tun, um die Leistung zu steigern?

Vielleicht lassen Sie bzip2 mehr Kerne verwenden. Der Server hat 16 Kerne.

Oder eine Alternative zu bzip2 nutzen?

Was kann ich tun, um die Leistung zu steigern?

performance postgresql gzip

— guettli
quelle

8

Sofern Sie bzip2 nicht aus älteren Gründen benötigen, ist es meine persönliche Erfahrung, dass xz eine bessere Komprimierung / Zeit liefert als bzip2. Es enthält auch Threads, wenn Sie ein ausreichend neues Programm erhalten, und ermöglicht es Ihnen, die Zeit und den Speicherbedarf von gzipish bis hin zu massiv zu skalieren, je nachdem, was Sie möchten.

— Perkins

6

"pigz" ist eine andere Option - es wird eher eine gzip-Ausgabe als eine bzip2-Ausgabe erzeugt. Und im Grunde versteht alles gzip.

— Criggie

Sie können versuchen, es symmetrisch mit GnuPG mit bzip2-Komprimierung zu verschlüsseln. Es scheint aus unbekannten Gründen überraschend schnell zu sein, wenn man es nur komprimiert, selbst mit der höchsten Komprimierungsstufe. Es ist möglich, dass der Algorithmus schneller ist als die Effizienz meines regulären Komprimierungsprogramms, das auf der Benutzeroberfläche basiert.

— Shule

2

Sie haben die Anforderungen Ihres alternativen Algorithmus nicht angegeben. Bzip2 ist spaltbar. Ist dir das wichtig

— Martin Smith

7

" Was kann ich tun, um die Leistung zu steigern? " - nicht komprimieren? Sie sagen eigentlich nicht, dass Sie es komprimiert brauchen, und nicht zu tun ist immer schneller als zu tun. Machen Sie die Festplatte zum Engpass.

— TessellatingHeckler

49

Es gibt viele Komprimierungsalgorithmen und bzip2einer der langsameren. Plain gzipneigt in der Regel nicht viel schlechter Kompression deutlich schneller zu sein. Wenn Geschwindigkeit am wichtigsten ist, lzopist mein Favorit. Schlechte Komprimierung, aber ach so schnell.

Ich beschloss, ein bisschen Spaß zu haben und ein paar Algorithmen einschließlich ihrer parallelen Implementierungen zu vergleichen. Die Eingabedatei ist die Ausgabe des pg_dumpallBefehls auf meiner Workstation, eine SQL-Datei mit 1913 MB. Die Hardware ist ein älterer Quad-Core i5. Die Zeiten sind Wanduhrzeiten nur der Kompression. Bei parallelen Implementierungen werden alle 4 Kerne verwendet. Tabelle sortiert nach Kompressionsgeschwindigkeit.

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 im Leerlauf sind, sodass alle für die Komprimierung verwendet werden können, pbzip2wird dies wahrscheinlich zu einer erheblichen Beschleunigung führen. Aber Sie brauchen noch mehr Geschwindigkeit und können ~ 20% größere Dateien tolerieren, gzipist wahrscheinlich die beste Wahl.

Update: Ich habe brotlider Tabelle Ergebnisse hinzugefügt (siehe TOOGAMs Antwort). brotlis Druckqualitätseinstellung eine sehr große Auswirkung auf Verdichtungsverhältnis und die Geschwindigkeit hat, so dass ich drei Einstellungen hinzugefügt ( q0, q1, und q11). Die Standardeinstellung ist q11, aber es ist extrem langsam und noch schlimmer als xz. q1sieht aber sehr gut aus; das gleiche Kompressionsverhältnis wie gzip, aber 4-5 mal so schnell!

Update: Hinzugefügt lbzip2(siehe gmathts Kommentar) und zstd(Johnnys Kommentar) zur Tabelle und sortiert nach Kompressionsgeschwindigkeit. lbzip2bringt die bzip2Familie zurück ins Rennen, indem sie dreimal so schnell pbzip2komprimiert wie mit einem hervorragenden Kompressionsverhältnis! zstdsieht auch vernünftig aus, ist aber brotli (q1)sowohl in der Übersetzung als auch in der Geschwindigkeit besser.

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

— marcelm
quelle

1

Eine ähnliche Tabelle mit weitaus mehr Algorithmen finden Sie unter mattmahoney.net/dc/text.html .

— Dougal

1

@Dougal Fair genug. Mein Test pg_dumpall

— bezieht sich

1

zstd fehlt ebenfalls in der Tabelle. Beim Komprimieren unserer Protokolldateien stellte ich fest, dass ein einzelner zstd-Kern 16 Kerne von pbzip2 mit vergleichbaren Komprimierungsraten übertrifft.

— Johnny

1

lz4ist übrigens etwas schneller und effizienter als lzop. Es wird jedoch mehr RAM verwendet, was für eingebettete Systeme relevant ist.

— Daniel B

1

Wenn Sie Multithread-Versionen testen möchten, können Sie dies auch versuchen zstd -T4. Für sehr schnelle Einstellungen können Sie versuchen zstd -T4 -1, zstdstandardmäßig -3die von Ihnen getestete Einstellung zu verwenden.

— Cyan

37

Verwenden Sie pbzip2.

Das Handbuch sagt:

pbzip2 ist eine parallele Implementierung des bzip2-Block-Sorting-Dateikomprimierers, der pthreads verwendet und auf SMP-Maschinen eine nahezu lineare Beschleunigung erzielt. Die Ausgabe dieser Version ist voll 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 die entsprechenden Threads.

— ThoriumBR
quelle

Das ist in Ordnung, wenn Sie eine Datei komprimieren, dies funktioniert jedoch schrecklich durch eine Pipe

— camelccc

@camelccc Warum sagst du das? Ich finde das überhaupt nicht der Fall. Für eine optimale Leistung benötigen Sie einen schnellen Produzenten oder einen großen Puffer in der Pipe davor. Dies gilt jedoch auch für pixzund pigzan einer Pipe.

— Michael - Sqlbot

Kommt darauf an, wie groß das ist, was er komprimiert. Wenn Sie einen großen Puffer haben, ist es in Ordnung, wie Sie sagen, wenn Sie etwas leiten, das viel größer als der physische RAM ist, habe ich festgestellt, dass die Dinge etwas interessanter werden können. Wie Sie wahrscheinlich für jeden Komprimierungsalgorithmus wahr sagen.

— Camelccc

4

bzip2 kann ein gutes Stück RAM verwenden, sodass 16 bzip-Worker gleichzeitig nicht-trivialen RAM-Speicher mit mehr als 1 GB belegen können. BTW, lbzip2scheint eine bessere Geschwindigkeit, Speichernutzung und geringfügig bessere Komprimierung als pbzip2. Hier gibt es Benchmarks: vbtechsupport.com/1614

— gmatht

@gmatht lbzip2sieht gut aus! Ich habe es zu meiner Antwort hinzugefügt :)

— marcelm

8

Googles brotli ist ein neueres Format, das in letzter Zeit in Browsern eine breite Unterstützung gefunden hat, da es eine beeindruckende Komprimierung, eine beeindruckende Geschwindigkeit und möglicherweise die beeindruckendste Kombination / Balance dieser beiden Funktionen aufweist.

Daten:

Vergleich der Kompressionsalgorithmen Brotli, Deflate, Zopfli, LZMA, LZHAM und Bzip2
- Beispiel: In diesem Diagramm sind Zahlen angegeben, die zeigen, dass Brotli ungefähr 6-14 schneller ist als Bzip2.
CanIUse.com: Feature: brotli zeigt Unterstützung von Microsoft Edge, Mozilla Firefox, Google Chrome, Apple Safari, Opera (jedoch nicht Opera Mini oder Microsoft Internet Explorer).

Vergleich: Brotli vs deflate vs zopfli vs lzma vs lzham vs bzip2
- Wenn Sie nach einer Komprimierungsgeschwindigkeit suchen, ist das, wonach Sie suchen, welche Linien sich weiter rechts in diesem Diagramm befinden. (Die Einträge oben in diesem Diagramm zeigen ein enges Komprimierungsverhältnis. Höher = enger. Wenn jedoch die Komprimierungsgeschwindigkeit Ihre Priorität ist, sollten Sie mehr darauf achten, welche Linien direkt im Diagramm weiter reichen.)
Vergleich: Komprimierungsrate und Komprimierungsgeschwindigkeit für 7-Zip-ZStandard-Methoden
Facebooks ZStandard ist eine weitere Option, die darauf abzielt, die Anzahl der Bits zu reduzieren, aber auch darauf abzielt, Daten so zu speichern, dass verpasste Vorhersagen reduziert werden, wodurch eine schnellere Geschwindigkeit ermöglicht wird. Die Homepage lautet: Kleinere und schnellere Datenkomprimierung mit ZStandard
Lizard wird nicht ganz so stark komprimiert wie Brotli oder ZStandard, hat jedoch möglicherweise ein ähnliches Komprimierungsverhältnis und ist etwas schneller (zumindest laut dieser Tabelle, die sich mit Geschwindigkeit befasst, obwohl dies eine Dekomprimierung anzeigt).

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.

— TOOGAM
quelle

Interessant, von dem ich schon gehört brotlihatte, aber ich habe es vergessen. Ich habe es in meiner Antwort zur Benchmarktabelle hinzugefügt! Eigentlich war ich ein wenig enttäuscht von der Leistung, außer bei Qualitätseinstellung 1, wo das gleiche Kompressionsverhältnis wie gzipbei einer viel höheren Geschwindigkeit erzielt wurde.

— März

2

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

Im Ernst, es ist eigentlich ziemlich gut . Ich benutze es jetzt für alles, weil es einfach funktioniert und Sie damit im großen Stil Geschwindigkeit gegen Verhältnis tauschen können (am häufigsten ist Geschwindigkeit ohnehin wichtiger als Größe, da Speicher billig ist, Geschwindigkeit aber ein Engpass).
Bei Komprimierungsstufen, die eine vergleichbare Gesamtkomprimierung wie bzip2 erzielen, ist dies erheblich schneller. Wenn Sie bereit sind, etwas mehr CPU-Zeit zu bezahlen, können Sie fast ähnliche Ergebnisse wie bei LZMA erzielen (obwohl dies dann langsamer ist als bei bzip2). Bei etwas schlechteren Komprimierungsraten ist es viel, viel schneller als bzip2 oder jede andere Mainstream-Alternative.

Jetzt komprimieren Sie einen SQL-Speicherauszug, der so peinlich einfach zu komprimieren ist, wie er nur sein kann. Sogar die ärmsten Kompressoren schneiden bei dieser Art von Daten gut ab.
Sie können also zstdmit einer niedrigeren Komprimierungsstufe ausgeführt werden, 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 etwas mehr Zeit investieren möchten, den zstdKompressor im Voraus "trainieren" , was sowohl das Kompressionsverhältnis als auch die Geschwindigkeit erhöht. Beachten Sie, dass Sie einzelne Datensätze füttern müssen, damit das Training gut funktioniert, und nicht das Ganze. Aufgrund der Funktionsweise des Tools werden viele kleine und etwas ähnliche Beispiele für das Training erwartet, nicht ein einziger großer Blob.

— Damon
quelle

Besser noch, verwenden Sie pzstd (parallele Version) auf Multicore-Maschinen

— Borowis

1

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 timeBefehl verwendet, um die Ausführungszeit zu messen. input.txtist eine ~ 250-MB-Textdatei mit beliebigen JSON-Datensätzen.

Verwenden der Standardblockgröße (größte Blockgröße) ( --bestwä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 ( --fastArgument):

# 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 steht:

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

— Jakub Kukul
quelle

Mein aktueller Favorit ist pbzip2. Hast du das auch versucht? Bei dieser Frage handelt es sich um eine Umgebung, in der 16 Kerne verfügbar sind.

— Guettli

@guettli leider muss ich mich an bzip halten. Ich benutze es für Hadoop-Jobs und bzip ist eine der eingebauten Komprimierungen. In gewisser Weise ist es also bereits parallelisiert.

— Jakub Kukul