XZ - das Kompressionswunderwerkzeug

[heisenberg]

Ich bin immer wieder erstaunt, was xz(xz-utils) für krasse Kompressionsraten erzielt. Ich habe hier Logfiles, die xz auf durchschnittlich 0,5% des Originalplatzes runterkomprimiert. Bei DB-Redo-Logfiles ist die Bilanz etwas schlechter, aber auch da sind es noch ca. 10% der Originalgrösse.

Hier mal ein Vergleich(Alles mit maximaler Kompressionsstufe -9 des jeweiligen Werkzeuges komprimiert).

Code: Alles auswählen

-rw-r--r-- 1 root root 5713920 Jun 21 11:10 t0.tar
-rw-r--r-- 1 root root   96868 Jun 21 11:09 t1.tar.xz
-rw-r--r-- 1 root root  726625 Jun 21 11:09 t2.tar.gz
-rw-r--r-- 1 root root  748131 Jun 21 11:09 t3.tar.bz2

[ThorstenS]

Das ist die eine Sicht auf das Ergebnis, die andere sind die Kompressionszeiten. Ich bin bei gz geblieben, weil ich mittels pigz alle Kerne auslasten kann und somit die Gesamtbilanz für mich positiver ausschaut, als bei xz.

[Meillo]

Ist also xz nicht multithreading-faehig?

Wichtiger fuer mich: Kann man bei teilweise veraenderten (z.B. abgeschnitten) xz-Dateien die noch intakten Teile dekomprimieren, wie das bei bzip2 moeglich ist? Die Wikipedia wusste dazu leider nichts.

[heisenberg]

Das ist die eine Sicht auf das Ergebnis, die andere sind die Kompressionszeiten. Ich bin bei gz geblieben, weil ich mittels pigz alle Kerne auslasten kann und somit die Gesamtbilanz für mich positiver ausschaut, als bei xz.

Parallelkomprimierer gibt es für alle 3 (gzip,bzip2,xz).

[hikaru]

LZMA ist schon ein netter Algorithmus. Neben der Kompresionsrate ist auch der vergleichsweise geringe Rechenaufwand beim Entpacken sehr angenehm, insbesondere auf langsamen Systemen.

pixz ist smp-fähig.

[heisenberg]

Wichtiger fuer mich: Kann man bei teilweise veraenderten (z.B. abgeschnitten) xz-Dateien die noch intakten Teile dekomprimieren, wie das bei bzip2 moeglich ist?

Sieht ganz so aus.

Code: Alles auswählen

user@vc-blablub:/tmp$ cat 2016-05.tar.xz | dd bs=1 count=$(( $(du -sb 2016-05.tar.xz | awk '{print $1}') - 200 )) | tar -xvJf -
./2016-05-04/result.log
...
52476+0 records in
52476+0 records out
52476 bytes (52 kB) copied, 0,12013 s, 437 kB/s
...
./2016-05-01/result.log.0
xz: (stdin): Unexpected end of input
tar: Unexpected EOF in archive
tar: Unexpected EOF in archive
tar: Error is not recoverable: exiting now
user@vc-blablub:/tmp$

Nachdem alle 3 Programme Streamkomprimierer sind, würde ich das jetzt auch direkt so erwarten.

[wanne]

Defakto spielt xz sein volles können vor allem bei Binarys aus. Während die Gewinne zu bz2 bei logs nur gering sind (oder xz sogar schlechter abschneidet) ist man da ziemlich unschlagbar.
Ich verwende es trotzdem kaum noch Plattenplatz und Netzwerk ist billig. Und gzip -1 ist IMHO in Sachen Preis-Leistung einfach bei weitem überlegen.

[heisenberg]

Ein kleiner Vergleichstest dazu im Web:

http://catchchallenger.first-world.info ... LZ4_vs_LZO

Hier noch ein Testscript, falls Ihr selbst vergleichen möchtet:

39382

Die Ausgabe sieht dann so aus(jetzt im NoPaste):

39386

Update 22.6.2016 - 1: lzop hinzugefügt
Update 22.6.2016 - 2: parallele Varianten hinzugefügt, Feld "Realzeit" hinzugefügt

[Meillo]

Und gzip -1 ist IMHO in Sachen Preis-Leistung einfach bei weitem überlegen.

