Najszybsze narzędzie GZIP

18

Szukam najszybszego gzip(lub zip) narzędzia. Mam wolumin LVM, który w 95% istnieje z próby ślepej 0, więc kompresja jest bardzo łatwa. Szukam najszybszego rozwiązania i tak naprawdę nie dbam o kompresję, z wyjątkiem tych 0.

Jestem świadomy gzip -1(tak jak gzip --fast), ale zastanawiałem się, czy jest jakaś szybsza metoda.

Dzięki.

Edit: po kilku testach porównywałem gzip -1, lzop -1a pigz -1granie i doszli do następujących wyników:

PIGZ:

time dd if=/dev/VPS/snap | pigz -1 | ssh backup-server "dd of=/home/backupvps/snap.pigz"

104857600+0 records in
104857600+0 records out
53687091200 bytes (54 GB) copied, 2086.87 seconds, 25.7 MB/s
7093985+266013 records in
7163950+1 records out
3667942715 bytes (3.7 GB) copied, 2085.75 seconds, 1.8 MB/s

real    34m47.147s

LZOP:

time dd if=/dev/VPS/snap | lzop -1 | ssh backup-server "dd of=/home/backupvps/snap.lzop"

104857600+0 records in
104857600+0 records out
53687091200 bytes (54 GB) copied, 1829.31 seconds, 29.3 MB/s
7914243+311979 records in
7937728+1 records out
4064117245 bytes (4.1 GB) copied, 1828.08 seconds, 2.2 MB/s

real    30m29.430s

GZIP:

time dd if=/dev/VPS/snap | gzip -1 | ssh backup-server "dd of=/home/backupvps/snap_gzip.img.gz

104857600+0 records in
104857600+0 records out
53687091200 bytes (54 GB) copied, 1843.61 seconds, 29.1 MB/s
7176193+42 records in
7176214+1 records out
3674221747 bytes (3.7 GB) copied, 1842.09 seconds, 2.0 MB/s

real    30m43.846s

Edycja 2 :

Nie jest to trochę związane z moim początkowym pytaniem, jednak przy użyciu time dd if=/dev/VPS/snap | lzop -1 | ssh backup-server "dd of=/home/backupvps/snap.lzop"(rozmiar bloku zmieniono na 16M) czas został skrócony do real 18m22.442s!

linux compression gzip

— Devator
źródło

1

Bądź ostrożny: używanie tego timew taki sposób jest nieco niesprawiedliwe . Przepustowość użytego dd pigzjest niższa niż pozostałe dwa.

— Henk,

@Devator: patrząc na czasy można stwierdzić, że przepychanie bajtów przez zaszyfrowany tunel ssh jest wąskim gardłem. próbowałeś użyć ssh z flagą „-c” (kompresja) i wypuściłeś kompresor z równania? możesz także przejść na szybszy algorytm szyfrowania. poza tym: ponownie przetestuj bez tunelu ssh (np. używając / dev / null jako ujścia wyjściowego)

— akira

Jako sidenote mógłbyś użyć rzadkiego pliku ? Wtedy zera nie zajmowałyby miejsca na dysku. Twoja kompresja byłaby również szybsza, ponieważ zera byłyby interpolowane przez sterownik systemu plików (i nie musiałyby być odczytywane z dysku.)

— Li-aung Yip

@ Li-aungYip Nie sądzę, ponieważ „pliki” są woluminami LVM.

— Devator

O, rozumiem. Kontynuować!

— Li-aung Yip

14

Jeśli nie masz nic przeciwko odejściu od DEFLATE, lzopjest to implementacja LZO, która faworyzuje szybkość nad stopniem kompresji.

— Ignacio Vazquez-Abrams
źródło

1

lub .. snappy: code.google.com/p/snappy

— akira

Dzięki, okazało się, że jestem lzopnajszybszy w moim scenariuszu. Jest szybszy niż pigzjakoś (prawdopodobnie z powodu wielu zer).

— Devator

23

Chociaż osobiście jeszcze go nie używałem, myślę, że użycie równoległego gzip może nieco przyspieszyć:

