7z, ускорение : Операционные системы и программное обеспечение

Pyatak · █ 16.11.2011 18:33

Запущенный в три потока, архиватор справился чуть более, чем за 6 часов. Т.е. ускорение получилось около 2-ух раз.
Заметил сейчас, что у меня-то версия архиватора 4.х, а сейчас уже 9.х. В общем, обновил до 9.13 и запустил на тех же фалах пока так:

Код:

time 7z a -mmt=8 -m0=lzma2 archivename.7z /path/to/backup/files

чтобы посмотреть что даст смена алгоритма. Потом еще попробую -mx=3.

Pyatak · █ 17.11.2011 09:22

С приведенными выше параметрами получилось вот что:

Код:

real	219m11.325s
user	1221m25.770s
sys	7m3.620s

т.е. 3 часа 39 минут, что в 3,3 раза быстрее исходного времени (12ч), вполне приемлемо.

Stels · █ 17.11.2011 09:26

а мне интересно: объём данных какой ужимается?

Pyatak · █ 17.11.2011 16:05

Попробовал еще так:

Код:

time 7z a -mmt=16 -m0=lzma2 archivename.7z /path/to/backup/files

получилось вот что:

Код:

real	176m44.712s
user	1257m20.410s
sys	7m13.070s

Т.е. чуть менее трех часов. Где-то в интернете нашел, что число потоков равное двукратному числу ядер - дает самое быстрое сжатие. Как оказалось, практика подтверждает.

В папке 10 файлов общим объемом 104,7Гб
сжимаются до 10,17Гб
файлы и архив находятся на физически разных S-ATA дисках.

Pyatak · █ 18.11.2011 09:11

Запустил так:

Код:

7z a -mx=3 -mmt=16 -m0=lzma2

Получилась так:

real 32m26.599s
user 208m32.760s
sys 2m24.410s

размер архива при этом составил 14Гбайт

akonev · █ 18.11.2011 11:10

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

OlegON · █ 02.01.2012 21:21

-mmt=16 включен при работающей БД? Оно памяти выжирает нехило. У меня на рабочей машинке (4Гб) -mmt=2 завалилось по нехватке памяти, причем, не на старте. Что дает основания предполагать нестабильность бекапа, обязательно надо проверять выходной код.