Почему Rsync быстрее, чем NFS?

Несколько дней назад я заметил кое-что довольно странное (по крайней мере, для меня). Я запустил rsync, скопировав те же данные и впоследствии удалив их в NFS mount, под названием /nfs_mount/TEST. Это /nfs_mount/TESTразмещено / экспортировано из nfs_server-eth1. MTU на обоих сетевых интерфейсах - 9000, коммутатор между ними также поддерживает большие кадры. Если я это сделаю, rsync -av dir /nfs_mount/TEST/я получу скорость передачи по сети X Мбит / с. Если я это сделаю, rsync -av dir nfs_server-eth1:/nfs_mount/TEST/я получу скорость передачи по крайней мере 2X Мбит / с. У меня есть варианты монтирования NFS nfs rw,nodev,relatime,vers=3,rsize=1048576,wsize=1048576,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,mountvers=3,mountproto=tcp.

Итог: обе передачи проходят через одну и ту же сетевую подсеть, одни и те же провода, одни и те же интерфейсы, считывают одни и те же данные, записывают в один и тот же каталог и т. Д. Разница только в одном - через NFSv3, а другая - в rsync.

Клиент Ubuntu 10.04, сервер Ubuntu 9.10.

Почему rsync намного быстрее? Как заставить NFS соответствовать этой скорости?

Благодарность

Изменить: обратите внимание, я использую rsync для записи в общий ресурс NFS или SSH на сервер NFS и записи там локально. Оба раза я делаю rsync -av, начиная с чистого каталога назначения. Завтра попробую с обычной копией.

Edit2 (дополнительная информация): Размер файла варьируется от 1 КБ до 15 МБ. Файлы уже сжаты, я пытался сжать их дальше, но безуспешно. Я сделал tar.gzфайл из этого dir. Вот образец:

• rsync -av dir /nfs_mount/TEST/ = самая медленная передача;
• rsync -av dir nfs_server-eth1:/nfs_mount/TEST/= самая быстрая rsync с включенными большими кадрами; без больших кадров это немного медленнее, но все же значительно быстрее, чем непосредственно в NFS;
• rsync -av dir.tar.gz nfs_server-eth1:/nfs_mount/TEST/ = примерно так же, как его эквивалент не tar.gz;

Тесты с cpи scp:

• cp -r dir /nfs_mount/TEST/= немного быстрее чем, rsync -av dir /nfs_mount/TEST/но все еще значительно медленнее чем rsync -av dir nfs_server-eth1:/nfs_mount/TEST/.
• scp -r dir /nfs_mount/TEST/= самый быстрый в целом, немного преодолевает rsync -av dir nfs_server-eth1:/nfs_mount/TEST/;
• scp -r dir.tar.gz /nfs_mount/TEST/ = примерно так же, как его эквивалент не tar.gz;

Вывод, основанный на этих результатах: Для этого теста нет существенной разницы, если использовать большой файл tar.gz или много маленьких. Jumbo-кадры также не имеют большого значения. cpи scpбыстрее, чем их соответствующие rsync -avэквиваленты. Запись непосредственно в экспортированный общий ресурс NFS значительно медленнее (как минимум в 2 раза), чем запись в тот же каталог по SSH, независимо от используемого метода.

Различия между ними cpи rsyncне актуальны в этом случае. Я решил попробовать cpи scpпросто посмотреть, показывают ли они одинаковую картину, и они делают - разница в 2 раза.

Поскольку я использую rsyncили cpв обоих случаях, я не могу понять, что мешает NFS достичь скорости передачи тех же команд через SSH.

Почему запись в общий ресурс NFS в 2 раза медленнее, чем запись в то же место по SSH?

Edit3 (NFS - сервер / и т.д. / экспорта вариантов): rw,no_root_squash,no_subtree_check,sync. Клиент / Proc / монтирует показывает: nfs rw,nodev,relatime,vers=3,rsize=1048576,wsize=1048576,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,mountvers=3,mountproto=tcp.

Спасибо вам всем!

