Чому існує різниця швидкостей запису між dd, cp, rsync та macOS Finder на привід SMB3?

Tl; dr - Ми не можемо знайти причину обмеженої швидкості запису в 60 Мб / с для нашого NAS через SMB та AFP від ​​двох різних клієнтів Mac. Для порівняння: старий ноутбук Windows 7 у тій же мережі записує стійкі 100 Мб / сек.

Якщо ви читаєте це питання вперше, перейдіть до розділу " Оновлення 4 ". rsyncє основною причиною низької швидкості, навіть якщо ми не розуміємо, чому (для одного файлу!).

Оригінальне запитання: Знайдіть вузьке вузьке місце для SMB3 / NAS з Mac OS 10.11.5 і вище

Ми перевірили rsync --progress -a /localpath/test.file /nas/test.fileна macOS та інформацію про копію Windows.

NAS - це DS713 +, на якому працює їх поточний DSM 6.0.2 (тестується також 5.x), з двома HGST Deskstar NAS SATA 4TB (HDN724040ALE640) в RAID1, які мають лише гігабітні компоненти Ethernet та нові кабелі Ethernet (принаймні Cat5e).

Клієнти Mac спочатку зробили лише 20 Мб / сек. Але застосування signing_required=noвиправлення (описане тут ) підштовхнуло швидкість запису до 60 Мб / сек через SMB2 та SMB3. AFP також забезпечує близько 60 Мб / сек. Результат коливається в межах 5 Мб / с залежно від протоколу та (Mac) клієнта.

Що ми вже спробували:

Мережа

1. Перевірена продуктивність мережі через iperf3. Результат: 926 Мбіт / с. Виглядає чудово.
2. Спробував мережеві інтерфейси для агрегації подвійних посилань / зв'язкових. Без змін.
3. Збільшено MTU до 6000 та 9000. Без змін.
4. Перевірив усі кабелі. Все добре, принаймні Cat5e, у хорошому стані.

Диски

1. Перевірений SMART Виглядає здоровим.
2. Перевірена швидкість запису безпосередньо на диск з dd if=/dev/zero of=write.test bs=256M count=4різними bsта countналаштуваннями (128/8, 512M / 2, 1024/1). Результат: близько 120 Мб / с (залежно від розміру / кількості блоку)

SMB / AFP

1. Орієнтовані SMB2, SMB3 та AFP один проти одного. Про рівних.
   Дивіться оновлення нижче: Використовується неправильний метод для виключення SMB реалізації macOS. SMB у Windows швидше, тому можуть бути нові настройки SMB, що надходять із macOS 10.11 та 10.12.
2. Намагався змінити настройки SMB, включаючи параметри розетки (дотримуючись цієї інструкції )
3. Спробував іншу версію налаштувань затримки Ack та rsync --sockopts=TCP_NODELAY(коментарі)

Немає суттєвої зміни швидкості запису. Ми двічі перевірили, що конфігурація дійсно завантажена, і ми редагували правильний smb.conf .

Система

1. Переглянуті завантаження процесора та оперативної пам’яті. Нічого не виходить. Процесор близько 20%, оперативна пам'ять близько 25% під час передачі.
2. Випробував той самий NAS з DSM 5.xx у майже позаставній установці. Не встановлено додаткового програмного забезпечення. Примітка. У нас є два таких пункти в різних місцях. Вони синхронізуються через CloudSync Cloud Synology. Той самий результат.
3. Деактивувало все зайве, що могло б залучити системні ресурси.

Ми вважаємо, що це досить налаштування за замовчуванням, немає фантазійних адаптацій, клієнтів або мережевих компонентів. Відповідно до метрики, яку видає Synology, NAS повинна виконувати швидкість на 40 МБ / с до 75 МБ / с. Але ми просто не можемо знайти вузьке місце.

Клієнти / НАН

Клієнтами Mac є MacPro 5,1 (стандартний провідний NIC, працює 10.12.3 (16D32)) і MacBookPro10,1 (мережевий адаптер Thunderbolt, працює 10.11.6), що знаходиться приблизно на відстані 2 м від NAS, що працює над тим же Гігабітний комутатор як ноутбук Windows у тесті.