pigz, który oznacza równoległą implementację gzip, jest w pełni funkcjonalnym zamiennikiem gzip, który wykorzystuje wiele procesorów i wiele rdzeni do rękojeści podczas kompresji danych.

— Pascal
źródło

1

Używam go rutynowo i absolutnie polecam pigz, jeśli dostępnych jest wiele rdzeni. Oprócz zmiany poziomu kompresji jest to zdecydowanie najbardziej dostępny i prosty sposób na przyspieszenie kompresji.

— jgrundstad

3

Strona wygląda trochę dziwnie. Ale nie daj się oszukać, Pigz jest napisany przez jednego z twórców gzip i zlib, Marka Adlera.

— so_mv

Wygląda na to, że projekt został w tym momencie porzucony.

— AlexLordThorsen

Wolę myśleć o tym jako o „stabilnym”. Nie aktualizuje się często, ale aktualizuje się.

— Alan De Smet

7

Możesz wypróbować Parallel Gzip (połączony przez Pascal) lub Parallel BZIP.
Teoretycznie BZIP jest znacznie lepszy dla tekstu, więc możesz spróbować pbzip .

— Apacz
źródło

2

Twój dysk jest ograniczony do 30 MB / s

Wszystkie sprężarki działają wystarczająco dobrze. Możesz nawet zmniejszyć transfer sieciowy, używając nieco wolniejszego, ale wszechobecnego bzip2.

$dd if=/dev/zero bs=2M count=512 | pigz -1 | dd > /dev/null
512+0 records in
512+0 records out
1073741824 bytes (1.1 GB) copied, 9.12679 s, 118 MB/s
8192+7909 records in
9488+1 records out
4857870 bytes (4.9 MB) copied, 9.13024 s, 532 kB/s
$dd if=/dev/zero bs=2M count=512 | bzip2 -1 | dd > /dev/null
512+0 records in
512+0 records out
1073741824 bytes (1.1 GB) copied, 37.4471 s, 28.7 MB/s
12+1 records in
12+1 records out
6533 bytes (6.5 kB) copied, 37.4981 s, 0.2 kB/s
$dd if=/dev/zero bs=2M count=512 | gzip -1 | dd > /dev/null
512+0 records in
512+0 records out
1073741824 bytes (1.1 GB) copied, 14.305 s, 75.1 MB/s
9147+1 records in
9147+1 records out
4683762 bytes (4.7 MB) copied, 14.3048 s, 327 kB/s

Czy rozważałeś rsync? Dokonuje sumy kontrolnej, a następnie zgłasza jedynie różnicę.

— ZaB
źródło

1

Mój dysk nie jest ograniczony do 30 MB / s. Właśnie przeprowadziłem test: pigz -1: 1073741824 bytes (1.1 GB) copied, 8.6779 seconds, 124 MB/si gzip -1: 1073741824 bytes (1.1 GB) copied, 11.6724 seconds, 92.0 MB/s. Myślałem o rsync, ale sprawdziłoby to różnicę pliku i prawdopodobnie nie pomogłoby, ponieważ przez większość czasu wiele się zmieniło.

— Devator

Jeśli przenosisz zera, zobacz, jak imponujące jest kodowanie bzip2 w porównaniu. Tylko po której stronie mierzysz prędkość ... 4 Mb / s Pigz może być za dużo dla zwykłej linii DSL ... Rośnie jeszcze gorzej, jeśli twój dysk jest tak szybki.

— ZaB

2

Re: lzop jest wolniejszy w standardowej konfiguracji ... Poprawianie może być o połowę krótsze. Istnieje jednak jeszcze szybszy zamiennik o nazwie blosc:

https://github.com/FrancescAlted/blosc

Hmm ... Czas potrzebny na opublikowanie tego i otrzymanie odpowiedzi jest prawdopodobnie co najmniej dwukrotnie większy niż kiedykolwiek zaoszczędzony czas ... Teraz przepraszam, gdy rekompiluję jądro, aby zgolić kolejne .1s od czasu rozruchu 2s.

— technozaur
źródło