Быстрое сжатие большого количества больших файлов

У меня ежедневно генерируется около 200 ГБ данных журнала, которые распределяются по 150 различным файлам журнала.

У меня есть скрипт, который перемещает файлы во временную папку и делает tar-bz2 во временной директории.

Я получаю хорошие результаты, поскольку журналы объемом 200 ГБ сжимаются примерно до 12-15 ГБ.

Проблема в том, что для сжатия файлов требуется вечность. Хрон задание выполняется в 2:30 утра ежедневно , и продолжает работать до 5: 00-6: 00 PM.

Есть ли способ улучшить скорость сжатия и завершить работу быстрее? Есть идеи?

Не беспокойтесь о других процессах и обо всем, место, где происходит сжатие, находится на NAS , и я могу запустить монтирование NAS на выделенной виртуальной машине и запустить скрипт сжатия оттуда.

Вот вывод top для справки:

top - 15:53:50 up 1093 days,  6:36,  1 user,  load average: 1.00, 1.05, 1.07
Tasks: 101 total,   3 running,  98 sleeping,   0 stopped,   0 zombie
Cpu(s): 25.1%us,  0.7%sy,  0.0%ni, 74.1%id,  0.0%wa,  0.0%hi,  0.1%si,  0.1%st
Mem:   8388608k total,  8334844k used,    53764k free,     9800k buffers
Swap: 12550136k total,      488k used, 12549648k free,  4936168k cached
 PID  USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
 7086 appmon    18   0 13256 7880  440 R 96.7  0.1 791:16.83 bzip2
7085  appmon    18   0 19452 1148  856 S  0.0  0.0   1:45.41 tar cjvf /nwk_storelogs/compressed_logs/compressed_logs_2016_30_04.tar.bz2 /nwk_storelogs/temp/ASPEN-GC-32459:nkp-aspn-1014.log /nwk_stor
30756 appmon    15   0 85952 1944 1000 S  0.0  0.0   0:00.00 sshd: appmon@pts/0
30757 appmon    15   0 64884 1816 1032 S  0.0  0.0   0:00.01 -tcsh

Первый шаг - выяснить, что является узким местом: дисковый ввод-вывод, сетевой ввод-вывод или процессор?

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

Если узким местом является сетевой ввод / вывод, запустите процесс сжатия на компьютере, на котором хранятся файлы: запуск его на компьютере с более мощным ЦП помогает, только если ЦП является узким местом.

Если узким местом является процессор, то первое, что нужно рассмотреть, - это использовать более быстрый алгоритм сжатия. Bzip2 не обязательно является плохим выбором - его основным недостатком является скорость распаковки - но вы можете использовать gzip и пожертвовать некоторым размером для скорости сжатия или попробовать другие форматы, такие как lzop или lzma. Вы также можете настроить уровень сжатия: по умолчанию bzip2 -9(максимальный размер блока, то есть максимальное сжатие, но также самое продолжительное время сжатия); установите переменную окружения BZIP2в значение, подобное тому, -3чтобы попробовать уровень сжатия 3. Этот поток и этот поток обсуждают общие алгоритмы сжатия; в частности, этот пост в блоге, цитируемый Деробертом, дает некоторые критерии, которые предполагают, что gzip -9илиbzip2с низким уровнем может быть хорошим компромиссом по сравнению с bzip2 -9. Этот другой тест, который также включает lzma (алгоритм 7zip, так что вы можете использовать 7zвместо него tar --lzma), предполагает, что lzmaна низком уровне можно достичь степени сжатия bzip2 быстрее. Почти любой выбор, кроме bzip2, улучшит время распаковки. Помните, что степень сжатия зависит от данных, а скорость сжатия зависит от версии программы сжатия, от того, как она была скомпилирована, и от процессора, на котором она выполняется.

Другой вариант, если узким местом является процессор, а у вас несколько ядер, - распараллелить сжатие. Есть два способа сделать это. Тот, который работает с любым алгоритмом сжатия, состоит в том, чтобы сжимать файлы отдельно (по отдельности или в нескольких группах) и использовать parallelдля параллельного запуска команд архивирования / сжатия. Это может уменьшить степень сжатия, но увеличивает скорость извлечения отдельного файла и работает с любым инструментом. Другой подход заключается в использовании параллельной реализации инструмента сжатия; эта тема перечисляет несколько.

Вы можете установить pigz, распараллелить gzip и использовать tar с многопоточным сжатием. Подобно:

tar -I pigz -cf file.tar.gz *

Где -Iвариант:

-I, --use-compress-program PROG
  filter through PROG

Конечно, если ваш NAS не имеет нескольких ядер / мощного процессора, вы все равно ограничены мощностью процессора.

Скорость жесткого диска / массива, на котором работает виртуальная машина и сжатие, также может быть узким местом.

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

Какие журналы вы генерируете? 200 ГБ в день звучит довольно много (если вы не Google или какой-то провайдер ...), учтите, что 1 МБ текста составляет около 500 страниц, поэтому вы генерируете эквивалент 100 миллионов страниц текста в день, Заполните библиотеку конгресса через неделю.

Посмотрите на свои данные журнала, если вы можете как-то уменьшить их и все же получить то, что вам нужно из журналов. Например, уменьшая уровень журнала или используя более короткий формат журнала. Или, если вы используете журналы для статистики, обрабатывайте статистику на лету и сохраняйте файл со сводкой, а затем фильтруйте журналы перед сжатием для хранения.

Вы можете уменьшить степень сжатия (с точки зрения экономии места), чтобы сделать его быстрее. Начнем с того, что bzip2 НАМНОГО медленнее, чем gzip, хотя он сжимает меньше. Вы также можете изменить уровень сжатия bzip2, gzip или большинства программ сжатия, чтобы увеличить размер.

Если вы не желаете обменивать размер скорости, вы все равно можете получить тот же размер или меньше, но при этом получить повышение скорости, используя компрессор, использующий LZMA (например, xz).

Если вы будете искать, вы найдете эталонные тесты, но лучше всего делать некоторые тесты с вашим собственным файлом на целевом оборудовании.

Если единственным требованием является быстрое сжатие , я очень рекомендую lz4 .

Он используется во многих местах, где скорость сжатия важнее, чем степень сжатия (например, файловые системы с прозрачным сжатием, такие как ZFS)