bzip2 занадто повільно. Існує кілька ядер

Я виконую цю команду:

pg_dumpall | bzip2 > cluster-$(date --iso).sql.bz2

Це займає занадто багато часу. Я дивлюся на процеси с top. Процес bzip2 займає близько 95% і постгреси 5% одного ядра. waЗапис низька. Це означає, що диск не є вузьким місцем.

Що я можу зробити для підвищення продуктивності?

Можливо, нехай bzip2 використовує більше ядер. Сервери мають 16 ядер.

Або використовувати альтернативу bzip2?

Що я можу зробити для підвищення продуктивності?

Навколо існує багато алгоритмів стиснення та bzip2 це один із повільніших. Рівнина, gzipяк правило, значно швидше, як правило, не набагато гірше стискається. Коли швидкість є найважливішою, lzopце моя улюблена. Погана компресія, але о так швидко.

Я вирішив повеселитися і порівняв кілька алгоритмів, включаючи їх паралельні реалізації. Вхідний файл - це вихідpg_dumpall команди на моїй робочій станції, файл SQL 1913 Мб. Апаратне забезпечення - це старший чотирьохядерний i5. Часи - це настінні годинники просто стиснення. Паралельні реалізації встановлені для використання всіх 4 ядер. Таблиця, відсортована за швидкістю стиснення.

Algorithm     Compressed size        Compression          Decompression

lzop           398MB    20.8%      4.2s    455.6MB/s     3.1s    617.3MB/s
lz4            416MB    21.7%      4.5s    424.2MB/s     1.6s   1181.3MB/s
brotli (q0)    307MB    16.1%      7.3s    262.1MB/s     4.9s    390.5MB/s
brotli (q1)    234MB    12.2%      8.7s    220.0MB/s     4.9s    390.5MB/s
zstd           266MB    13.9%     11.9s    161.1MB/s     3.5s    539.5MB/s
pigz (x4)      232MB    12.1%     13.1s    146.1MB/s     4.2s    455.6MB/s
gzip           232MB    12.1%     39.1s     48.9MB/s     9.2s    208.0MB/s
lbzip2 (x4)    188MB     9.9%     42.0s     45.6MB/s    13.2s    144.9MB/s
pbzip2 (x4)    189MB     9.9%    117.5s     16.3MB/s    20.1s     95.2MB/s
bzip2          189MB     9.9%    273.4s      7.0MB/s    42.8s     44.7MB/s
pixz (x4)      132MB     6.9%    456.3s      4.2MB/s     7.9s    242.2MB/s
xz             132MB     6.9%   1027.8s      1.9MB/s    17.3s    110.6MB/s
brotli (q11)   141MB     7.4%   4979.2s      0.4MB/s     3.6s    531.6MB/s

Якщо 16 ядер вашого сервера простоюють, щоб усі вони могли бути використані для стиснення, pbzip2 ймовірно, ви отримаєте дуже значне прискорення. Але вам потрібна ще більша швидкість, і ви можете терпіти ~ 20% більше файлів, gzipмабуть, найкраща ставка.

Оновлення: я додав brotli(див. Відповідь TOOGAMs) до таблиці. brotliНалаштування якості стиснення з має дуже великий вплив на ступінь стиснення і швидкості, так що я додав три параметра ( q0, q1і q11). За замовчуванням є q11, але він надзвичайно повільний і все ж гірший, ніжxz . q1виглядає дуже добре, хоча; той же коефіцієнт стиснення gzip, але в 4-5 разів швидше!

Оновлення: Додано lbzip2(див. Коментар до гматтів) та zstd(коментар Джонні) до таблиці та сортувало його за швидкістю стиснення. lbzip2ставить bzip2сім'ю назад в управлінні за рахунок стиснення в три рази швидше, ніжpbzip2 ніж з великим коефіцієнтом стиснення! zstdтакож виглядає розумним, але його б'ють і brotli (q1)в співвідношенні, і в швидкості.

Мій початковий висновок про те, що звичайна gzipнайкраща ставка, починає виглядати майже нерозумно. Хоча щодо повсюдності, її все одно не можна перемогти;)

Використовуйте pbzip2.

Керівництво каже:

pbzip2 - паралельна реалізація компресора файлів сортування файлів bzip2, яка використовує pthreads і досягає майже лінійного прискорення на машинах SMP. Вихід цієї версії повністю сумісний з bzip2 v1.0.2 або новішою (тобто: все, що стискається з pbzip2, може бути декомпресоване bzip2).

Він автоматично визначає кількість наявних у вас процесорів і відповідно створює потоки.

