Pull to refresh

Сжатие файлов в многоядерную эру

Reading time 3 min
Views 3.1K
Original author: Jeff Atwood
Мы делали ежедневный большой бэкап для Stack Overflow, поэтому я снова немного поигрался со сжатием файлов.

На нашем сервере установлена последняя 64-битная версия 7zip (4.64). Я считаю, что двухядерного процессора вполне достаточно для настольной системы. Но с серверами всё просто: чем больше ядер, тем веселее! У сервера два четырёхядерных процессора — всего восемь ядер, поэтому я был немного разочарован, обнаружив, что ни RAR, ни 7zip не используют больше двух ядер.

Но, даже используя всего два ядра для сжатия, алгоритм 7zip невероятно эффективен, а в последнее время он стал довольно быстрым. Раньше я рекомендовал использовать RAR вместо Zip. Учитывая бесплатность, в отличие от RAR, и эффективность 7zip, теперь логичным будет выбрать именно его.

Вот парочка моих тестов по сжатию бэкап-файла базы данных размером 4.76 GB (использовался сервер с двумя четырёхядерным процессорами 2.5 ГГц Xeon E5420 на борту):
7zip fastest 5 min 14 MB/sec 973 MB
7zip fast 7 min 11 MB/sec 926 MB
7zip normal 34 min 2.5 MB/sec 752 MB
7zip maximum 41 min 2.0 MB/sec 714 MB
7zip ultra 48 min 1.7 MB/sec 698 MB
Если Вы думаете, что, раз 7zip показывает хорошие результаты при степенях сжатия maximum и ultra, то на ultra-plus результат будет и вовсе невероятным, вынужден Вас разочаровать. Есть определённые причины, по которым производители архиваторов по-умолчанию ставят степень сжатия normal. Если степень сжатия уменьшить, то размер выходного архива резко увеличивается, в то время как увеличение степени сжатия приведёт к сравнительно небольшому уменьшению размера выходного архива взамен на большое увеличение времени сжатия.

А теперь посмотрим, что произойдёт, если я переключу 7zip на использование bzip2:
7zip with bzip2 selected

Будем сжимать тот же файл(4.76 GB) на той же машине:
bzip2 fastest 2 min 36 MB/sec 1092 MB
bzip2 fast 2.5 min 29 MB/sec 1011 MB
bzip2 normal 3.5 min 22 MB/sec 989 MB
bzip2 maximum 7 min 12 MB/sec 987 MB
bzip2 ultra 21 min 4 MB/sec 986 MB
Почему bzip2 работает настолько быстрее, чем 7zip? Всё просто:
загрузка процессора при использовании 7zip
7zip multithreaded cpu usage
загрузка процессора при использовании bzip2
bzip2-multithreaded-cpu-usage.png

Bzip2 использует более двух ядер при распараллеливании. Я не знаю, сколько всего ядер он может использовать, но в выпадающем меню 7zip предлагает не больше шестнадцати ядер для bzip2. У нашего сервера восемь ядер, поэтому я столько и выбрал при проведении теста.

К сожалению, увеличение скорости работы bzip2 бессмысленно при высокой степени сжатия — разница между normal, maximum, и ultra составляет жалкие 0.06%. Алгоритм отлично масштабируется по времени, но практически не масштабируется по размеру выходного файла. Это очень странно, т.к. именно на уменьшение размера хотелось бы потратить время, выигранное распараллеливанием.

Но даже минимальное уменьшение размера может иметь смысл, в зависимости от обстоятельств:

итоговое время = время сжатия + n * (размер архива / скорость сети + время распаковки)

Например, если вы сжимаете файл, чтобы послать его по сети, n = 1, поэтому время сжатия ощутимо влияет на итоговое время. Если же вы хотите выложить файл в интернете, n велико, поэтому большое время сжатия будет слабо влиять на итоговое время.
В конце концов, медленные сети хорошо работают с медленными, но эффективными алгоритмами, в то время как для быстрых сетей нужны быстрые, но, возможно, менее эффективные алгоритмы.

С другой стороны, возможность сжать пятигигабайтный файл в пять раз за две минуты впечатляет. Поэтому меня всё никак не покидает мысль о том, как быстро бы работал алгоритм 7zip, если его переписать и распараллелить для работы болеее, чем на двух ядрах.
Tags:
Hubs:
+14
Comments 8
Comments Comments 8

Articles