Das Argument gegen gzip (beim Backup) ist halt dessen Problem mit dem teilweisen Recovery von korrupten Archiven.

[Colttt]

Ein kleiner Vergleichstest dazu im Web:

http://catchchallenger.first-world.info ... LZ4_vs_LZO

interessant wäre hier jetzt auch noch die SMP-fähigen pendants dazu, vor allem was die Zeit angeht..

[heisenberg]

Und gzip -1 ist IMHO in Sachen Preis-Leistung einfach bei weitem überlegen.

Das kommt natürlich immer auf den Anwendungsfall an. IMHO mögen Festplattenspeicherpreise stark gesunken sein, aber deswegen sind Sie immer noch ein erheblicher Kostenfaktor, der sich natürlich auch noch potentiert, wenn man an die verschiedene Anzahl von Backupsätzen denkt, die man von jeder Datei haben will.

Wenn man einen Server hat, der 24 oder mehr (virtuelle) Kerne mit passabler Leistungsfähigkeit hat, die man gleichzeitig nutzen kann, dann ist die CPU-Anforderung auf einmal auch gar nicht mehr so entscheidend.

Darüber hinaus ist jede Platzeinsparung unter Umständen auch eine echte Einsparung von I/O - wenn man statt 10 GB regelmässig nur 9 GB von der Platte lesen muss- und davon kann man nie genug haben.

Allerdings kann Komprimierung einer effektiven Sicherung manchmal auch im Weg stehen. Beispielswiese kann man von einem sehr grossen DB-Dump, der nur einige wenige Änderungen enthält in Form geänderter SQL-Statements gute inkrementelle Backups machen. Sind die Dumps komprimiert, sind die Dateiinhalte aller Wahrscheinlichkeit so unterschiedlich, dass effektiv beide Dateien voll gesichert werden müssen.

[heisenberg]

Die Überprüfung der parallalen Varianten hat dann nochmal interessante Ergebnisse gezeigt.

Siehe: 39386

[heisenberg]

Interessant auch, dass xz sich als einziges Werkzeug weigert ein defektes tar-Archiv zu komprimieren(War bewusst vorher von mir verkürzt worden).

[DeletedUserReAsG]

Dass ’n Packer selbst wählt, welche Daten er packen möchte und welche nicht, würde ich allerdings eher negativ bewerten. Eine Warnung wäre das Höchste, was ich akzeptieren würde; eigentlich hat ein Packer imho stumpf alles durchzuziehen, was man ihm vorsetzt – was da drin ist, sollte es allenfalls dazu analysieren, die beste Packstrategie zu bestimmen.

[heisenberg]

Das scheint eher ein Zufallstreffer gewesen zu sein. Bei einem gezielten Test, bekomme ich die xz-Fehlermeldung nicht mehr.

[DeletedUserReAsG]

Ja, hab’s gerade ausprobiert → funktioniert, wie’s soll

Edit, noch etwas on-topic: hat pixz nennenswerte Vorteile gegenüber der xz-eigenen Multithreadoption?

Code: Alles auswählen

  -T, --threads=ZAHL    Erzeuge höchstens ZAHL viele Threads; die Grund-
                        einstellung ist 1. Wenn der Wert 0 angegeben wird, dann
                        werden so viele Threads erzeugt, wie es Prozessorkerne
                        gibt

[heisenberg]

pixz bringt bei hoher kompression gar nix. Beim Messen von der Stufen -3,-6 und -9 gibt es nur bei den ersten beiden die Multi-CPU-Power. Bei -9 ist der Zeitverbrauch wie bei Single-Thread-xz.

Code: Alles auswählen

Testname      Testfile Dur.(Sec) CPU-Time Used RAM ComprSize    Compr. Ratio
============================================================================
pixz -9 16x   img_jpg    35.09    35.01   678248   50567988         88.07 %
pixz -3 16x   img_jpg     5.56    34.85   325925   55426356         96.54 %
pixz -1 16x   img_jpg     3.89    39.85   205131   55504028         96.67 %

Die xz-mutlithreaded-Option habe ich bisher noch gar nicht bemerkt. Nehme ich auch nochmal mit dazu. Mittlerweile dauert das aber ganz schön lange, da pro Test 20 Runden durchgeführt werden um halbwegs sauber gemittelte Testergebnisse zu bekommen.

