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.fileMacOS и информацию о копировании Windows.
NAS представляет собой DS713 +, на котором установлена текущая версия DSM 6.0.2 (также протестированная с 5.x), с двумя HGST Deskstar NAS SATA 4 ТБ (HDN724040ALE640) в RAID1 с только гигабитными компонентами Ethernet и новыми кабелями Ethernet (как минимум Cat5e).
Клиенты Mac сначала производили только 20 МБ / с. Но применение signing_required=noисправления (описанного здесь ) увеличило скорость записи до 60 МБ / с через SMB2 и SMB3. AFP также обеспечивает скорость около 60 МБ / с. Результат варьируется около 5 МБ / с в зависимости от протокола и (Mac) клиента.
Что мы уже пробовали:
сеть
- Проверена производительность сети через iperf3. Результат: 926 Мбит / с. Выглядит хорошо.
- Опробованная агрегация двойных каналов / связанные сетевые интерфейсы. Без изменений.
- Увеличено MTU до 6000 и 9000. Без изменений.
- Проверил все кабели. Все хорошо, по крайней мере, Cat5e, в хорошем состоянии.
Диски
- Проверено SMART Выглядит здорово.
- Испытано скорость записи непосредственно на диск с
dd if=/dev/zero of=write.test bs=256M count=4с различнымиbsиcountнастройками (128/8, 512M / 2, 1024/1). Результат: около 120 МБ / с (в зависимости от размера / количества блоков)
SMB / AFP
Бенчмаркинг SMB2, SMB3 и AFP друг против друга. Примерно равный.
Смотрите обновление ниже: Использовал неправильный метод, чтобы исключить реализацию macOS для SMB. SMB в Windows работает быстрее, причиной могут быть новые настройки SMB, поставляемые с macOS 10.11 и 10.12.- Попытался настроить параметры SMB, включая параметры сокета (следуя этой инструкции )
- Пробовал разные версии отложенных настроек ака
rsync --sockopts=TCP_NODELAY(комментарии)
Нет значительного изменения скорости записи. Мы дважды проверили, что конфиг действительно загружен, и мы редактировали правильный файл smb.conf .
система
- Следил за загрузкой процессора и оперативной памяти. Ничто не исчерпывается. Процессор около 20%, ОЗУ около 25% во время передачи.
- Протестировал тот же NAS с DSM 5.xx в почти готовой конфигурации. Дополнительное программное обеспечение не установлено. Примечание: у нас есть два из них в разных местах. Они синхронизируются через Synology CloudSync. Тот же результат.
- Отключено все ненужное, что могло бы привлечь системные ресурсы.
Мы думаем, что это скорее настройка по умолчанию, никаких необычных адаптаций, клиентов или сетевых компонентов. В соответствии с показателями, которые публикует Synology, NAS должен работать на 40–75 МБ / с быстрее. Но мы просто не можем найти узкое место.
Клиенты / NAS
Клиентами Mac являются MacPro 5,1 (стандартная проводная сетевая карта, работающая 10.12.3 (16D32)) и MacBookPro10,1 (сетевой адаптер Thunderbolt, работающий 10.11.6) всего в 2 м от кабеля NAS, работающего через тот же гигабитный коммутатор как ноутбук с Windows в тесте.
У нас есть два таких NAS в разных местах, и результаты идентичны. Секунды 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 - новые идеи
AndrewHenle указал в комментариях, что я должен исследовать трафик подробно, используя Wireshark для большего понимания.
Поэтому я работал sudo tcpdump -i eth0 -s 65535 -w tcpdump.dumpна NAS, передавая два тестовых файла: один с 512 МБ и один с 1 ГБ. И осмотрел свалку с Wireshark.
Что я нашел:
- Как OS X, так и Windows, кажется, используют SMB2, хотя SMB3 включен на NAS (по крайней мере, в соответствии с Wireshark).
- OS X, кажется, придерживается MTU . Пакеты имеют 1514 байтов, что приводит к увеличению нагрузки на сеть и отправке пакетов (видно из дампов).
- Похоже, что Windows отправляет пакеты размером до 26334 байт (если я правильно читаю данные! Пожалуйста, проверьте.), Даже если MTU не должен допускать этого, поскольку на NAS он установлен равным 1500, максимальное значение будет 9000 (Synology также использует настройку 1500 в своих тестах).
- Попытка заставить macOS использовать SMB3 путем добавления
smb_neg=smb3_onlyв /etc/nsmb.conf не сработала или, по крайней мере, не привела к более быстрой передаче. - Запуск
rsync --sockopts=TCP_NODELAYс различными комбинациями настроек TCP с задержкой подтверждения (от 0 до 3) не имел никакого эффекта (Примечание: я запустил tcpdump с настройкой подтверждения по умолчанию 3).
Я создал 4 дампа в виде файлов .csv, 2 при копировании 512 МБ (test-2.file) и 2 при копировании 1024 МБ (test.file). Вы можете скачать экспорт 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 - Samba Wars: новая надежда
Это немного смущает, но главная проблема здесь - опять же - кажется, измерение.
Получается rsync --progress -aстоит около 30 МБ / с скорости записи. Запись с ddиспользованием общего ресурса SMB и его использование time cp /local/test.file /NAS/test.fileбыстрее со скоростью 85-90 МБ / с, и, очевидно, самый быстрый способ копирования - это MacOS Finder со скоростью около 100 МБ / с (что также является самым трудным для измерения методом, поскольку индикатор времени или скорости - кому это нужно, верно? o_O). Мы измерили это, сначала скопировав файл 1 ГБ, а затем файл 10 ГБ, используя секундомер.
Что мы пробовали с момента последнего обновления этого вопроса.
- Скопируйте с клиента Mac на клиент Mac. Оба имеют твердотельные накопители (MacPro записывает на свой диск 250 МБ / с, MacBook Pro - 300 МБ / с). Результат: скудные 65 МБ / с благодаря
ddзаписи из MacBook Pro в MacPro (rsync25 МБ / с). Просмотр 25 МБ / с был моментом, когда мы начали расспрашивать rsync. Тем не менее, 65 МБ / с очень медленные. Так что реализация SMB на macOS кажется ... ну, сомнительной. - Пробовал разные настройки ack с dd и cp - не повезло.
- Наконец, мы нашли способ перечислить все доступные опции 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должен быть действительным эквивалентом.
Во всяком случае, ни одна из этих настроек не имела значения для нас.
Новые вопросы с первого взгляда
Почему rsync такой дорогой способ скопировать один (1!) Файл. Здесь не так много для синхронизации / сравнения, не так ли? Tcpdump также не указывает на возможные издержки.
Почему
ddиcpмедленнее, чем поиск в macOS при переносе на общий ресурс SMB? Кажется, что при копировании с помощью Finder в связи по протоколу TCP значительно меньше подтверждений. (Опять же: настройка Ack, например,delayed_ack=1не имеет никакого значения для нас.)Почему 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 МБ), имена файлов объясняют, что было скопировано (ОС, способ передачи и размер файла).