bzip2 слишком медленный. Несколько ядер доступны

31

Я запускаю эту команду:

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

Это занимает слишком много времени. Я смотрю на процессы с top. Процесс bzip2 занимает около 95% и занимает 5% одного ядра. waЗапись низка. Это означает, что диск не является узким местом.

Что я могу сделать, чтобы увеличить производительность?

Возможно, пусть bzip2 использует больше ядер. Сервер имеет 16 ядер.

Или использовать альтернативу bzip2?

Что я могу сделать, чтобы увеличить производительность?

performance postgresql gzip

— guettli
источник

8

Если вам не нужен bzip2 по унаследованным причинам, мой личный опыт показывает, что xz дает лучшее сжатие / время, чем bzip2. Он также поддерживает многопоточность, если вы получаете достаточно новую программу, и позволяет масштабировать время и использование памяти от gzipish до массового в зависимости от того, что вы хотите.

— Перкинс,

6

"pigz" - это еще один вариант - он производит вывод gzip, а не вывод bzip2. И в основном все понимает gzip.

— Кригги

Вы можете попробовать зашифровать его симметрично с помощью GnuPG со сжатием bzip2; он кажется удивительно быстрым по сравнению с простым сжатием, по неизвестной причине, даже с самым высоким уровнем сжатия. Вполне возможно, что алгоритм может быть быстрее, чем эффективность моей обычной программы сжатия, которая основана на графическом интерфейсе.

— Шуле

2

Вы не указали требования вашего альтернативного алгоритма. Bzip2 разделяется. Это важно для тебя?

— Мартин Смит

7

« Что я могу сделать, чтобы увеличить производительность? » - не сжимать ли это? Вы на самом деле не говорите, что вам это нужно сжать, и неделание всегда быстрее, чем выполнение работы. Сделайте диск узким местом.

— TessellatingHeckler

49

Существует множество алгоритмов сжатия, и 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(см. Комментарий gmathts) и zstd(комментарий Джонни) к таблице и отсортировано по скорости сжатия. lbzip2ставит bzip2семью обратно в управлении за счет сжатия в три раза быстрее, чем pbzip2с большим коэффициентом сжатия! zstdтакже выглядит разумно, но побежден и brotli (q1)в соотношении и в скорости.

Мой первоначальный вывод о gzipтом, что лучшим вариантом является равнина, начинает выглядеть почти глупо. Хотя для повсеместности, это все еще не может быть разбито;)

— marcelm
источник

1

Для таблицы с похожей ишей с гораздо большим количеством алгоритмов см. Mattmahoney.net/dc/text.html .

— Дугал

1

@ Достаточно справедливо. Мой тест на данных, аналогичных OP, хотя ( pg_dumpallвыходной), так что он, вероятно, немного более представительный :)

— marcelm

1

zstd - это еще один файл, которого нет в таблице - для сжатия наших файлов журнала я обнаружил, что одноядерный процесс zstd превосходит 16 ядер pbzip2 с сопоставимыми коэффициентами сжатия.

— Джонни

1

lz4немного быстрее и эффективнее, чем lzop, кстати. Он использует больше оперативной памяти, что актуально для встроенных систем.

— Даниэль Б

1

Если вы хотите протестировать многопоточные версии, вы можете попробовать zstd -T4тоже. Для очень быстрых настроек вы можете попробовать zstd -T4 -1, по zstdумолчанию -3, это, вероятно, настройка, которую вы тестировали.

— Cyan

37

Используйте pbzip2.

В руководстве сказано:

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

Он автоматически определяет количество имеющихся у вас процессоров и соответственно создает потоки.

— ThoriumBR
источник

Это нормально, если вы

— сжимаете

@camelccc Почему ты так говоришь? Я не считаю, что это так. Вам нужен быстрый производитель или большой буфер в канале перед ним для оптимальной производительности, но это в равной степени относится pixzи pigzк каналу.

— Майкл - sqlbot

Зависит от того, насколько большой он сжимает. Если у вас большой буфер, это нормально, как вы говорите, если вы пипетируете что-то намного больше, чем физический баран, я обнаружил, что все может стать намного интереснее. Как вы говорите, вероятно, верно для любого алгоритма сжатия, хотя.

— camelccc

4

