Быстрое сжатие большого количества больших файлов
Можно ли считать, что [
-exec ...] теперь поддерживается повсюду?Вариант
-exec ... '{}' ';', который обеспечивает ровно одно совпадение для каждой выполняемой команды, определенно ожидается, что теперь он будет поддерживаться повсюду, даже в системах unix, отличных от POSIX.Вариант
-exec ... '{}' +, я не уверен. Правда, он определен в POSIX-1 , поэтому определенно поддерживается во всех текущих системах POSIXy. Однако я не уверен, поддерживают ли его все старые системы unix (все еще используемые).Есть ли какие-либо веские причины защищать xargs вместо этого в случаях, когда можно использовать [
-exec ... '{}' +]?Нет, не совсем. Зачем использовать две команды, если одной достаточно?
Проблема в том, что если единственный известный вам инструмент - это молоток, все проблемы будут похожи на гвозди. Мощь
xargsзаключается в том, что вы можете управлять списком совпадений с помощьюbash,sed,awkи т. Д. , перед выполнением команды (команд), действующей в списке.(На практике это требует, чтобы имена файлов и каталогов не содержали в себе символов новой строки. Bash и GNU find, sed, awk и xargs поддерживают нулевой символ
\ 0в качестве символа разделитель, чтобы они могли без проблем манипулировать всеми возможными именами файлов.)
Первый шаг - выяснить, что является узким местом: дисковый ввод-вывод, сетевой ввод-вывод или ЦП?
Если узким местом является дисковый ввод-вывод, тут мало что можно сделать. Убедитесь, что диски не обслуживают много параллельных запросов, так как это может только снизить производительность.
Если узким местом является сетевой ввод-вывод, запустите процесс сжатия на машине, где хранятся файлы: запуск его на машине с более мощным ЦП помогает только в том случае, если ЦП является узким местом.
Если узким местом является ЦП, то в первую очередь следует рассмотреть возможность использования более быстрого алгоритма сжатия. 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).
Вы найдете тесты производительности, если будете искать, но лучше всего провести несколько тестов с вашим собственным файлом на целевом оборудовании.