[ТЕМА ЗАКРЫТА]
16.11.2011 12:08
Pyatak
 
У меня есть база, бэкап которой после сжатия занимает примерно 10Гб. Так вот, на компьютере с общей численностью ядер 8 архив создается примерно 12 часов. 7z вроде как должен по умолчанию уметь использовать все имеющиеся ядра. Или я ошибаюсь? Как можно ускорить процесс архивирования, пусть даже путем некоторого увеличения размера архива? Причем ускорить хотелось бы минимум раза в два.
16.11.2011 12:21
OlegON
 
Я так понял, что больше 2х ядер он не берет по любому. Ты строку приведи, с какой архивируешь... По любому можно уменьшить силу компрессии, когда доведешь до нуля, время архивирования будет равно времени копирования...
16.11.2011 12:45
Pyatak
 
Можно сказать что по умолчанию:
Код:
7z a archivename.7z /path/to/backup/files/*
У меня там 10 файлов. Получается, можно запустить параллельно три (или до восьми) копии 7z и каждому скормить свою часть файлов. :scratch_one-s_head:
16.11.2011 12:58
Pyatak
 
в выводе, кстати, пишет про 8 CPU:
Код:
7-Zip  4.58 beta  Copyright (c) 1999-2008 Igor Pavlov  2008-05-05
p7zip Version 4.58 (locale=ru_RU.UTF-8,Utf16=on,HugeFiles=on,8 CPUs)
16.11.2011 13:01
OlegON
 
Я бы паковал директорию. Рано или поздно добавится один файл и ...
И учти, что он прожорлив до памяти, это если несколько копий запускать.
В мане, кстати, есть пример
Цитата:
7z a -t7z -m0=lzma -mx=9 -mfb=64 -md=64m -ms=on archive.7z dir
попробуй взять его и потестируй с разными -mx=, двигаясь к нулю.
16.11.2011 13:02
OlegON
 
Цитата:
Pyatak в выводе, кстати, пишет про 8 CPU:
Ну да.. Это не значит, что он все 8 жрет :) Кстати, по таск-менеджеру можно заметить, сколько он процессоров под себя берет.
16.11.2011 14:17
Pyatak
 
При следующем архивировании поиграюсь с параметрами, а пока запустил всё-таки в три потока для пробы, судя по прогрессу, должен часов за 9 управиться, т.е. ускорение на 25% примерно.
16.11.2011 14:58
akonev
 
Цитата:
OlegON Я так понял, что больше 2х ядер он не берет по любому...
Это не его собственное ограничение, а формата lzma.

в bzip2, lzma2 он может запустить больше потоков. причем даже больше, чем ядер. где-то на их когда-то форуме проскакивало, что без этого процы могут не догрузиться.

-m0=LZMA2
16.11.2011 15:12
akonev
 
как-то так, если для скорости
Код:
7z a -mx=3 -mmt=8 -m0=LZMA2 archivename.7z /path/to/backup/files/*
-mx3 fast, по одному потоку на чанк
-mmt=8 - 8 потоков
16.11.2011 16:01
OlegON
 
да, забыл, вот в lzma оно вообще не параллелится, а в lzma2 - не больше 2х потоков. У меня по крайней мере не получилось. Только что проверил твою строку - 2 потока.
16.11.2011 18:33
Pyatak
 
Запущенный в три потока, архиватор справился чуть более, чем за 6 часов. Т.е. ускорение получилось около 2-ух раз.
Заметил сейчас, что у меня-то версия архиватора 4.х, а сейчас уже 9.х. В общем, обновил до 9.13 и запустил на тех же фалах пока так:
Код:
time 7z a -mmt=8 -m0=lzma2 archivename.7z /path/to/backup/files
чтобы посмотреть что даст смена алгоритма. Потом еще попробую -mx=3.
17.11.2011 09:22
Pyatak
 
С приведенными выше параметрами получилось вот что:
Код:
real	219m11.325s
user	1221m25.770s
sys	7m3.620s
т.е. 3 часа 39 минут, что в 3,3 раза быстрее исходного времени (12ч), вполне приемлемо.
17.11.2011 09:26
Stels
 
а мне интересно: объём данных какой ужимается?
17.11.2011 16:05
Pyatak
 
Попробовал еще так:
Код:
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 дисках.
18.11.2011 09:11
Pyatak
 
Запустил так:
Код:
7z a -mx=3 -mmt=16 -m0=lzma2
Получилась так:

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

размер архива при этом составил 14Гбайт
18.11.2011 11:10
akonev
 
дело вкуса каждого, но лично я бы предпочел терять 4гига, а не 3 часа.
хотя, конечно, тут уже от целей и схемы резервирования зависит.
02.01.2012 21:21
OlegON
 
-mmt=16 включен при работающей БД? Оно памяти выжирает нехило. У меня на рабочей машинке (4Гб) -mmt=2 завалилось по нехватке памяти, причем, не на старте. Что дает основания предполагать нестабильность бекапа, обязательно надо проверять выходной код.
Опции темы


Часовой пояс GMT +3, время: 12:41.

 

Форум сделан на основе vBulletin®
Copyright ©2000 - 2018, Jelsoft Enterprises Ltd. Перевод: zCarot и OlegON
В случае заимствования информации гипертекстовая индексируемая ссылка на Форум обязательна.