Время архивировать очень большие (100 ГБ) файлы

Мне приходится сжимать несколько очень больших файлов (80 ГБ), и я удивлен (нехваткой) скорости, которую демонстрирует моя система. Я получаю скорость конвертирования около 500 МБ / мин; используя top, я, кажется, использую один процессор примерно на 100%.

Я почти уверен, что это не (просто) скорость доступа к диску, поскольку создание tarфайла (именно так был создан файл 80G) заняло всего несколько минут (возможно, 5 или 10), но после более чем 2 часов моя простая команда gzip по-прежнему не выполнено.

В итоге:

tar -cvf myStuff.tar myDir/*

Потребовалось <5 минут, чтобы создать 87 G tar-файл

gzip myStuff.tar

Потребовалось два часа и 10 минут, чтобы создать почтовый файл 55G.

Мой вопрос: это нормально? Есть ли определенные варианты, gzipчтобы ускорить процесс? Будет ли быстрее объединить команды и использовать их tar -cvfz? Ссылка , которую я видел на pigz- Параллельная реализация GZip - но , к сожалению , я не могу установить программное обеспечение на компьютере я использую, так что это не вариант для меня. Смотрите, например, этот предыдущий вопрос .

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

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

ОБНОВИТЬ

Как и было обещано, я попробовал трюки, предложенные ниже: измените степень сжатия и измените место назначения файла. Я получил следующие результаты для tar, который был около 4.1GB:

flag    user      system   size    sameDisk
-1     189.77s    13.64s  2.786G     +7.2s 
-2     197.20s    12.88s  2.776G     +3.4s
-3     207.03s    10.49s  2.739G     +1.2s
-4     223.28s    13.73s  2.735G     +0.9s
-5     237.79s     9.28s  2.704G     -0.4s
-6     271.69s    14.56s  2.700G     +1.4s
-7     307.70s    10.97s  2.699G     +0.9s
-8     528.66s    10.51s  2.698G     -6.3s
-9     722.61s    12.24s  2.698G     -4.0s

Так что да, изменение флага со значения -6по умолчанию на самый быстрый -1дает мне ускорение на 30%, при этом (по моим данным) вряд ли что-либо изменится в размере zip-файла. Я использую тот же самый диск или другой, по сути, не имеет значения (мне пришлось бы запускать это несколько раз, чтобы получить статистическую значимость).

Если кому-то интересно, я сгенерировал эти временные тесты, используя следующие два сценария:

#!/bin/bash
# compare compression speeds with different options
sameDisk='./'
otherDisk='/tmp/'
sourceDir='/dirToCompress'
logFile='./timerOutput'
rm $logFile

for i in {1..9}
  do  /usr/bin/time -a --output=timerOutput ./compressWith $sourceDir $i $sameDisk $logFile
  do  /usr/bin/time -a --output=timerOutput ./compressWith $sourceDir $i $otherDisk $logFile
done

И второй скрипт ( compressWith):

#!/bin/bash
# use: compressWith sourceDir compressionFlag destinationDisk logFile
echo "compressing $1 to $3 with setting $2" >> $4
tar -c $1 | gzip -$2 > $3test-$2.tar.gz

Три вещи на заметку:

1. Использование, /usr/bin/timeа не time, поскольку встроенная команда bashимеет гораздо меньше параметров, чем команда GNU
2. Я не стал использовать эту --formatопцию, хотя это облегчило бы чтение файла журнала
3. Я использовал script-in-a-script, так timeкак казалось, что он работает только с первой командой в конвейерной последовательности (поэтому я сделал ее похожей на одну команду ...).

Со всем этим узнал, мои выводы

1. Ускорить вещи с -1флагом (принятый ответ)
2. Гораздо больше времени уходит на сжатие данных, чем на чтение с диска
3. Вложите капитал в более быстрое программное обеспечение сжатия ( pigzкажется хорошим выбором).
4. Если у вас есть несколько файлов для сжатия, вы можете поместить каждую gzipкоманду в свой собственный поток и использовать больше доступного процессора (бедняков pigz)

Спасибо всем, кто помог мне научиться всему этому!

Вы можете изменить скорость gzip, используя --fast --bestили, -#где # - это число от 1 до 9 (1 - самое быстрое, но с меньшим сжатием, 9 - самое медленное, но с большим сжатием). По умолчанию gzip работает на уровне 6.

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

Проблема в том, что gzip ограничен (как вы обнаружили) одним потоком.

Введите pigz , который может использовать несколько потоков для выполнения сжатия. Пример того, как использовать это:

tar -c --use-compress-program=pigz -f tar.file dir_to_zip

Существует хорошее резюме succint опции --use-компресс-программа над на партнерском сайте .

Кажется, я использую один процессор примерно на 100%.

Это подразумевает, что нет проблемы с производительностью ввода-вывода, но что сжатие использует только один поток (что будет в случае с gzip).

Если вам удастся достичь доступа / соглашения, необходимого для установки других инструментов, то 7zip также поддерживает несколько потоков, чтобы использовать преимущества многоядерных процессоров, хотя я не уверен, распространяется ли это на формат gzip, а также на его собственный.

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

Можно также использовать число доступных процессов в pigz, что обычно обеспечивает более высокую производительность, как показано в следующей команде

tar cf - каталог для архивирования | pigz -0 -p largenumber> mydir.tar.gz

Пример - tar cf - patha | pigz -0 -p 32> patha.tar.gz

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

Пример установки значения p = 32 в случае 32-процессорного компьютера помогает.

0 предназначен для самого быстрого сжатия PIGZ, поскольку он не сжимает архив и скорее фокусируется на скорости. Значение по умолчанию 6 для сжатия.