Мы делали ежедневный большой бэкап для Stack Overflow, поэтому я снова немного поигрался со сжатием файлов.
На нашем сервере установлена последняя 64-битная версия 7zip (4.64). Я считаю, что двухядерного процессора вполне достаточно для настольной системы. Но с серверами всё просто: чем больше ядер, тем веселее! У сервера два четырёхядерных процессора — всего восемь ядер, поэтому я был немного разочарован, обнаружив, что ни RAR, ни 7zip не используют больше двух ядер.
Но, даже используя всего два ядра для сжатия, алгоритм 7zip невероятно эффективен, а в последнее время он стал довольно быстрым. Раньше я рекомендовал использовать RAR вместо Zip. Учитывая бесплатность, в отличие от RAR, и эффективность 7zip, теперь логичным будет выбрать именно его.
Вот парочка моих тестов по сжатию бэкап-файла базы данных размером 4.76 GB (использовался сервер с двумя четырёхядерным процессорами 2.5 ГГц Xeon E5420 на борту):
Если Вы думаете, что, раз 7zip показывает хорошие результаты при степенях сжатия maximum и ultra, то на ultra-plus результат будет и вовсе невероятным, вынужден Вас разочаровать. Есть определённые причины, по которым производители архиваторов по-умолчанию ставят степень сжатия normal. Если степень сжатия уменьшить, то размер выходного архива резко увеличивается, в то время как увеличение степени сжатия приведёт к сравнительно небольшому уменьшению размера выходного архива взамен на большое увеличение времени сжатия.
А теперь посмотрим, что произойдёт, если я переключу 7zip на использование bzip2:
Будем сжимать тот же файл(4.76 GB) на той же машине:
Почему bzip2 работает настолько быстрее, чем 7zip? Всё просто:
загрузка процессора при использовании 7zip
загрузка процессора при использовании bzip2
Bzip2 использует более двух ядер при распараллеливании. Я не знаю, сколько всего ядер он может использовать, но в выпадающем меню 7zip предлагает не больше шестнадцати ядер для bzip2. У нашего сервера восемь ядер, поэтому я столько и выбрал при проведении теста.
К сожалению, увеличение скорости работы bzip2 бессмысленно при высокой степени сжатия — разница между normal, maximum, и ultra составляет жалкие 0.06%. Алгоритм отлично масштабируется по времени, но практически не масштабируется по размеру выходного файла. Это очень странно, т.к. именно на уменьшение размера хотелось бы потратить время, выигранное распараллеливанием.
Но даже минимальное уменьшение размера может иметь смысл, в зависимости от обстоятельств:
Например, если вы сжимаете файл, чтобы послать его по сети, n = 1, поэтому время сжатия ощутимо влияет на итоговое время. Если же вы хотите выложить файл в интернете, n велико, поэтому большое время сжатия будет слабо влиять на итоговое время.
В конце концов, медленные сети хорошо работают с медленными, но эффективными алгоритмами, в то время как для быстрых сетей нужны быстрые, но, возможно, менее эффективные алгоритмы.
С другой стороны, возможность сжать пятигигабайтный файл в пять раз за две минуты впечатляет. Поэтому меня всё никак не покидает мысль о том, как быстро бы работал алгоритм 7zip, если его переписать и распараллелить для работы болеее, чем на двух ядрах.
На нашем сервере установлена последняя 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 на использование bzip2:
Будем сжимать тот же файл(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 |
загрузка процессора при использовании 7zip
загрузка процессора при использовании bzip2
Bzip2 использует более двух ядер при распараллеливании. Я не знаю, сколько всего ядер он может использовать, но в выпадающем меню 7zip предлагает не больше шестнадцати ядер для bzip2. У нашего сервера восемь ядер, поэтому я столько и выбрал при проведении теста.
К сожалению, увеличение скорости работы bzip2 бессмысленно при высокой степени сжатия — разница между normal, maximum, и ultra составляет жалкие 0.06%. Алгоритм отлично масштабируется по времени, но практически не масштабируется по размеру выходного файла. Это очень странно, т.к. именно на уменьшение размера хотелось бы потратить время, выигранное распараллеливанием.
Но даже минимальное уменьшение размера может иметь смысл, в зависимости от обстоятельств:
итоговое время = время сжатия + n * (размер архива / скорость сети + время распаковки)Например, если вы сжимаете файл, чтобы послать его по сети, n = 1, поэтому время сжатия ощутимо влияет на итоговое время. Если же вы хотите выложить файл в интернете, n велико, поэтому большое время сжатия будет слабо влиять на итоговое время.
В конце концов, медленные сети хорошо работают с медленными, но эффективными алгоритмами, в то время как для быстрых сетей нужны быстрые, но, возможно, менее эффективные алгоритмы.
С другой стороны, возможность сжать пятигигабайтный файл в пять раз за две минуты впечатляет. Поэтому меня всё никак не покидает мысль о том, как быстро бы работал алгоритм 7zip, если его переписать и распараллелить для работы болеее, чем на двух ядрах.
