rsync очень медленный (в 8-10 раз) по сравнению с cp при копировании файлов из nfs-share в локальный каталог

rsync очень медленный (в 8-10 раз) по сравнению с cp при копировании файлов из nfs-share в локальный каталог

У меня есть свежеустановленный Ubuntu-сервер, который должен стать новым резервным сервером для нашего хранилища виртуальных машин. На сервере есть 4 сетевых карты, 2 из которых 10Gbit (фактически Intel x540-T2 с новейшим доступным драйвером), которые используются для подключения к SAN. Я смонтировал nfs-share локально и сравнил разницу в скорости при копировании каталога с ~30 файлами, около 15 образами виртуальных машин и соответствующими файлами журналов. Образы имеют размер от 8 ГБ до 600 ГБ.

С использованием:

cp -rf /mnt/nfs-share /backup-storage/

bmon показывает соответственно около 600 МБ/с.

С использованием

rsync -av /mnt/nfs-share /backup-storage/

bmon показывает несколько пакетов в первые секунды, останавливается примерно на 30 секунд, а затем нарастает примерно до 60-75 МБ/с. Загрузка ЦП составляет около 60%.

Что я должен/могу изменить, чтобы использовать rsyncс той же производительностью, что и cp?

решение1

Я думаю, что эти различия достаточно хорошо установлены между cpи rsync. См. эту статью в качестве справочного материала под названием:Взгляд на производительность rsync.

отрывок:
The four commands tested were:

    rsync $SRC $DEST
    echo $SRC | cpio -p $DEST
    cp  $SRC $DEST
    cat $SRC > $DEST/$SRC

The results for rsync, cpio, cp, and cat were:

user    sys     elapsed hog MiB/s   test
5.24    77.92   101.86  81% 100.53  cpio
0.85    53.77   101.12  54% 101.27  cp
1.73    59.47   100.84  60% 101.55  cat
139.69  93.50   280.40  83% 36.52   rsync

Я использую rsyncежедневно. Есть вещи, которые вы можете сделать, чтобы улучшить ситуацию.

Например, вы можете попробовать использовать -Wпереключатель:

-W, --whole-file            copy files whole (w/o delta-xfer algorithm)

Также я бы посоветовал убедиться, что у вас есть версии 3.x. rsyncБыли заметные улучшения, когда мы перешли на новые версии.

решение2

Чтобы rsync имел такую ​​же производительность, как cp, нужно написать его как «cp».

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

Есть ли какая-то причина, по которой вы хотите использовать rsync? Поскольку cp копирует "вслепую", вы увидите более высокую сырую производительность. Если для набора условий срабатывания используется механизм "дельта-передачи" rsync, вы увидите, что скорость передачи данных упадет, а использование ЦП возрастет примерно так, как вы сообщаете.

решение3

Для этого варианта использования rsync— излишне сложная машина. Если вас устраивает синхронизация на основе сравнения времени модификации файлов и размеров файлов, то на обоих концах следует собирать только метаданные файловой системы, сравнивать их, а измененные (или новые) файлы следует копировать (локальной) командой cp.

Вас может заинтересовать этот небольшой и простой синхронизатор, который делает следующее:Фитус/Залоха.ш

Он используется следующим образом:

$ Zaloha.sh --sourceDir="test_source" --backupDir="test_backup"

Для максимальной скорости фазы анализа вы можете пропустить генерацию скриптов восстановления: используйте опцию --noRestore. Кроме того, если у вас установлен fast mawk, дайте опцию --mawkдля его использования.

Zaloha.shсобирает метаданные файловой системы через findкоманды. Остался один вопрос о производительности findна вашем ресурсе NFS ...

Связанный контент