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


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

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

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


13
2018-03-01 01:29


Источник


Это действительно только сотни? Как в менее чем пару тысяч? - Zoredache
Еще несколько ... 475 576 на общую сумму 9,3 ГБ - Noodles
Это будет сосать, используя практически любой инструмент, который работает на уровне файловой системы. Я подозреваю, что если вы сделали какое-то профилирование, вы увидите значительное количество времени, затрачиваемое на вызов stat(), - Zoredache
Почему нет -aно -r? - kamae


Ответы:


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

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

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

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


13
2018-03-01 02:24



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


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

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

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


5
2018-03-01 01:39



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


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


1
2018-03-01 02:30



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


Добавить -v --progress в вашу командную строку rsync

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

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

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

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


0
2018-03-01 10:01





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

Подробности см. В моем ответе: https://serverfault.com/a/759421/80414


0
2018-02-24 11:01