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

16

У меня ежедневно генерируется около 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

— ана
источник

2

Если у вас есть несколько процессоров, и вы можете разбить их на несколько файлов tar, вы можете запустить несколько сжатий.

— Джефф Шаллер

@JeffSchaller, возможно ли получить несколько процессов bzip2, сжимающих разные файлы, но записывающих в один и тот же tar.bz2файл?

— ана

2

Файлы журнала генерируются на локальном диске перед перемещением в NAS? Если так, то сожмите, затем двигайтесь таким образом, вы отправляете только 15 ГБ данных по сети, а не 100 (перемещение), а затем 115 (100read + 15write) при сжатии. В качестве альтернативы может показаться, что вы связаны процессором с одним процессом bzip2, поэтому параллельное выполнение нескольких (по одному на процессор) может помочь (пока вы не достигнете предела ввода-вывода). Или используйте более простое сжатие (например, «gzip -1»). Это не сэкономит столько места на диске, но будет работать быстрее.

— Стивен Харрис

@Sukminder Я обязательно попробую это и увижу разницу в размерах. Благодарю.

— ана

Ваш topвывод показывает, что ваш однопоточный bzip2процесс использует одно ядро, но вы используете его в четырехъядерной системе (один процесс использует 100% ЦП -> 25.1%время ЦП в пользовательском пространстве, 74% бездействия). Таким образом, с небольшими изменениями вы можете идти в 4 раза быстрее, если что-то еще не станет узким местом. Внимательно прочитайте ответ Жиля. Рассмотрите возможность использования ЦП в той же коробке, что и диски, на которых хранятся данные, для сжатия. (Вы можете даже сжать некоторые из ваших файлов в одном блоке, другие - в другом, а затем архивировать, чтобы оба процессора использовались.)

— Питер Кордес

25

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

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

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

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

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

— Жиль "ТАК - перестань быть злым"
источник

4

«Если узким местом является дисковый ввод-вывод, вы ничего не можете сделать». Это, вероятно, верно, поскольку степень сжатия уже хороша, но в общем случае, когда ввод-вывод является узким местом, может стоить изучить использование большего количества ЦП для получения лучшей степени сжатия (с использованием других настроек сжатия или другого алгоритма). .. вы не можете реально уменьшить «Я» (потому что вам нужно прочитать все данные), но иногда вы можете значительно уменьшить «О» :-)

— psmears

1

Если вы запретите 7zделать «сплошной» архив или ограничите размер «сплошных» блоков, он будет параллельно запускать несколько потоков LZMA, IIRC. Данные файла журнала являются особым случаем для сжатия, потому что они, как правило, сильно избыточны (большое сходство между строками). Это, безусловно , стоит проверить gzip, bzip2и xzна лог - файлов конкретных ор, а не просто смотреть на общих тестах на сжатие , чтобы исключить любые варианты. Даже быстрые компрессоры стоит учесть , ( lzop, lz4, snappy).

— Питер Кордес

Предпочтительный компрессор LZMA в эти дни xz. Используйте tar -Jили --xzне --lzma. .lzmaсчитается "устаревшим" форматом файла . Несколько итераций форматов файлов для сжатия LZMA - это немного смущает, и что-то, что они должны были сделать правильно с первого раза. Но AFAIK сейчас в основном хорошо, и .xz не будет заменен еще одним форматом файла для того же потока сжатия.

— Питер Кордес

У 7z есть отличное сжатие и многопоточность, но из-за формата архива (нужен индекс или, возможно, ошибки?), Я не думаю, что его можно использовать в середине конвейера - он не будет использовать stdin и stdout в то же время

— Xen2050

Это было действительно полезно и проницательно. Моя команда решила, что работа над NFS была большим узким местом.

— ана

16

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

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

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

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

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

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

— МАЗС
источник

1

И если вы хотите использовать bzip2, вы можете использовать pbzip2или lbzip2.

— Радован Гарабик

2

Это ваш лучший ответ. Но сначала убедитесь, что ваш первый шаг находится в той же файловой системе, что и исходные файлы. В противном случае ваш «ход» - это действительно byte-copy-then-delete. В той же файловой системе перемещение - это перестановка ссылок файловой системы. Это на порядок быстрее. Для моих лог-файлов, размер которых составляет сотни гигабайт, PIGZ все изменил. Вы можете сказать, сколько параллельных потоков запустить. Пока ваш процессор имеет несколько ядер, я бы не стал тратить много времени на изучение. Вы, вероятно, захотите pigz в любом случае; Вы можете получить ускорение немедленно.

— Майк С

После того, как вы поиграете, посмотрите на выходы htop и iostat и понаблюдайте за производительностью вашей системы, если вы хотите продолжить исследование вашей системы. Но опять же, я больше не буду пытаться сжимать большие файлы без pigz. В современной многоядерной системе глупо не использовать ее. Это такая немедленная победа - вы увидите.

— Майк С

7

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

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

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

— Эмили Л.
источник

1

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

— ана

1

@anu Никакого контекста к вопросу не было дано, поэтому я предположил, что нет. И не могли бы вы сказать мне, откуда у вас номер тысячи утверждений? Мне кажется, ты только что это выдумал.

— Эмили Л.

Я проголосую за это. Это часто упускаемое из виду, но однажды замеченное, выдающееся решение многих жизненных проблем.

— jrw32982 поддерживает Монику

1

Ну ... теперь, когда я больше там не работаю, я могу по крайней мере раскрыть, что это было проблемой в Apple. Точнее, в отношении стека услуг, который обслуживает онлайн-магазин приложений ... так что да, тысячи утверждений - это реальность, потому что у них есть тысячи микросервисов, и каждый из них создает журналы, которые необходимо сжать, и им придется подписываться при изменении своих уровни ведения журналов и т. д. В любом случае ... мы нашли решение для этого внутреннего кстати ... которое в значительной степени эквивалентно параллельному gzip, который выгружается на другие микросервисы.

— ану

3

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

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

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

— Эрикс
источник

3

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

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

— п.д.о.
источник

Никогда не слышал об этом раньше, есть ли программа, которая, вероятно, уже установлена практически везде, где она используется, например, xz?

— Xen2050