У нас є два таких НАС у різних місцях, і результати однакові. Секунди NAS більш-менш заводські за замовчуванням (навіть не встановлено сторонне програмне забезпечення). Всього два диски формату RAID1, EXT4 синхронізуються з іншими NAS за допомогою Synology CloudSync. Ми пройшли далеко до прямого підключення до NAS без вимикача, такий же результат.

Важливе оновлення

Метод, який використовується для виключення SMB-реалізації macOS / OS X, був помилковим. Я перевірив це через віртуальну машину, припускаючи, що він буде використовувати власну версію SMB, але, очевидно, трафік передається macOS, проходить через свою версію SMB.

Використовуючи ноутбук Windows, я зараз змогла досягти в середньому 100 Мб / с. Вказівка ​​на впровадження / оновлення SMB, що надходять із 10.11 та 10.12, може спричинити низьку ефективність. Навіть якщо signing_requiredвстановлено значення no.

Було б чудово, якби хтось міг вказати на деякі подальші налаштування, які могли змінитися з оновленнями і можуть вплинути на ефективність.

Оновлення 2 - нові відомості

ЕндрюХенле в коментарях зазначив, що я повинен детально дослідити трафік, використовуючи Wireshark для отримання більш глибокої інформації.

Тому я біг sudo tcpdump -i eth0 -s 65535 -w tcpdump.dumpу NAS, передаючи два тестові файли, один із 512 МБ та один з 1 ГБ. І оглянув звалище з Wireshark.

Що я знайшов:

1. І OS X, і Windows, здається, використовують SMB2, хоча SMB3 увімкнено в NAS (принаймні, згідно Wireshark).
2. OS X, схоже, тримається на MTU . Пакети містять 1514 байт, що призводить до збільшення кількості накладних та надісланих мереж (видно на дампах).
3. Здається, Windows надсилає пакети до 26334 байтів (якщо я прочитав дані правильно! Будь ласка, перевірте.) Навіть якщо MTU не повинен цього дозволити, оскільки в NAS встановлено 1500, максимальний параметр буде 9000 там (Synology також використовує налаштування 1500 у своїх тестах).
4. Спроба примусити macOS використовувати SMB3, додавши smb_neg=smb3_onlyв /etc/nsmb.conf , не спрацювало або, принаймні, не призвело до швидших передач.
5. Запуск rsync --sockopts=TCP_NODELAYіз різними комбінаціями параметрів TCP із затримкою ack (від 0 до 3) не мав ефекту (Примітка: я запустив tcpdump із налаштуванням ack за замовчуванням 3).

Я створив 4 звалища у форматі .csv, 2 при копіюванні 512 МБ (тест-2.файл) та 2 під час копіювання 1024 МБ (тест.файл). Ви можете завантажити експорт Wireshark тут (25,2 Мб). Вони застібкуються на блискавці, щоб заощадити простір та названі само собою зрозумілими.

Оновлення 3 - висновок smbutil

Вихід, smbutil statshares -aяк вимагає harrymc у коментарях.

==================================================================================================
SHARE                         ATTRIBUTE TYPE                VALUE
==================================================================================================
home
                              SERVER_NAME                   server-name._smb._tcp.local
                              USER_ID                       502
                              SMB_NEGOTIATE                 SMBV_NEG_SMB1_ENABLED
                              SMB_NEGOTIATE                 SMBV_NEG_SMB2_ENABLED
                              SMB_NEGOTIATE                 SMBV_NEG_SMB3_ENABLED
                              SMB_VERSION                   SMB_3.0
                              SMB_SHARE_TYPE                DISK
                              SIGNING_SUPPORTED             TRUE
                              EXTENDED_SECURITY_SUPPORTED   TRUE
                              LARGE_FILE_SUPPORTED          TRUE
                              OS_X_SERVER                   TRUE
                              QUERYINFO_NOT_SUPPORTED       TRUE
                              DFS_SUPPORTED                 TRUE
                              MULTI_CREDIT_SUPPORTED        TRUE

--------------------------------------------------------------------------------------------------

Зверніть увагу на це: я впевнений, що SIGNING_SUPPORTEDперебування trueтут не означає, що налаштування в конфігурації не працює. Але лише те, що це підтримується NAS. Я тричі перевіряв, що зміна signing_requiredналаштувань у моєму конфігурації впливає на швидкість запису (~ 20 Мб / с при включенні, ~ 60 Мб / с при відключенні).