bzip2 может использовать довольно много памяти, поэтому одновременная работа 16 рабочих bzip может потреблять нетривиальный оперативный памяти, более 1 ГБ. Кстати, lbzip2кажется, дает лучшую скорость, использование памяти и немного лучшее сжатие, чем pbzip2. Есть тесты здесь: vbtechsupport.com/1614

— gmatht

@gmatht lbzip2выглядит красиво! Я добавил это в свой ответ :)

— marcelm

8

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

Некоторые данные:

Сравнение алгоритмов сжатия Brotli, Deflate, Zopfli, LZMA, LZHAM и Bzip2
- например, на этом графике представлены цифры, показывающие, что Brotli примерно на 6-14 быстрее, чем Bzip2.
CanIUse.com: функция: brotli показывает поддержку Microsoft Edge, Mozilla Firefox, Google Chrome, Apple Safari, Opera (но не Opera Mini или Microsoft Internet Explorer).

Сравнение: Бротли против дефлята против Зопфли против Лзмы против Лжама против Бзип2
- Если вы ищете скорость сжатия, то, что вы ищете, это то, какие линии расположены прямо на этом графике. (Записи в верхней части этой диаграммы показывают жесткую степень сжатия. Более высокая = более узкая. Однако, если скорость сжатия является вашим приоритетом, вам следует уделить больше внимания тому, какие линии достигают дальше прямо на диаграмме.)
Сравнение: коэффициент сжатия и скорость сжатия для 7-Zip стандартных методов
ZStandard от Facebook - это еще один вариант, который стремится уменьшить количество битов, но также уделяет большое внимание хранению данных таким образом, чтобы уменьшить количество пропущенных прогнозов и тем самым повысить скорость. Его домашняя страница находится по адресу: Меньше и быстрее сжатие данных с ZStandard
У Lizard не такая высокая степень сжатия, как у Brotli или ZStandard, но он может быть несколько близок по степени сжатия и быть немного более быстрым (по крайней мере, в соответствии с этим графиком, который касается скорости, хотя он сообщает о декомпрессии)

Вы не упомянули операционную систему. Если Windows, 7-Zip с ZStandard (Releases) - это версия 7-Zip, которая была модифицирована для обеспечения поддержки использования всех этих алгоритмов.

— TOOGAM
источник

Интересно, я слышал brotliраньше, но я забыл об этом. Я добавил это в таблицу тестов в своем ответе! На самом деле я был немного разочарован его производительностью, за исключением настройки качества 1, где она обеспечивала ту же степень сжатия, что и gzipна гораздо более высокой скорости.

— marcelm

2

Используйте ZSTD . Если это достаточно хорошо для Facebook, то, вероятно, достаточно хорошо и для вас.

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

Теперь вы сжимаете дамп SQL, который настолько смущает, насколько это возможно. Даже самые плохие компрессоры хорошо зарекомендовали себя на таких данных.
Таким образом, вы можете работать zstdс более низким уровнем сжатия, который будет работать в десятки раз быстрее и при этом достигнет 95-99% такого же сжатия этих данных.

В качестве бонуса, если вы будете делать это часто и хотите потратить дополнительное время, вы можете zstdзаранее «тренировать» компрессор, что увеличивает как степень сжатия, так и скорость. Обратите внимание, что для того, чтобы тренировка работала хорошо, вам нужно кормить ее отдельными записями, а не целыми. Как работает этот инструмент, он ожидает много маленьких и несколько похожих образцов для обучения, а не один большой шарик.

— Damon
источник

еще лучше, используйте pzstd (параллельная версия) на многоядерных машинах

— borowis

1

Похоже, что настройка (уменьшение) размера блока может оказать существенное влияние на время сжатия.

Вот некоторые результаты эксперимента, который я провел на моей машине. Я использовал 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

Это было немного удивительное открытие, учитывая, что документация говорит:

Скорость сжатия и распаковки практически не зависит от размера блока

— Якуб Кукул
источник

Мой текущий фаворит - pbzip2. Ты тоже это пробовал? Этот вопрос касается среды, в которой доступно 16 ядер.

— Геттли

@guettli, к сожалению, я должен придерживаться bzip. Я использую его для заданий Hadoop, а bzip - одно из встроенных сжатий. В каком-то смысле это уже распараллелено.

— Якуб Кукул