Почему мой rsync является настолько медленным?
Если это - Exchange Server, можно также попробовать https://www.testexchangeconnectivity.com/
Еще один способ уменьшить высокую загрузку ЦП, но при этом сохранить функциональность rsync, - это перейти с rsync / SSH на rsync / NFS. Вы можете экспортировать пути, которые вы хотите скопировать, через NFS, а затем использовать rsync локально из монтирования NFS в место назначения.
В одном тесте с сетевого диска WD MyBook Live, один или несколько rsync с NAS на гигабите сеть к 2 локальным USB-дискам не будет копировать более 10 МБ / с (ЦП: 80% usr, 20% sys), после экспорта через NFS и локальной синхронизации из общего ресурса NFS на оба диска я получил в общей сложности 45 МБ / с (макс. из обоих дисков USB2) и небольшая загрузка ЦП. Использование диска при использовании rsync / SSH составляло около 6%, а использование rsync / NFS было ближе к 24%, в то время как оба диска USB2 были близки к 100%.
Таким образом, мы эффективно переместили узкое место с ЦП NAS на оба диска USB2.
После еще нескольких тестов я наконец сам нашел ответ. 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. Please note, that there are two colons.
Solution 2: Old-school rsh-server
However, the configuration was way too complicated for me. So I just installed and rsh-server on my laptop. Invoking rsync on the workstation with -e rexec then uses rsh instead of ssh. Which then almost doubled the performance to 44.6 MB/s, which is still slow. The speed bounces between 58 MB/s and 33 MB/s, which indicates there may be some buffer or congestion control problems. But that is beyond the scope of this question.
Reasons can include: compression, encryption, the number and size of files being copied, your source and destination systems' disk I/O capabilities, TCP overhead... These are all factors that can influence the type of transfer you're conducting.
Please post the rsync command you're using and provide details on the specifications of both computers.
Edit: Encryption is often a limiting factor in rsync speeds. You can run with ssh and a lighter-weight encryption cipher like arcfour
Something like: rsync -e "ssh -c arcfour"
Or you can use a modified rsync/ssh that can disable encryption. See hpn-ssh: http://psc.edu/networking/projects/hpn-ssh
But again, your laptop has a slow drive compared to your workstation. Writes may be blocked and waiting for I/O going to your laptop. What are your real performance expectations?
Это очень старый вопрос и ответы, но отсутствует одна важная вещь: если вы копируете уже сжатые или зашифрованные данные, отключите сжатие.
Если ваши данные не сжаты ни зашифрованный, вы все равно хотите сжать его только один раз! 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, даже если запрос поступил через другой интерфейс.