Мой ноутбук и моя рабочая станция подключены к гигабитному коммутатору. Оба работают под управлением 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 жестких дисках. Поверх рейда стоит лвм. Сам том зашифрован таким же шифром. Рабочая станция оснащена процессором 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
Причины могут включать: сжатие, шифрование, количество и размер копируемых файлов, возможности дискового ввода-вывода исходной и целевой систем, накладные расходы TCP ... Все это факторы, которые могут повлиять на тип проводимой вами передачи.
Опубликуйте используемую вами команду rsync и предоставьте подробную информацию о технических характеристиках обоих компьютеров.
Изменить: шифрование часто является ограничивающим фактором скорости rsync. Вы можете работать с ssh и более легким шифром шифрования, например arcfour
Что-то вроде: rsync -e "ssh -c arcfour"
Или вы можете использовать модифицированный rsync / ssh, который может отключить шифрование. См. Hpn-ssh: http://psc.edu/networking/projects/hpn-ssh
Но опять же, у вашего ноутбука более медленный диск по сравнению с вашей рабочей станцией. Записи могут быть заблокированы и ожидают ввода-вывода на ваш ноутбук. Каковы ваши реальные ожидания от производительности?
Другой способ уменьшить высокую загрузку ЦП, сохранив при этом функциональность rsync, - это перейти с rsync / SSH на rsync / NFS. Вы можете экспортировать пути, которые хотите скопировать, через NFS, а затем использовать rsync локально из монтирования NFS в место назначения.
В одном тесте с сетевого диска WD MyBook Live один или несколько rsync от NAS в гигабитной сети к 2 локальным USB-дискам не копировали более 10 МБ / с (ЦП: 80% usr, 20% sys) после экспорта более NFS и rsyncing локально из общего ресурса NFS на оба диска я получил в общей сложности 45 МБ / с (максимальное использование обоих дисков USB2) и небольшую загрузку процессора. Использование диска при использовании rsync / SSH составляло около 6%, а при использовании rsync / NFS - около 24%, в то время как оба диска USB2 были близки к 100%.
Таким образом, мы эффективно перенесли узкое место с ЦП NAS на оба диска USB2.
После еще нескольких тестов я наконец нашел ответ. rsync по умолчанию использует туннелирование через ssh. Крипта замедляет работу. Так что мне нужно было обойти эту криптовалюту.
Чтобы использовать его через 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. Обратите внимание, что есть два двоеточия.
Однако настройка была для меня слишком сложной. Я просто установил и 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-адресу интерфейса, на который должны были маршрутизироваться пакеты. Мое прямое кросс-соединение между двумя ноутбуками, также подключенными по Wi-Fi, не использовалось. После расследования выяснилось, что это произошло из-за использования 169.254 / 16, который Mac ставит на все интерфейсы, а также из-за того, что целевой компьютер отвечает на запросы ARP, даже если запрос поступил через другой интерфейс.