In der Manpage steht auch dieses hier:

Multithreaded compression and decompression are not implemented yet, so this option has no effect for now.

[wanne]

pixz bringt bei hoher kompression gar nix.

Das ist so nicht richtig. -1 bis -9 vergrößert vor allem das Dictionary. (-1 bs -3 spielen noch am Match finder rum um etwas schneller zu sein) -9 hat eines von 64MiB. Bei einer Dateigröße von 48MiB sind da schonal 15MiB aus Prinzip ungenutzt. Für Dateien <32MiB sind -8 und mit -9 identisch in der Kompression. Ein Dictionary, das größer als die Datei ist, ist sinnlos. Eines das nur minimal kleiner als die Datei ist, ist fast sinnlos.

Paralellisiert wird indem die Datei in Chunks eingeteilt wird. Chunks die gleichzeitig komprimiert werdend können nicht gegeneinander komprimiert werden. Wenn du von deinem 64MiB Dictionary profitieren willst, sollte also mindestens die ersten 64MiB am Stück lassen und in einen Chunk packen. Bei 48MiB Dateigröße bist du dann singlethreated.
Damit vernünftig Parallelisiert werden kann solltest du mindestens die ~10-fache DictSize pro Thread haben. Eher etwas mehr.

Wenn du größere Kompression nur auf kosten der CPU und nicht auf kosten des Speichers (der nunmal durch die Dateigröße begrenzt ist) haben willst kannst du den "mode" umstellen (-e) oder "nice" hochsetzen. Ähnlich verghällt sich die mit "depth". Da gute werte zu ermitteln ist allerdings schwer.
Zuletzt sollte noch angemerkt sein, dass die Parallelisierung sinlos ist ohne genügend RAM. DictSize*Threads*10 ist sinnvoll. dh. für -9 und 4 Threads mindestens 2,5GiB
Das gleiche gilt für die Ursprungsdatei. Um vernünftig testen zu können sollte deutlich größer als 2,5GiB sein.

Für kleinere Dateien lohnen sich höhere Kompressionsstufen/Multithreading nicht.

Ansonsten: jpeg hat schon ein verlustfreies Kompressionsverfahren am Ende. Das ist zwar nur eine Entropiekodierung aber dadurch ein recht störrisches Objekt. Gerade bzip2 das am ende ebenfalls eine Entropiekodierung hat dürfte da unfair benachteiligt sein, wenn man vergleicht.

[DeletedUserReAsG]

heisenberg, pixz war bei dir das, was den kaputten Tarball angemeckert hat. Offensichtlich versucht’s, die Inhalte des Archivs gleichmäßig auf die Threads zu verteilen, wozu es das natürlich erstmal einlesen muss und bei kaputter Datei einen Fehler wirft. In dem Kontext ist’s okay – man kann die „tar-Erkennung“ auch unterbinden.

Ich wollte gerade mal pixz und xz mit ähnlichen Parametern (-9) auf ein getartes ~/.thunderbird (~280MB, bunte Mischung aus mehr oder weniger gut komprimierbaren Daten – überwiegend aber wohl gut, das Ergebnis ist nur noch rund ein Drittel so groß) loslassen, leider braucht’s mehr RAM, als ich auf diesem Kistchen zur Verfügung habe → es swappt, als Messung ist’s unbrauchbar, allerdings ist bis dahin der angezeigte Durchsatz mit -T 2 ~60% höher, als mit -T 1 an der gleichen Stelle, Letzteres ist aber aufgrund des geringeren Speicherverbrauchs (und daher ohne zu swappen) unterm Strich 30% schneller. Ein 100MB-Stück der obengenannten Datei wird bei mir jedoch immer mit einem Thread abgearbeitet, egal, was ich mitgebe. pixz bringt’s System bei dem 280MB-Tarball wieder zum Swappen (zeigt aber im Gegensatz zu xz den momentanen Durchsatz nicht an), beim 100MB-File (mit -t explizit nicht als Tarball behandelt, da sonst die erwähnte Fehlermeldung kommen würde) sind Zeit und Kompressionsrate vergleichbar mit xz bei einem Thread, es wurde überwiegend auch nur ein Kern genutzt.

