Чому rsync швидше, ніж NFS?

Кілька днів тому я помітив щось досить дивне (принаймні для мене). Я запустив rsync, копіюючи ті самі дані та видаляючи їх згодом на кріплення NFS, зване /nfs_mount/TEST. Це /nfs_mount/TESTрозміщено / експортовано з nfs_server-eth1. MTU на обох мережних інтерфейсах 9000, перемикання між підтримкою jumbo-кадрів також. Якщо мені це, rsync -av dir /nfs_mount/TEST/я отримую швидкість передачі мережі X Мбіт / с. Якщо я це зробити, rsync -av dir nfs_server-eth1:/nfs_mount/TEST/я отримую швидкість передачі мережі принаймні 2X Мбіт / с. Мої параметри кріплення NFS є nfs rw,nodev,relatime,vers=3,rsize=1048576,wsize=1048576,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,mountvers=3,mountproto=tcp.

Підсумок: обидва передачі йдуть по одній мережевій підмережі, однакові дроти, однакові інтерфейси, читаються ті самі дані, записуються в ту саму директорію і т. Д. Тільки різниця одна - через NFSv3, інша - через rsync.

Клієнт - Ubuntu 10.04, сервер Ubuntu 9.10.

Чому rsync набагато швидше? Як зробити так, щоб NFS відповідав цій швидкості?

Спасибі

Редагувати: зверніть увагу: я використовую rsync для запису на NFS-спільний доступ або на SSH на сервер NFS і пишу локально там. І те й інше rsync -av, починаючи з чіткого каталогу призначення. Завтра спробую із звичайною копією.

Edit2 (додаткова інформація): Розмір файлу коливається від 1 КБ-15 МБ. Файли вже стиснуті, я намагався додатково стиснути їх. Я зробив tar.gzфайл із цього dir. Ось викрійка:

• rsync -av dir /nfs_mount/TEST/ = найповільніша передача;
• rsync -av dir nfs_server-eth1:/nfs_mount/TEST/= найшвидший rsync з увімкненими рамками jumbo; без джомбових кадрів трохи повільніше, але все-таки значно швидше, ніж безпосередньо безпосередньо до NFS;
• rsync -av dir.tar.gz nfs_server-eth1:/nfs_mount/TEST/ = приблизно те саме, що його еквівалент non-tar.gz;

Тести з cpта scp:

• cp -r dir /nfs_mount/TEST/= Трохи швидше , rsync -av dir /nfs_mount/TEST/але все ж значно повільніше , ніж rsync -av dir nfs_server-eth1:/nfs_mount/TEST/.
• scp -r dir /nfs_mount/TEST/= найшвидший в цілому, трохи долає rsync -av dir nfs_server-eth1:/nfs_mount/TEST/;
• scp -r dir.tar.gz /nfs_mount/TEST/ = приблизно те саме, що його еквівалент non-tar.gz;

Висновок, виходячи з цих результатів: Для цього тесту немає суттєвої різниці, якщо ви використовуєте великий файл tar.gz або багато маленьких. Увімкнення або вимкнення кадрів Jumbo також майже не має ніякої різниці. cpі scpшвидше, ніж їх відповідні rsync -avеквіваленти. Написання безпосередньо на експортовану частку NFS значно повільніше (принаймні в 2 рази), ніж запис у ту саму директорію через SSH, незалежно від використовуваного методу.

Відмінності між cpі rsyncне мають значення в даному випадку. Я вирішив спробувати cpі scpпросто побачити, чи показують вони однаковий зразок, а вони - 2X різниця.

Оскільки я використовую rsyncабо cpв обох випадках, я не можу зрозуміти, що заважає NFS досягти швидкості передачі тих же команд через SSH.

Чому письмовій формі на NFS частку відбувається в 2 рази повільніше, ніж писати там же через SSH?

Edit3 (NFS - сервер / і т.д. / експорту варіантів): rw,no_root_squash,no_subtree_check,sync. Клієнт / Proc / монтує показує: nfs rw,nodev,relatime,vers=3,rsize=1048576,wsize=1048576,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,mountvers=3,mountproto=tcp.

Дякую вам всім!

