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 4 ТБ (HDN724040ALE640) в RAID1 с только гигабитными компонентами Ethernet и новыми кабелями Ethernet (по крайней мере Cat5e).
Клиенты Mac сначала производили только 20 МБ / с. Но применение signing_required=no fix (описанного здесь) увеличило скорость записи до 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 МБ / s (это также метод, который сложнее всего измерить, поскольку нет индикатора времени или скорости - кому это нужно, верно? о_О). Мы измерили это, сначала скопировав файл 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 finder, при передаче на общий ресурс 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 МБ), имена файлов объясняют, что было скопировано (ОС, способ передачи и размер файла).