Um vernünftig testen zu können sollte deutlich größer als 2,5GiB sein.

Kommt drauf an, was man testen will – wenn man üblicherweise auf älterer Hardware Backups von einzelnen Verzeichnissen zusammenpackt (wo ~/.thunderbird auf ’nem Desktopsystem ja ein typischer Kandidat wäre), bringt’s einem nicht viel, wenn man weiß, dass pixz bei ’nem aus 2 1.25GiB-Textfiles bestehenden 2.5GiB-Tarball und ausreichend RAM schneller wäre. Wenn’s um ’nen rein technischen, also in der Praxis irrelevanten, Vergleich gehen sollte, sollte man hingegen schon zusehen, dass die Ausgangsbedingungen möglichst optimal sind, da stimme ich zu – wenn ich allerdings einen Packer für eine konkrete praktische Anwendung suche, etwa für ein Backup auf einer gegebenen Maschine, würde ich die Kandidaten konkret mit diesem Backup auf dieser Maschine testen.

[wanne]

OK, ich muss mich wohl nochmal verbessern: Für kleine Dateien ist -9 einfach nicht sinnvoll. Das wird in der man-Page ausdrücklich erwähnt. Selbstverständlich ist das Ergebnis aussagekräftig für diese Datei. Wenn aber schon in der man-page steht, dass die Parameter für die Datei unsinnig sind, sollte man sich nicht wundern, wenn das nicht so genial ist, was da raus kommt. (Und eben nicht auf andere Dateien schließen.)
Die höheren Kompressionsstufen sind bei xz definitiv mit Vorsicht zu genießen und sollten eben nur da eingesetzt werden wo sie sinnvoll sind. (Wenn man viel RAM Zeit und große Dateien hat.)

Bisschen wie volle Plastikflaschen an die Schleifmaschine halten. Man wird feststellen, dass sie sogar schneller kaputt gehen, als Glasflaschen. Das Ergebnis ist richtig. Und wenn das dein Threat model ist, definitiv der richtige Test. Der Test ist aber auch sinnloß weil man das ohne weiteres auch ohne Experiment vorhersagen kann. Die schlussfolgern dass Plastikflaschen schneller kaputt gehen als Glasflaschen ist dagegen vollständig falsch.

Ansonsten komprimiert die multithreadded Variante etwas schlechter als xz. Ich würde mir bei wenig RAM und 280MB massiv überlegen, ob man nicht besser -8 und xz nutzt. Dürfte vermutlich ähnliche Ergebnisse in der Größe haben aber dafür schneller laufen.

[DeletedUserReAsG]

Der Test ist aber auch sinnloß weil man das ohne weiteres auch ohne Experiment vorhersagen kann.

Ach wanne, du weißt doch, dass ich ’n doofer Noob bin, und sowas nicht vorhersagen kann. Wenn ich also Packer vergleiche, komprimiere ich damit jeweils die gleiche Ausgangsdatei (mit Daten, die ich auch im Normalfall komprimieren würde) mit höchstmöglichem Kompressionslevel und schau’, wer‘s wie schnell bei wieviel RAM-Verbrauch wie klein macht. Der Gewinner ist fortan mein Favorit und gut. Leute, die detaillierter wissen, wie‘s funktioniert, mögen das nicht nötig haben, die sagen „sieht man doch, dass pixz schlechter komprimiert“. Andere probieren’s aus und finden, dass es bei der konkreten Testdatei gar noch leicht besser und leicht schneller war. So what?

Abgesehen davon kann xz mittlerweile sehr wohl Multithreading, wie oben schon geschrieben, und die einzigen mir aufgefallenen Unterschiede zwischen pixz und xz (neben den der paar Byte und Sekunden, die pixz besser/schneller war) sind, dass pixz Tarballs aufmachen kann, um das Komprimieren sinnvoll zu parallelisieren, und dass es keine hübsche Verboseoption mit fortlaufender Datenaktualisierung wie xz hat. Überhaupt spricht mich die Bedienung von xz mehr an, außerdem muss man zwei Zeichen weniger tippen, um’s zu benutzen. Und das ist ja wohl ein ein ultimatives Argument für xz. [scnr]

[wanne]

