Почему мой rsync такой медленный?
Мой ноутбук и моя рабочая станция подключены к гигабитному коммутатору. Оба работают под управлением Linux. Но когда я копирую файлы с rsyncЭто плохо работает.
Я получаю около 22 МБ / с. Разве я не должен теоретически получить около 125 МБ / с? Что является ограничивающим фактором здесь?
РЕДАКТИРОВАТЬ: Я провел несколько экспериментов.
Запись производительности на ноутбуке
Ноутбук имеет файловую систему XFS с полным шифрованием диска. Оно использует aes-cbc-essiv:sha256 режим шифрования с длиной ключа 256 бит. Производительность записи на диск составляет 58,8 МБ / с.
iblue@nerdpol:~$ LANG=C dd if=/dev/zero of=test.img bs=1M count=1024
1073741824 Bytes (1.1 GB) copied, 18.2735 s, 58.8 MB/s
Чтение производительности на рабочей станции
Файлы, которые я скопировал, находятся на программном RAID-5 на 5 жестких дисках. На вершине рейда есть lvm. Сам том зашифрован тем же шифром. Рабочая станция имеет процессор FX-8150, который имеет собственный набор команд AES-NI, который ускоряет шифрование. Производительность чтения с диска составляет 256 МБ / с (кеш был холодным).
iblue@raven:/mnt/bytemachine/imgs$ dd if=backup-1333796266.tar.bz2 of=/dev/null bs=1M
10213172008 bytes (10 GB) copied, 39.8882 s, 256 MB/s
Производительность сети
Я запустил iperf между двумя клиентами. Производительность сети 939 Мбит / с
iblue@raven $ iperf -c 94.135.XXX
------------------------------------------------------------
Client connecting to 94.135.XXX, TCP port 5001
TCP window size: 23.2 KByte (default)
------------------------------------------------------------
[ 3] local 94.135.XXX port 59385 connected with 94.135.YYY port 5001
[ ID] Interval Transfer Bandwidth
[ 3] 0.0-10.0 sec 1.09 GBytes 939 Mbits/sec
4 ответа
Другой способ снизить нагрузку на процессор, но сохранить функциональность rsync, - перейти с rsync/SSH на rsync/NFS. Вы можете экспортировать пути, из которых вы хотите скопировать, через NFS, а затем использовать rsync локально из монтирования NFS в место назначения.
В одном тесте с сетевого диска WD MyBook Live один или несколько rsyncs из NAS в гигабитной сети на 2 локальных USB-диска не копировали бы более 10 МБ / с (ЦП: 80% usr, 20% sys) после экспорта через NFS и локальное rsyncing с общего ресурса NFS на оба диска Я получил в общей сложности 45 МБ / с (максимально для обоих дисков USB2) и малую загрузку ЦП. Использование диска при использовании rsync/SSH составляло около 6%, а при использовании rsync / NFS было ближе к 24%, в то время как оба диска USB2 были близки к 100%.
Таким образом, мы эффективно переместили узкое место с ЦП NAS на оба диска USB2.
Причины могут включать: сжатие, шифрование, количество и размер копируемых файлов, возможности дискового ввода-вывода вашей исходной и целевой систем, издержки TCP... Все эти факторы могут влиять на тип передачи, которую вы выполняете.
Пожалуйста, опубликуйте команду rsync, которую вы используете, и предоставьте подробную информацию о характеристиках обоих компьютеров.
Изменить: Шифрование часто является ограничивающим фактором в скорости rsync. Вы можете работать с ssh и более легким шифровальным шифром, таким как arcfour
Что-то вроде: rsync -e "ssh -c arcfour"
Или вы можете использовать модифицированный rsync / ssh, который может отключить шифрование. См. Hpn-ssh: http://psc.edu/networking/projects/hpn-ssh
Но опять же, ваш ноутбук работает медленнее, чем ваша рабочая станция. Запись может быть заблокирована и ожидает ввода / вывода на ваш ноутбук. Каковы ваши реальные ожидания производительности?
После еще одного тестирования я наконец нашел ответ сам. rsync по умолчанию использует туннелирование через ssh. Крипто делает это медленно. Так что мне нужно было обойти это крипто.
Решение 1. Настройка сервера rsync
Чтобы использовать его через rsync протокол, вы должны настроить сервер rsyncd. Это был /etc/init.d/rsync скрипт на моем ноутбуке, так что я догадался, rsyncd был запущен. Я был неправ. /etc/init.d/rsync start существует без вывода сообщений, когда rsync не включен в /etc/default/rsync, Тогда вы также должны настроить его в /etc/rsyncd.confЭто боль.
Если вы сделали все это, вы должны использовать rsync file.foo user@machine::directory, Обратите внимание, что есть два двоеточия.
Решение 2: Старый школьный rsh-сервер
Однако конфигурация была слишком сложной для меня. Так что я только что установил и rsh-server на моем ноутбуке. Вызов rsync на рабочей станции с -e rexec затем использует rsh вместо ssh. Который затем почти удвоил производительность до 44,6 МБ / с, что все еще медленно. Скорость отскакивает от 58 МБ / с до 33 МБ / с, что указывает на возможные проблемы с управлением буфером или перегрузкой. Но это выходит за рамки этого вопроса.
Это очень старые вопросы и ответы, но одна важная вещь отсутствует: если вы копируете уже сжатые или зашифрованные данные, отключите сжатие.
Если ваши данные не сжаты и не зашифрованы, вы все равно хотите сжать их только один раз! Rsync сжимает с -z, ssh сжимает с -C (может быть по умолчанию). Я не проверял, что лучше, так как мои данные сжаты.
Пока я в этом, вы можете отключить переадресацию X и распределение TTY, в результате чего:
rsync -avh -e "ssh -x -T -c arcfour -o Compression=no" $src $dst
Наконец, убедитесь (например, используя iptraf) что вы на самом деле используете сетевой интерфейс, который, как вы думаете, вы используете. К моему большому удивлению, я заметил, что на моем OSX исходящий ssh связывался с IP-адресом на исходящем интерфейсе по умолчанию, а не с IP-адресом на интерфейсе, на который должны были направляться пакеты. Мое прямое кросс-соединение между двумя ноутбуками, также подключенными по WiFi, не использовалось. После расследования это было связано с использованием 169.254/16, который Mac устанавливает на все интерфейсы, и конечным компьютером, отвечающим на запросы ARP, даже если запрос поступил на другом интерфейсе.