Как ускорить rsync для небольших файлов

15

Я пытаюсь перенести тысячи маленьких файлов с одного сервера на другой, используя следующую команду:

rsync -zr --delete /home/user/ user@10.1.1.1::backup

В настоящее время перевод занимает много времени (я не рассчитал это). Есть ли способ сделать это быстрее? Должен ли я использовать другой инструмент? Должен ли я использовать rsync через ssh, а не протокол rsync?

rsync

— лапша
источник

Это действительно только сотни? Как менее чем за пару тысяч?

— Zoredache

Несколько больше ... 475 576 на общую сумму 9,3 ГБ

— Лапша

Это будет отстой, используя практически любой инструмент, работающий на уровне файловой системы. Я подозреваю, что если бы вы сделали какое-то профилирование, вы бы увидели, что на звонки тратится значительное количество времени stat().

— Zoredache

Почему нет -aно -r?

— Камаэ

13

Вам нужно определить узкое место. Это не Rsync. Вероятно, это не ваша пропускная способность сети. Как сказал @Zoredache, это, скорее всего, огромное количество iops, генерируемых всеми stat()вызовами. Любой инструмент синхронизации будет нуждаться в статистике файлов. Во время синхронизации запустить, iostatчтобы проверить.

Так возникает вопрос; как оптимизировать стат? Два простых ответа:

получить более быструю дисковую подсистему (при необходимости на обоих хостах) и
настройте свою файловую систему (например, для монтирования ext3 noatimeи добавьте a dir_index).

Если по какой-то причине пределом является не размер iops диска, вы можете поэкспериментировать с разбиением дерева каталогов на несколько разных деревьев и запустить несколько rsyncs.

— Марк Вагнер
источник

1

Спасибо, я посмотрю в dir_index и посмотрю, как у меня получится (мы уже используем noatime). Кажется, что диск io является узким местом, но мы уже используем 15k дисков SAS в RAID 5. Следующим шагом будет SSD, но наша хостинговая компания пока не дает нам такой возможности.

— Лапша

5

Сжатие не очень полезно для небольших файлов (скажем, менее 100 байт). Для небольших файлов иногда сжатая версия может быть даже больше оригинальной. Попробуйте rsyncкоманду без -zфлага.

sshэто хорошо для безопасности, но не сделает передачу быстрее. Фактически, это замедлит передачу из-за необходимости шифрования / дешифрования.

rsyncможет показаться не быстрым при первом запуске, потому что есть много данных для передачи. Однако, если вы планируете периодически запускать эту команду, последующие запуски могут быть намного быстрее, так rsyncкак разумно не передавать файлы, которые не были изменены.

— unutbu
источник

Если вы просто используете rsyncклиент, он будет использовать SSH за кулисами. Вы должны изо всех сил отключить шифрование при использовании rsync. См .: stackoverflow.com/a/1821574/64911

— mlissner

1

Какую версию rsync вы используете? Все, что старше 3.0.0 (на обоих концах), не имеет функции добавочного списка файлов, что ускоряет большие передачи.

— devicenull
источник

Использование rsync 3.0.5 на обоих серверах.

— Лапша

1

Добавьте -v --progressк своей командной строке rsync

rsync выполняется в 2 этапа:

глубокий просмотр всех файлов на обеих платформах, чтобы сравнить их размер и дату
сделать фактический перевод

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

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

— Алекс Ф
источник

1

В случае, когда задействованы файловые системы ext3 или ext4, убедитесь, что в обеих функциях dir_index включена! Это утроило пропускную способность rsync в моем случае.

Подробности см. В моем ответе по адресу: /server//a/759421/80414

— alfonx
источник