mit höchstmöglichem Kompressionslevel und schau’, wer‘s wie schnell bei wieviel RAM-Verbrauch wie klein macht.

Und genau diese Vorgehensweise wollte ich kritisieren. Multithreadded -9 ist in vielen Fällen eine deutlich schlechtere Idee als -8e mit einem Thread. (Langsamer bei schlechterer Kompressionsrate) Weil du mit deinen Tests eben nie alle Optionen abdecken kannst ist es durchaus sinnvoll mal zu gucken, was diejenigen, die das Tool geschrieben haben zu sagen haben.

[DeletedUserReAsG]

Hmm … steht denn die Zahl nicht mehr für die Kompressionsstufe? Wenn nämlich doch, dann ist die höchste Stufe die einzige Möglichkeit, verschiedene Programme sinnvoll zu vergleichen, „höchste“ ist überall „höchste“, aber -6 bei blubzip4 muss nicht -6 bei blar7 entsprechen (oder ist irgendwo festgelegt, dass die Option linear zu sein hat? Wenn ja, wo?). Hat dann selbstverständlich keine Aussage für die Geschwindigkeit, wenn man’s da vergleichbar machen wollte, müsste man die Parameter austüfteln, mit denen beide Programme etwa gleichstark komprimieren und dann die Laufzeit messen.

[heisenberg]

Und genau diese Vorgehensweise wollte ich kritisieren.

Danke für Deine konstruktive Kritik Wanne. Auch wenn in den Manpages normalerweise nur Müll drin steht, scheint es dieses Mal wohl anders zu sein. (Wer Ironie findet, darf sich gerne einen Stempel ins Hausaufgabenheft drücken lassen.)

Brute-Force-Testing ist für mich eine effektive Methode für den Erkenntnisgewinn.

Das viele Dateiformate mittlerweile eine sehr starke inhärente Kompression haben ist mir auch klar. Doch ich will nicht raten, sondern wissen(= testen). GIF bekommt man z. B. noch auf 65% runter.

Auch dass ich derzeit, wo ich noch in der Entwicklung des Testprogramms bin mit kleineren Dateigrössen spiele ist der Tatsache geschuldet, dass ich in überschaubaren Zeiträumen Ergebnisse haben will. Die Auswirkung auf pixz hatte ich dabei allerdings noch nicht so klar vor Augen.

Wenn ich noch genug Lust habe da weiter zu scripten, dann werde ich die Ergebnisse mal in eine kleine DB schreiben, um Dann die diversen Tests nur jeweils einmal (=1 x intensiv über X Einzelvorgänge) durchführen muss.

[wanne]

Die -1 bis -9 beeinflussen wie gesagt in erster Linie die DictSize. Garantiert die wichtigste Größe um die Kompressionsrate zu beeinflussen. Daneben gibt es aber eben noch einige andere:
Mehr Threads verursachen schlechtere Raten. Dann gibt es noch "mf", "mode" "nice" "lc"... xz bietet da viele Optionen.
Wenn du "depth" auf 9000 setzt, wirst du schlicht nicht mehr abwarten können bis das Ding fertig komprimiert.
Btw siht das bei gzip ähnlich aus -1 bis -9 stellen nur an einigen Parametern rum. Setzt man die in Sourcecode auf das maximum bekommt man wesentlich bessere Kompressionsergebnisse. Dafür komprimiert man an einem MiB über eine Minute.
Letztednlich ist eben auch -9 nur ein Kompromiss aus Geschwindigkeit und Kompressionsrate. Bei xz kannst du da mit vielen Parametern noch deutlich weiter jenseits des -9 gehen.
Irgend wann wird's halt sinnlos. Mit -9 zu vergleichen zeigt eigentlich nur, was die Entwickler des tools für die maximale noch vernünftige Datenrate hielten.

Entweder du hältst die Kompressionszeit konstant und vergleichst dann die Komprimierten Ergebnisse oder du hältst die Kompressionsrate gleich und guckst, welches am schnellsten ist.
Das maximum rausfinden zu wollen ist ziemlicher Quatsch. Irgend wann werden die Algorithmen halt so langsam, dass sie absolut unbrauchbar sind. Um das wirkliche maximum von xz herauszufinden bräuchtest du halt Jahre um deine ~200MiB zu komprimieren.