Оновлення 4 - Війни Самба: Нова надія

Це стає дещо бентежно, але головна проблема тут - знову ж таки - здається, вимірювання.

Виявляється, rsync --progress -aкоштує близько 30 Мб / с швидкість запису. Писання ddбезпосередньо на SMB-долі та використання time cp /local/test.file /NAS/test.fileшвидше зі швидкістю 85-90 Мб / с, і, мабуть, найшвидший спосіб копіювання - це Finder macOS зі швидкістю близько 100 Мб / с (що також є найважчим способом вимірювання, оскільки його немає індикатор часу або показника швидкості - кому це потрібно, правда? o_O). Ми виміряли його, спочатку скопіювавши 1 Гб файл, а потім 10 ГБ файл, використовуючи секундомір.

Що ми намагалися з часу останнього оновлення цього питання.

1. Скопіюйте з клієнта Mac на клієнт Mac. Обидва мають SSD-диски (MacPro пише з 250 Мб / с власний диск, MacBook Pro з 300 Мб / с). Результат: Невисокі 65 Мб / с за допомогою ddнаписання з MacBook Pro на MacPro ( rsync25 Мб / с). Бачити 25 Мб / с був момент, коли ми почали допитуватись до rsync. Ще 65 Мб / с надзвичайно повільно. Тож реалізація SMB на macOS здається… ну, сумнівною.
2. Пробували різні настройки ack з dd та cp - не пощастило.
3. Нарешті ми знайшли спосіб перелічити всі доступні параметри nsmb.conf. Це просто man nsmb.conf. Обережно, що онлайн-версія застаріла!

Тому ми спробували ще кілька налаштувань, серед яких:

notify_off=yes
validate_neg_off=yes
read_async_cnt=16
write_async_cnt=16
dir_cache_async_cnt=40
protocol_vers_map=4
streams=no
soft=yes

Примітка: smb_neg=smb3_only- як я вже очікував - не є правильним параметром. protocol_vers_map=4має бути дійсним еквівалентом.

У будь-якому разі жоден з цих параметрів не змінив для нас значення.

Нові питання з першого погляду

1. Чому rsync такий дорогий спосіб скопіювати один (1!) Файл. Тут не так багато для синхронізації / порівняння, чи не так? Tcpdump також не вказує можливих накладних витрат.

2. Чому під час переходу на SMB-акцію ddі cpшвидше, ніж шукач macOS? Здається, що при копіюванні з Finder значно менше підтверджень у спілкуванні TCP. (Знову ж таки: налаштування Ack, наприклад, delayed_ack=1для нас не змінилося.)

3. Чому Windows, здається, ігнорує MTU, надсилаючи значно більші і, отже, менші пакети TCP, що призводить до найкращої продуктивності порівняно з усім можливим через macOS.

Ось так виглядають пакети від macOS (постійно 1514)

"TCP","1514","[TCP segment of a reassembled PDU]"
"TCP","66","445  >  56932 [ACK] Seq=6603 Ack=35239 Win=4505 Len=0 TSval=520980697 TSecr=650208630"

І це з Windows (до 26334, залежно від розміру)

"SMB2","1466","Write Request Len:65536 Off:196608 File: test.file"
"TCP","26334","[TCP segment of a reassembled PDU]"
"TCP","7354","[TCP segment of a reassembled PDU]"
"TCP","54","445  >  49220 [ACK] Seq=6831 Ack=267030 Win=4074 Len=0"

Ви можете завантажити повний .csv тут (25,2 Мб), назви файлів пояснюють, що було скопійовано (ОС, спосіб передачі та розмір файлу).

1. подібне запитання, але має цікаві відповіді. Ви можете перевірити цю тему, особливо в коментарі 5: https://bugzilla.samba.org/show_bug.cgi?id=8512#c5

Тут цитата «Пітер ван Хуфт». Але я не впевнений, що я перевіряю базу на те, що / який Linux дистрибутив. і версія rsync. Однак: 1. Він дає нам думку спробувати - sparse flag, якщо це можливо для підвищення продуктивності. 2. Він перевіряв протокол NFS, але зіткнувся з проблемою швидкості, тому ІТ, можливо, не причина протоколу (SMB2 / 3, AFP тощо).