Может быть, это не медленная скорость передачи, но увеличенная задержка записи. Попробуйте смонтировать асинхронный ресурс общего ресурса NFS вместо синхронизации и посмотрите, сокращает ли это разрыв в скорости. Когда вы выполняете rsync через ssh, удаленный процесс rsync записывает асинхронно (быстро). Но при записи в синхронно смонтированный общий ресурс nfs запись не подтверждается немедленно: сервер NFS ждет, пока они не ударили по диску (или, скорее всего, в кэш контроллера), прежде чем отправить подтверждение клиенту NFS, что запись прошла успешно.

Если «асинхронность» устраняет вашу проблему, имейте в виду, что если что-то случится с промежуточной записью NFS-сервера, у вас могут получиться противоречивые данные на диске. Пока это монтирование NFS не является основным хранилищем для этих (или любых других) данных, вы, вероятно, будете в порядке. Конечно, вы оказались бы в той же лодке, если бы вы отключили плагин на сервере nfs во время / после запуска rsync-over-ssh (например, rsync возвращает «завершено», сервер nfs падает, незафиксированные данные в кэше записи теперь теряются оставив противоречивые данные на диске).

Хотя это не проблема для вашего теста (rsyncing новых данных), имейте в виду, что rsync через ssh может предъявлять значительные требования к ЦП и IO на удаленном сервере до передачи одного байта во время вычисления контрольных сумм и генерации списка файлов, которые необходимо обновлено.

NFS - это протокол обмена, а Rsync оптимизирован для передачи файлов; Есть много оптимизаций , которые можно сделать , если вы знаете заранее , что ваша цель заключается в копировании файлов вокруг как можно быстрее , а не предоставление общего доступа к ним.

Это должно помочь: http://en.wikipedia.org/wiki/Rsync

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

Это интересно. Возможность, которую вы, возможно, не рассматривали, - это содержимое / тип файла, который вы передаете.

Если у вас есть небольшие файлы (например, электронные письма в отдельных файлах), эффективность NFS может снизиться из-за того, что не используется полный MTU (хотя, возможно, это менее вероятно при использовании TCP через UDP).

В качестве альтернативы, если у вас есть файлы / данные с высокой степенью сжатия, быстрые процессоры и сеть, в которой скорость процессора невелика (*), вы можете получить ускорение только за счет неявного сжатия по каналу ssh.

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

(*) В данном случае под «скоростью» я подразумеваю скорость, с которой ЦП может сжимать данные по сравнению со скоростью, с которой сеть может передавать данные, например, для отправки 5 МБ по проводам требуется 5 секунд, но ЦП может сжать эти 5 МБ в 1 МБ за 1 секунду. В этом случае время передачи сжатых данных будет чуть более 1 секунды, тогда как несжатых данных составляет 5 секунд.

Я также использую -e "ssh Ciphers = arcfour" для увеличения пропускной способности.

если ваша цель - просто скопировать все файлы из одного места в другое, то tar / netcat будет самым быстрым вариантом. если вы знаете, что в ваших файлах (нулях) много пробелов, используйте опцию -i.

ИСТОЧНИК: tar cvif - / path / to / source | NC DESTINATION PORTNUM DESTINATION: cd / path / to / source && nc -l PORTNUM | tar xvif -

если вы знаете, что ваши данные сжимаемы, то используйте сжатие в ваших командах tar -z -j -Ipixz

Я фанат pixz .. Параллельный xz, он предлагает отличное сжатие, и я могу настроить количество процессоров, которые у меня есть, на пропускную способность сети. если у меня более низкая пропускная способность, я буду использовать более высокое сжатие, поэтому я жду на процессоре больше, чем сеть .. если у меня быстрая сеть, я буду использовать очень низкое сжатие:

ИСТОЧНИК: tar cvif - / path / to / source | pixz -2 -p12 | nc DESTINATION PORTNUM # tar, игнорировать нули, сжатие пикселя уровня 2 с использованием 12 ядер процессора. DESTINATION: nc -l PORTNUM | tar -Ipixz -xvif

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

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

У netcat практически нет ни одного ... он будет отправлять полные TCP-пакеты, которые содержат только данные, которые вас интересуют.

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

У вас есть настройки блокировки файлов на nfsshare? Вы можете получить намного больше преформанс, если это было отключено.

Я предполагаю, что увеличение скорости, по крайней мере частично, связано с тем, что «rsync src host: / path» порождает локальный процесс на удаленной машине для отправки / получения, эффективно сокращая ваши операции ввода-вывода в два раза.