3

Использование rsync для копирования некоторых больших файлов (по 24 МБ каждый):

bronger@steed:/tmp$ time rsync -r root@my_nas::media/distortion .
Password: 

real    0m18.128s
user    0m2.600s
sys     0m5.756s

(Выделите 2 секунды для ввода пароля.) Теперь то же самое с NFS:

bronger@steed:/tmp$ time cp -a /mnt/media/distortion .

real    0m5.569s
user    0m0.036s
sys     0m2.128s

Как это может быть? Сжатие или шифрование не используются, однако загрузка ЦП на стороне сервера составляет 100%. Это NAS с медленным процессором ARM, но даже в этом случае любое действие копирования должно быть ограничено вводом-выводом.

Файл rsyncd.conf говорит:

pid file = /var/run/rsyncd.pid
lock file = /var/run/rsync.lock
use chroot = no

[media]
path = /volume1/media 
comment = Main volume                      
fake super = yes                         
uid = 1000
gid = 1000    
read only = no
list = yes     
charset = utf-8  
auth users = root                 
secrets file = /etc/rsyncd.secrets

2 ответа2

3

rsync медленнее, чем NFS, если rsync привязан к процессору. rsync гораздо менее эффективен, чем NFS, когда речь идет о простой передаче данных. В моем случае rsync потребляла 100% ЦП, в то время как NFS требовалось только 20%, а NFS был все еще быстрее в 3 раза. Это означает, что Rsync потребляется 15 раз (!) больше ресурсов процессора, чем NFS для того же объема сетевого трафика. Я передал большие файлы.

Наилучшим подходом в таком сценарии является монтирование каталога с NFS на более быстрой машине и локальное копирование файлов с помощью rsync.

Смотрите статью LWN о ком-то с подобной проблемой.

1

RSync собирается сделать свою домашнюю работу, прежде чем начать, чтобы убедиться, что копирование является даже обязательным требованием.

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

Всё ещё ищете ответ? Посмотрите другие вопросы с метками .