Ми використовуємо rsync для копіювання даних з одного файлового сервера на інший за допомогою кріплення NFS3 через посилання 10Gb. Ми виявили, що збільшення розмірів буфера (як швидкий тест) підвищує продуктивність. При використанні --sparse це збільшує продуктивність з коефіцієнтом п'ятдесят, від 2MBps до 100MBps.

2. Ось ще одна цікава перевірка щодо продуктивності rsync. https://lwn.net/Articles/400489/

LWN.net має висновки, що питання про продуктивність може стосуватися ядра навіть статті, опублікованої в 2010 році, і ми не можемо змінити NAS або MacOS. Однак ця стаття дає нам думку про те, що проблема з ядром може викликати розрахунок контрольної суми (як я здогадуюсь).

Ясно одне: я повинен оновити ядро ​​в моїй системі Mythtv. Загалом, ядра 2.6.34 та 2.6.35-rc3 дають кращу продуктивність, ніж старе ядро ​​2.6.27. Але, поводячись чи ні, rsync все ще не може перемогти простий cp, який копіює зі швидкістю 100 Мбіт / с. Дійсно, rsync дійсно потребує великої потужності процесора для простих локальних копій. На найвищій частоті процесору потрібно всього 0,34 + 20,95 секунди CPU, порівняно з 70 + 55 секундами rsync.

також цитуйте коментарі:

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

update 1 : моя помилка, цей опис призначений для --checksum. перевірте це тут: [Покращено опис параметра --checksum.] PS, мені не вистачає репутації, щоб розмістити більше 2 посилань.

але я не можу знайти той самий опис на сторінці rsync man, тому я здогадуюсь, що хтось говорить про це нижче Bold:

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

Тому порівняйте з cp / tar / cat, якщо ми використовуємо rsync для копіювання купки невеликих чи великих файлів, це може спричинити проблеми з продуктивністю. АЛЕ через те, що я не в змозі прочитати вихідний код rsync, тому я не можу підтвердити, що це є кінцевою причиною.

моя ідея триває перевірку:

1. Яку версію rsync використовує awenro для тестування? Чи можете ви оновити до останньої версії?
2. давайте подивимося, який вихід при використанні --stats і -v з --debug = FLAGS

прапори

--stats Це говорить rsync надрукувати багатослівний набір статистики щодо передачі файлів, що дозволяє вам сказати, наскільки ефективний алгоритм rsync для ваших даних.

--debug = ФЛАГИ Цей параметр дозволяє вам мати тонкозернистий контроль над виводом налагодження, який ви хочете бачити. Ім'я окремого прапора може супроводжуватися номером рівня, причому 0 означає мовчання цього виходу, 1 - вихідний рівень за замовчуванням, а більші числа збільшують вихід цього прапора (для тих, хто підтримує більш високі рівні). Використовуйте --debug = допомога, щоб побачити всі доступні імена прапорів , що вони виводять, а також які імена прапорців додаються за кожне збільшення рівня багатослідового.

нарешті, я б рекомендував прочитати цей додатковий пост, щоб отримати більше знань.
"Як передавати велику кількість даних через мережу" moo.nac.uci.edu/~hjm/HOWTO_move_data.html

Rsync / ssh шифрує з'єднання smb не робить, якщо я правильно пам’ятаю. Якщо це лише один файл, то одна система може прочитати цей файл, а інша - ні. Також зауважте, що для того, щоб мати MTU вище 1514, вам потрібно включити "гіганти" / "Jumbo Frames" пакети, той факт, що пакети потрібно додатково скорочувати, може означати, що є накладні витрати для "перепакування" пакету. Друге, що слід зазначити, це те, що "гіганти" / "рамки Jumbo" повинні бути включені з обох кінців і ВСЕ МІЖ.

1514 - це звичайні кадри Ethernet. Кадри 6k-9k називаються гігантами або "рамками Jumbo" залежно від ОС / програми

Я в середньому 80 Мб / с між моїм носом (ПК з VM, один з ВМ - це NAS) і моєю станцією (ПК) з sftp (використовуючи sshfs) [гіганти не ввімкнено], і пристрій між ними - microtik 2011 (йде тільки чіп комутатора)

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

редагувати: SMB не дуже ефективний для передачі файлів.