Почему существует разница в скорости записи между 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.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) клиента.

Что мы уже пробовали:

сеть

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 друг против друга. Примерно равный.
   Смотрите обновление ниже: Использовал неправильный метод, чтобы исключить реализацию macOS для SMB. SMB в Windows работает быстрее, причиной могут быть новые настройки SMB, поставляемые с macOS 10.11 и 10.12.
2. Попытался настроить параметры SMB, включая параметры сокета (следуя этой инструкции )
3. Пробовал разные версии отложенных настроек ака rsync --sockopts=TCP_NODELAY(комментарии)

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

система

1. Следил за загрузкой процессора и оперативной памяти. Ничто не исчерпывается. Процессор около 20%, ОЗУ около 25% во время передачи.
2. Протестировал тот же NAS с DSM 5.xx в почти готовой конфигурации. Дополнительное программное обеспечение не установлено. Примечание: у нас есть два из них в разных местах. Они синхронизируются через Synology CloudSync. Тот же результат.
3. Отключено все ненужное, что могло бы привлечь системные ресурсы.

Мы думаем, что это скорее настройка по умолчанию, никаких необычных адаптаций, клиентов или сетевых компонентов. В соответствии с показателями, которые публикует 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.

Что я нашел:

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 с задержкой подтверждения (от 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 ГБ, используя секундомер.

Что мы пробовали с момента последнего обновления этого вопроса.

1. Скопируйте с клиента Mac на клиент Mac. Оба имеют твердотельные накопители (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. Почему ddи cpмедленнее, чем поиск в macOS при переносе на общий ресурс SMB? Кажется, что при копировании с помощью 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, если это возможно, для увеличения производительности. 2. он тестировал по протоколу NFS, но столкнулся с той же проблемой скорости, поэтому, возможно, IT не причина протокола (SMB2 / 3, AFP и т. Д.).

Мы используем rsync для копирования данных с одного файлового сервера на другой с использованием монтирования NFS3 по каналу 10 Гб. Мы обнаружили, что увеличение размеров буфера (в качестве быстрого теста) повышает производительность. При использовании --sparse это увеличивает производительность в 50 раз, с 2 МБ / с до 100 МБ / с.

2. Вот еще одна интересная проверка производительности rsync. https://lwn.net/Articles/400489/

У LWN.net есть выводы о том, что проблема с производительностью может иметь отношение к ядру даже в статье, опубликованной в 2010 году, и мы не можем изменить ее на NAS или MacOS. Тем не менее, эта статья наводит нас на мысль, что проблема с ядром может быть вызвана вычислением контрольной суммы (мои предположения)

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

Также цитата комментариев имеет это:

Обратите внимание, что rsync всегда проверяет, что каждый переданный файл был правильно восстановлен на принимающей стороне, проверяя контрольную сумму всего файла, которая генерируется при передаче файла.

обновление 1 : моя ошибка, это описание для --checksum. проверьте это здесь: [Улучшено описание опции --checksum.] PS, у меня недостаточно репутации, чтобы публиковать более 2 ссылок.

но я не могу найти то же описание на странице руководства rsync, так что я предполагаю, что кто-то говорит ниже Bold:

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

Поэтому сравните с cp / tar / cat: если мы используем rsync для копирования множества маленьких или больших файлов, это может привести к снижению производительности. НО из-за того, что я не могу прочитать исходный код rsync, поэтому я не могу подтвердить, что это конечная причина.

моя идея постоянно проверять:

1. Какую версию rsync использует awenro для тестирования? Не могли бы вы обновить до последней версии?
2. давайте посмотрим, что выводится при использовании --stats и -v с --debug = FLAGS

флаги

--stats Указывает rsync напечатать подробный набор статистических данных о передаче файлов, что позволяет вам определить, насколько эффективен алгоритм rsync для ваших данных.

--debug = FLAGS Эта опция позволяет вам детально контролировать выходные данные отладки, которые вы хотите видеть. За отдельным именем флага может следовать номер уровня, где 0 означает отключение этого выхода, 1 - выходной уровень по умолчанию, а более высокие числа увеличивают выход этого флага (для тех, которые поддерживают более высокие уровни). Используйте --debug = help, чтобы увидеть все доступные имена флагов , что они выводят, и какие имена флагов добавляются при каждом увеличении подробного уровня.

наконец, я бы рекомендовал прочитать этот дополнительный пост, чтобы получить больше знаний.
«Как передавать большие объемы данных через сеть» moo.nac.uci.edu/~hjm/HOWTO_move_data.html

Rsync / ssh шифрует соединение smb, если я правильно помню. Если это всего лишь один файл, то одна система может прочитать этот файл, а другая - нет. Также обратите внимание, что для того, чтобы MTU был выше 1514, вам нужно включить пакеты "giants" / "Jumbo Frames", тот факт, что пакеты должны быть дополнительно сокращены, может указывать на то, что существуют дополнительные затраты для "перепаковки" пакета. Второе, на что следует обратить внимание, это то, что «гиганты» / «Jumbo Frames» должны быть включены с обоих концов и ВСЕ между.

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

Среднее значение 80 МБ / с между моей NAS (ПК с виртуальными машинами, одна из которых является NAS) и моей станцией (ПК) с sftp (используется sshfs) [гиганты не включены], а промежуточное устройство - микротик 2011 (собирается) только чип переключатель Tru)

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

редактировать: SMB не очень эффективен для передачи файлов.