Aufgabe; 400GB LVM Volume zu Backupzwecken möglichst schnell und performant komprimieren und de-komprimieren.
gzip gewinnt um Faktor 4-5 gegen bzip2 und lzma.
gzip ist jedoch nicht Mutli-Core fähig – nimmt also nur einen Core der CPU. In meinem Fall langweilen sich also 7 Cores.
Hierfür gibt es pigz, welches für Multi-CPU/Core entwickelt wurde. Prima – jetzt kann ich meine 400GB mit 8 Kernen komprimieren – reduziert die Zeit auf 42 Minuten und macht Netto 81GB.
Jetzt wirds jedoch haarig – die Rücksicherung geht wieder nur mit einem/einer Core/CPU 🙁
In meinem Fall dauerte das entpacken der 81GB Datei auf die ursprünglichen 400GB knapp 9 Stunden…
Die Manpage sagt hierzu „Decompression can’t be parallelized, at least not without specially prepared deflate streams for that purpose. As a result, pigz uses a single thread (the main thread) for decompression, but will create three other threads for reading, writing, and check calculation, which can speed up decompression under some circumstances“
UPDATE: Ich hab mich gerade mit Mark Adler unterhalten (der Autor von pigz und Co-autor von gzip) – er meint, die Dekompression muss immer schneller gehen. Hier scheint irgendwas faul zu sein bei mir – vielleicht liegts am LVM.
UPDATE2: So jetzt kann ich auch mit ähnlicher Geschwindigkeit entpacken… Schuld war die fehlende Angabe einer passenden Blockgröße bs=… Ohne Angabe hat dd versucht, erstmal alles zu buffern, bevor es ans Schreiben ging. Danke an Stan Hoeppner – Beitrag hier
https://lists.debian.org/debian-user/2011/08/msg00541.html