%20%D0%BF%D0%BE%20%D1%81%D1%80%D0%B0%D0%B2%D0%BD%D0%B5%D0%BD%D0%B8%D1%8E%20%D1%81%20cp%20%D0%BF%D1%80%D0%B8%20%D0%BA%D0%BE%D0%BF%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D0%B8%20%D1%84%D0%B0%D0%B9%D0%BB%D0%BE%D0%B2%20%D0%B8%D0%B7%20nfs-share%20%D0%B2%20%D0%BB%D0%BE%D0%BA%D0%B0%D0%BB%D1%8C%D0%BD%D1%8B%D0%B9%20%D0%BA%D0%B0%D1%82%D0%B0%D0%BB%D0%BE%D0%B3.png)
У меня есть свежеустановленный 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 ...