Можливо, це не повільна швидкість передачі, а збільшена затримка запису. Спробуйте встановити асинхронний ресурс спільної NFS замість синхронізації та перевірте, чи закриває це розрив у швидкості. Коли ви rsync над ssh, віддалений процес rsync записує асинхронно (швидко). Але під час запису на синхронно встановлену спільну частину nfs записи не підтверджуються негайно: сервер NFS чекає, поки вони потраплять на диск (або, швидше за все, кеш-пам'ять контролера), перш ніж надіслати підтвердження клієнту NFS, що запис вдався.

Якщо "async" вирішує вашу проблему, майте на увазі, що якщо щось трапиться з сервером NFS посеред запису, то ви дуже добре може виявитися непослідовними даними на диску. Поки цей кріплення NFS не є основним сховищем для цих (або будь-яких інших) даних, ви, мабуть, будете добре. Звичайно, ви опинилися б у тому самому човні, якби ви витягнули штекер на сервері nfs під час / після запуску rsync-over-ssh (наприклад, rsync повертається після закінчення, сервер nfs виходить з ладу, невідомі дані в кеші запису втрачаються залишаючи на диску непослідовні дані).

Хоча це не проблема з вашим тестом (rsyncing нових даних), майте на увазі, що rsync через ssh може викликати значні вимоги CPU та IO на віддаленому сервері до того, як передається один байт під час обчислення контрольних сум та генерування списку файлів, які потрібно мати оновлено.

NFS - це протокол спільного використання, тоді як Rsync оптимізований для передачі файлів; Є багато оптимізацій, які можна зробити, коли апріорі ви знаєте, що ваша мета - скопіювати файли якомога швидше, а не надавати спільний доступ до них.

Це має допомогти: http://en.wikipedia.org/wiki/Rsync

Rsync - це файловий протокол, який передає лише змінені біти між файлами. NFS - це протокол файлів віддалених файлів каталогів, який обробляє все щоразу ... певним чином як SMB. Два різні та для різних цілей. Ви можете використовувати Rsync для передачі між двома загальними NFS.

Це цікаво. Можливість, яку ви, можливо, не врахували - це вміст / тип файлу, який ви передаєте.

Якщо у вас є невеликі файли (наприклад, електронні листи в окремих файлах), ефективність NFS може втратити силу через не повне використання повного MTU (можливо, це менш ймовірно, якщо TCP над UDP, хоча).

Крім того, якщо у вас є дуже стисливі файли / дані, швидкі процесори та мережа, яка не має достатньо швидкості процесора (*), ви можете отримати швидкість просто від неявного стиснення через ssh-посилання.

Третя можливість полягає в тому, що файли (або одна їх версія) вже існують у пункті призначення. У цьому випадку прискорення відбудеться тому, що протокол rsync зберігає вас при передачі файлів.

(*) У даному випадку під "швидкістю" я маю на увазі швидкість, з якою ЦП може стискати дані порівняно зі швидкістю, по якій мережа може передавати дані, наприклад, для передачі 5 МБ через провід потрібно 5 секунд, але ЦП може стиснути 5 Мб на 1 МБ за 1 секунду. У цьому випадку час передачі стислих даних буде трохи більше 1 секунди, тоді як нестиснені дані - 5 секунд.

Я також використовую -e "ssh Ciphers = arcfour" для збільшення пропускної здатності.

якщо ваша мета - просто скопіювати всі файли з одного місця в інше, тоді tar / netcat стане найшвидшим варіантом. якщо ви знаєте, що у ваших файлах є багато пробілів (нулі), то скористайтеся опцією -i.

ДЖЕРЕЛО: tar cvif - / шлях / до / джерело | nc ДЕСТИНАЦІЯ ПОРТНУМ ДЕСТИНАЦІЯ: cd / шлях / до / джерело && nc -l PORTNUM | смола xvif -

якщо ви знаєте, що ваші дані є стисливими, тоді використовуйте стиснення для ваших команд tar -z -j -Ipixz

Я фанат pixz .. паралельно xz, він пропонує велику компресію, і я можу налаштувати кількість процесорів, які у мене є, на пропускну здатність мережі. якщо у мене повільніша пропускна здатність, я використовую більш високу компресію, тому я чекаю на процесорі більше, ніж у мережі .. якщо у мене швидка мережа, я використовую дуже низьку компресію:

ДЖЕРЕЛО: tar cvif - / шлях / до / джерело | pixz -2 -p12 | nc ДЕСТИНАЦІЯ PORTNUM # tar, ігноруйте нулі, рівень 2 стиснення pixz за допомогою 12 ядер процесора ВИЗНАЧЕННЯ: nc -l PORTNUM | дьоготь -Ipixz -xvif

якщо ви правильно налаштуєте рівень стиснення та сердечники, залежно від вашого набору даних, ви зможете тримати мережу близькою до насиченої та робити достатню компресію, ви вузьким місцем стає диском (зазвичай сторона запису, якщо дискові системи читання та запису є так само).

що стосується rsync, я вважаю, що він пропускає нулі аналогічно тому, як робить tar з цією опцією, тому він передає менше даних, ніж NFS. NFS не може робити припущення щодо даних, тому має передавати кожен байт разом із накладними протоколами NFS. rsync має деякі накладні ..

netcat в основному не має .. він надсилатиме повні пакети TCP, які не містять нічого, крім важливих даних.

з netcat, як і в scp, вам доведеться постійно надсилати всі вихідні дані, ви не можете бути вибірковими, як при rsync, тому це не підходить для покрокових резервних копій або подібних речей, але це добре для копіювання даних або архівування.

У вас є налаштування блокування файлів на nfsshare? Ви можете отримати набагато більше готових даних, якщо це було вимкнено.

Я припускаю, що підвищена швидкість принаймні частково пояснюється тим, що "rsync src host: / path" нерестує локальний процес на віддаленій машині для надсилання / отримання, ефективно розрізаючи свій введення / вивід навпіл.