Как ускорить сжатие файлов размером 100 ГБ с помощью gzip

We have 100+ GB files and while trying to perform gzip using below command, gzip is taking minimum 1-2 hours to get complete

С процессором (, взятым из комментария):Intel® Core™ i3 -2350M @ 2,30 ГГц , который имеет:

Количество ядер :2; Количество витков :4

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

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

Настройка сжатия по умолчанию -6, если я не ошибаюсь, вы можете нажать, например,-2:

gzip -2 file.txt

и сами сравните результаты. Дополнительные настройки см. на странице руководства .

ОБНОВЛЕНИЕ наpigz

Сегодня, 2021 -Июн -03, мне самому нужно было сжать довольно большой файл размером 256 ГБ(239 ГиБ ), и я кое-как протестировал gzip, bzip2, xz, и я обнаружил, что все они не могут в полной мере использовать возможности моего процессора(i7 -7700HQ)и работают быстро, что является нашей целью в этом вопросе и ответе.

В конце концов, я загрузилpigz(справочную страницу)с ее домашней страницы и скомпилировал ее, просто запустив make, а затем, поскольку я не предпочитал напрямую помещать ее на свой PATH, поэтому я создал псевдоним Bash для двоичного файла.

Было бы полезно отметить, как наблюдать за (возможно долгим )прогрессом:

Пример #1 (чтение подготовленного образа диска и запись gzipотредактированного файла в тот же каталог):

file=disk.img; pv < "$file" | pigz -2 > "$file".gz

Пример #2 (чтение диска напрямую и запись gzipотредактированного файла в текущем каталоге):

dev=/dev/nvme0n1; file=disk.img.gz; pv < "$dev" | pigz -9 > "$file"

Заключение

Теперь я рекомендую использовать pigz,реализация p arallel i gz ip для очень больших файлов.

Если вы используете gzip, вы используете в основном одно ядро ​​​​процессора (ну, некоторые части задачи, такие как чтение и запись данных, являются задачами ядра, и ядро ​​будет использовать другое ядро ​​). Взгляните на некоторые многоядерные -заменители gzip, например. MiGz(https://github.com/linkedin/migz)или Pigz (https://zlib.net/pigz/, для более подробного объяснения см. также, например,.https://medium.com/ngs-sh/pigz-a-faster-alternative-to-gzip-for-big-files-d5909e46d659).

Как указывали другие, gzipимеет одинарную -резьбу.

Если у вас есть несколько файлов для обработки, вы можете делать это параллельно:

find -type f -not -name '*.gz' -print0 | xargs -tr0n 1 -P$(nproc) gzip

• find:сканирование дерева файловой системы
• -type f:фильтр для обычных файлов
• -not:инвертировать следующий тест
  • -name '*.gz':любые уже сжатые файлы
• print0:вывести имя на стандартный вывод, за которым следует нулевой байт
• |труба в
• xargs:читать элементы из стандартного ввода и передавать их в качестве аргументов другой программе
• -t:записать запущенные команды в консоль
• -r:не выполнять никакую команду, если элементы отсутствуют
• -0:ожидать, что элементы будут разделены байтами NUL
• -n 1:дать один элемент каждому вызову
• -P...:запускать как можно больше команд параллельно
  • $(...):запустите эту команду и замените ее вывод
    • nproc:получить количество процессоров
• gzip:команда для каждого файла

Обратите внимание, что gzip по-прежнему довольно быстр как алгоритм, так что вы, вероятно, будете ограничены вводом-выводом, и в то же время сжатие не так велико. Если вы можете выбрать другой метод сжатия, вы можете вместо этого использовать xz, который сжимает намного лучше, но для этого требуется больше процессорного времени.

Теоретически xzможет выполнять внутреннее распараллеливание,но это дает немного худшее сжатие:

xz -T$(nproc) *.txt

Нужен ли вам gzip или можно использовать другие алгоритмы сжатия? zstandard и lzop значительно быстрее, чем gzip.

Ваше хранилище замедляет работу.

gzip file.txt

Предполагая, что размер file.txt составляет 100 ГБ, как вы сказали, для этого потребуется прочитать 100 ГБ из файла file.txt и несколько меньше записать в файл file.txt.gz в том же каталоге.

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

gzip -c file.txt > /mount/some_other_drive/file.txt.gz

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

Конечно, место назначения должно находиться на другом физическом томе и, желательно, на другом интерфейсе к компьютеру.

Вам необходимо проверить вероятность использования сжатого файла.

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

Если вы планируете часто распаковывать файл, то действительно ли стоит выполнять работу по сжатию/распаковке?

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

Узкими местами являются :скорость чтения файла, скорость его сжатия и скорость записи или передачи на целевой носитель, возможно, по сети.

Первое, что нужно сделать, это запустить команду gzip, наблюдая за выводом

vmstat 1

в другом терминале. Вы увидите, максимально ли загружен ваш процессор, сколько ядер он использует и сколько МБ/с он читает и записывает. Также следите за vmstat при копировании большого файла, чтобы получить представление о максимальной скорости чтения/записи вашего жесткого диска. Тогда вы узнаете, связана ли операция с процессором или io.

Вы также можете использовать

time gzip...

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

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

gzip -c file.txt | ssh user@ip "cat > destfile.gz"

Это заархивирует файл и передаст его за одну конвейерную операцию, что быстрее, чем два отдельных шага.

Теперь просмотрите vmstat и определите, связана ли операция с io -, сетью -или процессором -. Рекомендую установить утилиту "pv" и пользоваться вот так:

gzip -c file.txt | pv | ssh user@ip "cat > destfile.gz"

pv покажет, сколько МБ/с сжатых данных передается по сети. С помощью этого:

cat file.txt | pv | ssh user@ip "cat > destfile.gz"

Вы можете протестировать сеть HDD и записать на другой конец с помощью этого:

cat /dev/zero | pv | ssh user@ip "cat > destfile.gz"

...и с этим можно протестировать только сеть:

cat /dev/zero | pv | ssh user@ip "cat > /dev/null"

Теперь вы должны иметь гораздо лучшее представление о том, что его замедляет.Обратите внимание, что если вы используете общие сетевые ресурсы samba, вам также следует проверить пропускную способность :

cat /dev/zero | pv > /mnt/share/filename

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

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

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

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

Итак, откуда взялся этот 100-гигабайтный файл? Это не обычный размер файла... и это намекает на то, что вам действительно следует использовать rsync в дельта-режиме.

Сначала убедитесь, что ЦП или ввод-вывод не являются узким местом. Если по вводу-выводу, единственный способ улучшить — это читать с одного и записывать на другой диск, если он доступен. Ваш ЦП довольно слаб, я не вижу смысла пробовать какой-либо современный алгоритм сжатия, так как они, как правило, более интенсивно используют ЦП -. Поскольку ваш процессор имеет два ядра, вы можете разделить файл на две части и сжать их параллельно. Когда закончите, вы можете объединить эти два gz-файла обратно в один (— это удобная функция формата gzip ). Предполагается, что у вас достаточно ввода-вывода. Вы также можете поиграть с уровнями сжатия gzip до 1.