Быстрая утилита GZIP

18

Я ищу самую быструю gzip(или почтовую) утилиту. У меня есть объем LVM, который на 95% существует из пустых 0, так что сжатие это очень легко. Я ищу самое быстрое решение, и меня не волнует сжатие, кроме 0s.

Я знаю gzip -1(так же, как gzip --fast), но мне было интересно, есть ли более быстрый метод.

Благодарю.

Edit: после некоторых тестов, я сравнил gzip -1, lzop -1и pigz -1с Афоризм и пришел к следующим результатам:

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

Изменить 2 :

Это несколько не связано с моим первоначальным вопросом, однако при использовании time dd if=/dev/VPS/snap | lzop -1 | ssh backup-server "dd of=/home/backupvps/snap.lzop"(размер блока изменен на 16M) время сокращается до real 18m22.442s!

linux compression gzip Devator
источник
1
Будьте осторожны: это несколько несправедливо в использовании timeтаким образом. Пропускная способность используемого dd pigzниже, чем у двух других.
Хенк
@Devator: взглянув на время, можно сделать вывод, что узким местом является проталкивание байтов через зашифрованный ssh-туннель. Вы пытались использовать ssh с флагом "-c" (сжатие) и пропустить предварительный компрессор из уравнения? Вы также можете переключиться на более быстрый алгоритм шифрования. кроме этого: повторный бенчмарк без ssh-туннеля (например, с использованием / dev / null в качестве выходного приемника)
akira
В качестве sidenote, вы могли бы использовать разреженный файл ? Тогда нули не занимают места на диске. Ваше сжатие также будет быстрее, потому что нули будут интерполироваться драйвером файловой системы (и его не нужно будет читать с диска).
Ли-Аунг Ип
@ Li-aungYip Я так не думаю, поскольку "файлы" - это тома LVM.
Деватор
Ах я вижу. Продолжать!
Ли-Аунг Ип

Ответы:

14

Если вы не возражаете отойти от DEFLATE, lzopэто реализация LZO, которая предпочитает скорость перед степенью сжатия.

Игнасио Васкес-Абрамс
источник
1
или .. мгновенный: code.google.com/p/snappy
Акира
Спасибо, я нашел lzopсамый быстрый в моем сценарии. Это быстрее, чем pigzкак-то (вероятно, из-за партии 0).
Деватор
23

Хотя я лично еще не использовал его, я думаю, что использование параллельного gzip может немного ускорить процесс:

pigz, который означает параллельную реализацию gzip, является полностью функциональной заменой gzip, которая использует несколько процессоров и несколько ядер для сжатия при сжатии данных.

паскаль
источник
1
Я использую его регулярно и абсолютно рекомендую pigz, если доступно несколько ядер. Помимо изменения уровня сжатия, это, безусловно, самый доступный и простой способ ускорения сжатия.
jgrundstad
3
Сайт выглядит немного странно. Но не обманывайте себя, pigz написан одним из разработчиков gzip и zlib, Марком Адлером.
so_mv
Похоже, проект заброшен на данный момент.
AlexLordThorsen
Я предпочитаю думать о нем как о "стабильном". Он не обновляется часто, но он обновляется.
Алан Де Смет
7

Вы можете попробовать Parallel Gzip (Pascal связал его) или Parallel BZIP.
Теоретически, BZIP гораздо лучше подходит для текста, поэтому вы можете попробовать pbzip .

апаш
источник
2

Ваш диск ограничен в 30 МБ / с

Все компрессоры работают достаточно хорошо. Вы даже можете уменьшить передачу по сети, используя чуть медленнее, но вездесущий 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

Рассматривали ли вы rsync? Это делает контрольную сумму, а затем распаковывает только разницу.

Заб
источник
1
Мой диск не ограничен в 30 МБ / с. Я только что провел ваш тест: pigz -1: 1073741824 bytes (1.1 GB) copied, 8.6779 seconds, 124 MB/sи gzip -1: 1073741824 bytes (1.1 GB) copied, 11.6724 seconds, 92.0 MB/s. Я думал о rsync, но это проверило бы различия в файлах, и это, вероятно, не помогло бы, поскольку в большинстве случаев многое изменилось.
Деватор
Если вы переносите нули, посмотрите, насколько впечатляюще выглядит кодировка bzip2 в сравнении. Просто с какой стороны вы измеряете скорость ... 4 Мбит / с pigz может быть слишком много для обычной линии DSL ... Это становится еще хуже, если ваш диск такой быстрый.
ЗаБ
2

Re: lzop медленнее при его конфигурации std ... Тонкая настройка может половину времени. Но есть еще более быстрая замена: blosc:

https://github.com/FrancescAlted/blosc

Хм ... Время, которое потребовалось, чтобы опубликовать это и получить ответы, вероятно, по крайней мере удваивает любую экономию времени, которую вы получите, хотя ... Теперь извините меня, пока я перекомпилирую свое ядро, чтобы сбрить другие .1s из моего времени загрузки 2s.

technosaurus
источник