Почему мой 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

Другой способ снизить нагрузку на процессор, но сохранить функциональность 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, даже если запрос поступил на другом интерфейсе.