• Google brotli - це новий формат, який останнім часом отримав широку підтримку в браузерах, оскільки він має вражаючу компресію, вражаючу швидкість і, можливо, найбільш вражаючу комбінацію / баланс обох цих функцій.

  Деякі дані:

  Порівняння алгоритмів стиснення Brotli, Deflate, Zopfli, LZMA, LZHAM і Bzip2

  • Наприклад, номери цього звіту на діаграмі, що показують, що Бротлі приблизно на 6-14 швидший, ніж Bzip2.

  CanIUse.com: особливість: brotli демонструє підтримку Microsoft Edge, Mozilla Firefox, Google Chrome, Apple Safari, Opera (але не Opera Mini чи Microsoft Internet Explorer).

  Порівняння: Brotli vs deflate vs zopfli vs lzma vs lzham vs bzip2

  • Якщо ви шукаєте швидкість стиснення, то те, що ви шукаєте, - це які лінії розташовані далі на цьому графіку. (Записи у верхній частині цього діаграму показують жорсткий коефіцієнт стиснення. Вищий = жорсткіший. Однак, якщо швидкість стиснення є вашим пріоритетом, тоді вам потрібно буде приділити більше уваги тому, які рядки досягають праворуч на графіку.)
  Порівняння: коефіцієнт стиснення та швидкість стиснення для методів 7-Zip ZStandard

• ZStandard Facebook є ще одним варіантом, який прагне скоротити біти, але також приділяє велику увагу збереженню даних таким чином, що зменшує пропущені прогнози, тим самим забезпечуючи більш високу швидкість. Його домашня сторінка знаходиться за адресою: Менше та швидше стиснення даних за допомогою ZStandard
• Ящірка не отримує настільки високу компресію, як Brotli або ZStandard, але може бути дещо близькою за коефіцієнтом стиснення і бути трохи швидшою (принаймні, відповідно до цієї діаграми, яка стосується швидкості, хоча це повідомляє про декомпресію)

Ви не згадали про операційну систему. Якщо Windows, 7-Zip з ZStandard (випуски) - це версія 7-Zip, яка була модифікована, щоб забезпечити підтримку використання всіх цих алгоритмів.

Використовуйте zstd . Якщо це досить добре для Facebook, це, мабуть, досить добре і для вас.

Якщо серйозніше зазначити, це насправді досить добре . Я використовую його для всього зараз, оскільки він просто працює, і він дозволяє торгувати швидкістю для співвідношення у великих масштабах (найчастіше, швидкість має значення більше, ніж розмір, оскільки зберігання дешеве, але швидкість - вузьке місце).
На рівнях стиснення, які досягають порівнянного загального стиснення, як bzip2, це значно швидше, і якщо ви готові заплатити трохи додаткових процесорів, ви можете майже досягти результатів, аналогічних LZMA (хоча тоді це буде повільніше, ніж bzip2). При плавно гірших коефіцієнтах стиснення це набагато, набагато швидше, ніж bzip2 або будь-яка інша основна альтернатива.

Тепер ви стискаєте дамп SQL, який так само прикро тривіально стискати, як це може бути. Навіть найбідніші компресори добре оцінюють такі дані.
Таким чином, ви можете запустити zstdз нижчим рівнем стиснення, який буде працювати в десятки разів швидше і все одно досягти 95-99% тієї ж компресії на цих даних.

Як бонус, якщо ви будете робити це часто і хочете вкласти додатковий час, ви можете «навчити» zstdкомпресор достроково, що збільшує як коефіцієнт стиснення, так і швидкість. Зауважте, що для того, щоб добре працювати, вам потрібно буде подавати в нього окремі записи, а не всю справу. Те, як інструмент працює, очікує багато дрібних і дещо подібних зразків для тренувань, а не одну величезну крапку.

Схоже, що регулювання (опускання) розміру блоку може мати значний вплив на час стиснення.

Ось кілька результатів експерименту, який я зробив на своїй машині. Я використовував timeкоманду для вимірювання часу виконання. input.txtце текстовий файл ~ 250 Мб, що містить довільні записи json.

Використання типового (найбільшого) розміру блоку ( --bestпросто вибирає поведінку за замовчуванням):

# time cat input.txt | bzip2 --best > input-compressed-best.txt.bz

real    0m48.918s
user    0m48.397s
sys     0m0.767s

Використання найменшого розміру блоку ( --fastаргумент):

# time cat input.txt | bzip2 --fast > input-compressed-fast.txt.bz

real    0m33.859s
user    0m33.571s
sys     0m0.741s

Це було трохи дивовижним відкриттям, враховуючи, що документація говорить:

Розмір блоку практично не впливає на швидкість стиснення та декомпресії