Найшвидша утиліта GZIP

18

Я шукаю найшвидшу gzip(або zip) утиліту. У мене об'єм LVM, який на 95% існує поза порожніх 0, так що стиснути це дуже просто. Я шукаю найшвидше рішення, і мені не дуже важливо стиснення, окрім 0's.

Мені відомо 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"(розмір блоку змінено на 16 М) час зменшується до real 18m22.442s!

linux compression gzip

— Девактор
джерело

1

Будьте уважні: користуватися timeтаким чином дещо несправедливо . Пропускна здатність використовуваного ДД pigzнижча, ніж інші два.

— Хенк

@ Deevator: дивлячись на таймінги, можна зробити висновок, що саме просування байтів через зашифрований тунель ssh є вузьким місцем. ви намагалися використати ssh з прапором "-c" (стиснення) і випустили попередній компресор з рівняння? ви також можете перейти до більш швидкого алгоритму шифрування. окрім цього: повторний показник без ssh-тунелю (наприклад, використання / dev / null як вихідної раковини)

— akira

Чи можете ви використати розріджений файл в якості бічного сигналу ? Тоді нулі не зайняли б місця на диску. Ваше стиснення також буде швидшим, тому що нулі будуть інтерпольовані драйвером файлової системи (і не доведеться читати з диска.)

— Li-aung Yip

@ Li-aungYip Я не думаю, що "файли" - це обсяги LVM.

— Девальватор

А, бачу. Продовжуй!

— Лі-Аун Іп

14

Якщо ви не заперечуєтесь від кроку від DEFLATE, lzopце реалізація LZO, яка сприяє швидкості над коефіцієнтом стиснення.

— Ігнасіо Васкес-Абрамс
джерело

1

або .. snappy: code.google.com/p/snappy

— akira

Дякую, я знайшов 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? Він робить контрольну суму, а потім gzipping лише різницю.

— ZaB
джерело

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 ... Це стає ще гірше, якщо ваш диск настільки швидкий.

— ZaB

2

Re: lzop, це повільніше в його std конфігурації ... Налаштування може половину часу. Але є ще швидша заміна, яка називається blocc:

https://github.com/FrancescAlted/blosc

Хм ... Час, який знадобився, щоб опублікувати це та отримати відповіді, мабуть, принаймні подвоїться за будь-яку економію часу, яку ви отримаєте, хоча ... Тепер вибачте, поки я перекомпілюю своє ядро, щоб поголити інший .1 з мого часу завантаження 2-х.

— технозавр
джерело