Несколько дней назад я заметил нечто весьма странное (по крайней мере, для меня). Я запустил rsync, скопировав те же данные и затем удалив их при монтировании NFS под названием /nfs_mount/TEST. это /nfs_mount/TEST размещается / экспортируется из nfs_server-eth1. MTU на обоих сетевых интерфейсах составляет 9000, коммутатор между ними также поддерживает jumbo-кадры. Если я сделаю rsync -av dir /nfs_mount/TEST/ У меня скорость передачи данных по сети X Мбит / с. Если я сделаю rsync -av dir nfs_server-eth1:/nfs_mount/TEST/ У меня скорость передачи данных по сети не менее 2 Мбит / с. Мои варианты монтирования 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 с включенными jumbo-кадрами; без jumbo-кадров работает немного медленнее, но все же значительно быстрее, чем прямая передача в 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-сервер / etc / exports): rw,no_root_squash,no_subtree_check,sync. Клиентский / proc / mounts показывает: 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 оптимизирован для передачи файлов; есть много оптимизаций, которые можно сделать, если вы знаете априори что ваша цель - как можно быстрее скопировать файлы, а не предоставлять к ним общий доступ.
Это должно помочь: http://en.wikipedia.org/wiki/Rsync
Может дело не в медленной скорости передачи, а в увеличении задержки записи. Попробуйте смонтировать асинхронный общий ресурс NFS вместо синхронизации и посмотрите, уменьшит ли это разрыв в скорости. Когда вы используете rsync через ssh, удаленный процесс rsync записывает асинхронно (быстро). Но при записи в синхронно смонтированный общий ресурс nfs записи не подтверждаются немедленно: сервер NFS ждет, пока они не попадут на диск (или, что более вероятно, в кеш контроллера), прежде чем отправить подтверждение клиенту NFS, что запись была успешной.
Если «асинхронный» решает вашу проблему, имейте в виду, что если что-то случится с сервером NFS во время записи, вы вполне можете получить несогласованные данные на диске. Пока это монтирование NFS не является основным хранилищем для этих (или любых других) данных, с вами, вероятно, все будет в порядке. Конечно, вы оказались бы в той же лодке, если бы отключили сервер nfs во время / после запуска rsync-over-ssh (например, rsync возвращает завершение, сервер nfs выходит из строя, незафиксированные данные в кэше записи теперь теряются оставляя несогласованные данные на диске).
Хотя это не проблема с вашим тестом (rsyncing новых данных), имейте в виду, что rsync over ssh может потребовать значительных ресурсов ЦП и ввода-вывода на удаленном сервере до того, как будет передан один байт, пока он вычисляет контрольные суммы и генерирует список файлов, которые должны быть обновлено.
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 - / путь / к / источнику | nc DESTINATION PORTNUM DESTINATION: cd / path / to / source && nc -l PORTNUM | tar xvif -
если вы знаете, что ваши данные можно сжимать, используйте сжатие в командах tar -z -j -Ipixz
Я фанат pixz .. parallel xz, он предлагает отличное сжатие, и я могу настроить количество процессоров, которые у меня есть, в зависимости от пропускной способности сети. если у меня более низкая пропускная способность, я буду использовать более высокое сжатие, поэтому я жду процессора больше, чем сеть .. если у меня быстрая сеть, я буду использовать очень низкое сжатие:
ИСТОЧНИК: tar cvif - / путь / к / источнику | 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, поэтому он не подходит для инкрементного резервного копирования или чего-то подобного, но он хорош для копирования данных или архивирования.
У вас есть настройка блокировки файлов на общем ресурсе nfs? Если бы это было отключено, вы могли бы получить намного больше производительности.
Я предполагаю, что увеличение скорости, по крайней мере, частично связано с тем, что "rsync src host: / path" порождает локальный процесс на удаленной машине для отправки / получения, эффективно сокращая количество операций ввода-вывода вдвое.