Чому моя rsync така повільна?

Мій ноутбук і моя робоча станція підключені до гігабітного комутатора. Обидва працюють під управлінням Linux. Але коли я копіюю файли rsync, вона працює погано.

Я отримую близько 22 Мб / с. Чи не повинен я теоретично отримати близько 125 Мб / с? Який тут обмежуючий фактор?

EDIT: Я провів кілька експериментів.

Випишіть продуктивність на ноутбуці

У ноутбуці є файлова система 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 та локальна рисингованія з 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, хоча запит надходив на інший інтерфейс.