Как ускорить rsync?

Question

[iBird Rose]

Есть папка с примерно 25кк картинками. Картинки маленькие. Просто количество большое.
Задача: Перенести ее на другой сервак.
rsync может только сканировать эти файлы по 12 часов, не говоря уже о копировании.
Можно ли как то ускорить работу?

Comments

[Igor Deyashkin]

С какими ключами вы запускаете rsync?
Вопрос именно об единоразовой операции? Вам потом не нужно будет их синхронизировать?
Какую версию rsync используете?
Все файлы лежат в одной директории или разбиты на поддиректории?
Какая ФС? Используется ли lvm?

[iBird Rose]

Igor Deyashkin,

С какими ключами вы запускаете rsync?

cat ../dirs.txt | parallel —progress —will-cite -j6 rsync -rv www@addr:~/path/{} ~/path/{}

Вопрос именно об единоразовой операции? Вам потом не нужно будет их синхронизировать?

Нужно синхронизировать хотя бы 1 раз, новые файлы уже дублируются в новую директорию, специально чтобы упростить синхронизацию, потому что невозможно будет потом столько ждать синхронизации, файлы пишутся десятками в секунду

Какую версию rsync используете?

3.1

Все файлы лежат в одной директории или разбиты на поддиректории?

3-х уровневая структура, например имел файл пользователя в ид 111222333, значит он будет лежат в 111/222/111222333.jpg то есть разбивка идёт по 3 символа (на вторых уровнях файлы тоже могут быть, если идентификатор маленький)

Какая ФС? Используется ли lvm?

ext4 - lvm нет, места на полную копию этих файлов тоже нет (эти файлы восстанавливаемые, по этому не бэкапятся, но их восстановление долгий процесс, поэтому нужно синхронизировать)

[АртемЪ]

А какой общий объем? Тут может быть дело банально в диске случайный доступ к большому количеству мелких файлов на HDD может занимать приличное время. Посмотрите что больше нагружено в момент работы rsync - процессор или диск.
Попробуйте zpaq - архиватор, дедупликатор, умеющий то же самое что и rsync - добавлять дельту.

[Igor Deyashkin]

В dirs.txt перечислены все директории (обоих уровней вложенности)?

Насколько я понимаю, в директории может быть максимум 1к файлов (+поддиректорий, если это директория верхнего уровня), верно?

Что вы имеете ввиду говоря о 12-ти часах на сканирование? Какое кол-во файлов обрабатывается в час? Насколько я понимаю,у вас запускаются отдельные процессы rsync на довольно небольшом количестве файлов каждый. Вы как-то суммируете их фазы сканирования? Вы запускали эту команду несколько раз? Перед этим вы убирали из dirs.txt уже синхронизированные директории?

Носитель - HDD?

Не может ли узким местом быть параллелизация сканирования? Мне думается, было бы эффективней делать это в один поток.

[Igor Deyashkin]

Опция `-v`, я так понимаю, была поставлена для проведения анализа и поиска узкого места? Непосредственно синхронизацию вы запускаете без нее?

Почему вы не используете опцию `--times`? Это упущение или так задумано? Если у одинаковых файлов может быть разное время и файлы можно считать одинаковыми в случае совпадения их размера (это ваш случай, как мне кажется) нужно использовать опцию `--size-only`. Мне пока не совсем понятно, есть ли уже какие-то из синхронизируемых файлов на целевой системе, но если есть - это может заметно влиять на производительность, так как rsync должен будет сравнить содержимое этих файлов чтобы удостовериться что они одинаковые.

[iBird Rose]

АртемЪ, Общий объём примерно 600гб

[iBird Rose]

Igor Deyashkin,

В dirs.txt перечислены все директории (обоих уровней вложенности)?

там только первый уровень, то есть 1 директорию сканит 1 процесс, в общем не более 6 процессов

Насколько я понимаю, в директории может быть максимум 1к файлов (+поддиректорий, если это директория верхнего уровня), верно?

1к файлов + 1к директорий в каждой папке возможно

Что вы имеете ввиду говоря о 12-ти часах на сканирование? ....

Запуская parallel он показывает сколько времени работал процесс, до этого я запускал команду rsync в один поток, то есть первые запуски parallel холостые, и просто сканируют папки чтобы убедиться что всё выгружено, в этот момент было показано что процесс работает порядка 240 секунд, следовательно если мы возьмем число папок в корне и число процессов то получим:
240 * 1000 / 60 / 60 = ~11 часов - просто на скан, без учета загрузки

Носитель - HDD?

Носитель - HDD, приёмник - SSD

Не может ли узким местом быть параллелизация сканирования? Мне думается, было бы эффективней делать это в один поток.

При считывании - может, но когда идёт загрузка, паралельная загрузка очень может ускорить процесс, учитывая что запуск планируется 1 раз (до полной синхронизации, а потом досинхрон из отдельной папки куда пишется всё свежее), это может быть полезным

[iBird Rose]

Igor Deyashkin, --size-only действительно помогло. процесс вместо 240 секунд отработал за 0,8 секунд)
и синхронизацию запускал с -v )))
напишите ответом. отмечу

Answer 1

[Igor Deyashkin]

В процессе выяснения деталей в комментариях к вопросу было найдено решение.

В данном случае синхронизация выполнялась без использования опции `--times`, которая сохраняет время модификации файла при синхронизации. При этом не была использована опция `--size-only`, благодаря которой файлы с одинаковыми размерами считаются одинаковыми вне зависимости от времени изменения.
И получается, что даты изменения у всех уже синхронизированных файлов отличаются, и rsync при повторном запуске считает эти файлы потенциально разными и считает их контрольные суммы, чтобы сравнить их по содержимому. На это и уходило время.

Добавление опции `--size-only` существенно сократило время анализа файлов перед началом передачи.
Хотя, на мой взгляд лучше вместо этого по умолчанию всегда использовать `--times` (в том числе в составе `-a`), если возможно.

Кроме того, была использована опция `-v`, которая выводит информацию о синхронизируемых файлах, что тоже могло замедлять процесс, хотя, скорее всего ,не значительно.

Answer 2

[Stalker_RED]

Если не надо сравниваь какие уже перенесены, то пакуй все в архивы (tar, gz) и перекачивай тем-же rsync'ом или scp.

Comments

[Radjah]

Тогда уж проще пайпом через ssh гнать сразу без записи на диск.