Перенос домашнего хранилища на UniFi UNAS Pro 8 стал частью более масштабной модернизации домашней лаборатории. Основной десктоп IRONHEART получил сетевую карту Intel E610-XT2 10GbE, NAS подключён по 10GbE, а в той же сети работает мини-ПК Minisforum MS-01 с 10GbE SFP+ соединением, на котором крутятся Immich, Portainer и ещё несколько сервисов.

Везде указано 10 гигабит. Windows показывает 10 гигабит. UniFi показывает 10 гигабит. SMB-копирование использует нужную сетевую карту, но скорость копирования файлов держится в районе 100-200 мегабит в секунду, что не может не расстраивать.

Первым делом под подозрение попал сам NAS и вращающиеся в нём диски. У UNAS шесть 16-терабайтных жёстких дисков в RAID 6 и пара NVMe SSD, используемых как кэш. На MS-01 к тому же работает Immich, чья фотобиблиотека хранится на UNAS, — то есть постоянно идут чтения миниатюр, метаданных и небольшие фоновые записи. Все выглядело как разумные подозреваемые.

SSD-кэш UNAS был переключён с режима чтения-записи в режим только для чтения — заметной разницы не было. Immich был полностью остановлен — тоже без изменений. Проверка iostat показала, что диски не загружены под завязку. Проверили подписывание SMB и сетевое сканирование Windows Defender. Скорость по-прежнему оставалась низкой.

После этого тестирование NAS было прекращено, и напрямую между Windows-десктопом и MS-01 запустили iperf3:

iperf3 -c 192.168.1.222 -P 4

133 Мбит/сек

Обратный тест дал результат получше, но всё равно неправильный:

iperf3 -c 192.168.1.222 -P 4 -R

1,33 Гбит/сек

Странно. Теперь диски, SMB, Immich, RAID и сам NAS были полностью выведены из уравнения. Проблема оказалась в связке Windows и сетевой карты, причём странным образом асимметричная.

Статистика адаптера Intel показала следующее:

Get-NetAdapterStatistics -Name "Ethernet - 10 Gig Intel"

Счётчик ReceivedDiscardedPackets показывал почти миллион отброшенных пакетов. За один десятисекундный тест iperf3 счётчик увеличился ещё на 268. Причина?

Драйвер E610 использовал буферы приёма по умолчанию — 512, хотя поддерживал до 4096. Буферы были увеличены — а увеличенные буферы это хорошо.

Set-NetAdapterAdvancedProperty `
  -Name "Ethernet - 10 Gig Intel" `
  -DisplayName "Receive Buffers" `
  -DisplayValue "4096"

Число отброшенных пакетов в следующем тесте упало с 268 до нуля, а пропускная способность на приём выросла с 1,33 Гбит/сек до 5,15 Гбит/сек. Направление передачи по-прежнему оставалось ужасным — около 313 Мбит/сек. Следующим экспериментом стало отключение Large Send Offload (LSO) V2 для IPv4:

Set-NetAdapterAdvancedProperty `
  -Name "Ethernet - 10 Gig Intel" `
  -DisplayName "Large Send Offload V2 (IPv4)" `
  -DisplayValue "Disabled"

После этого тест iperf3 запустили снова.

7,03 Гбит/сек

Это не опечатка. С 313 Мбит/сек до 7,03 Гбит/сек — изменением одной настройки сетевой карты. Вот это поворот.

LSO существует не просто так: Windows может передавать сетевой карте крупные TCP-буферы и позволять адаптеру/драйверу самостоятельно разбивать их на сетевые пакеты, снижая нагрузку на процессор. При этом Microsoft прямо отмечает, что offload сегментации может снижать максимальную устойчивую пропускную способность на некоторых сетевых адаптерах и в некоторых конфигурациях. Обычно LSO полезен, но не в данном случае.

В конкретном сочетании Windows и Intel E610-XT2 что-то в пути обработки LSO для IPv4 работало очень, очень плохо. Пока непонятно, идёт ли речь о баге драйвера Intel, проблеме прошивки, взаимодействии с Windows или особенности конкретной машины, поэтому это не повод превращать частный случай в универсальный совет отключать LSO всем подряд. Сначала измерь, потом режь. Точнее, дважды измерь.

В финале вернулись к тесту, с которого всё началось, — копированию большого файла на UNAS. Robocopy показал:

Speed : 350,201,354 Bytes/sec.
Speed : 20,038.682 MegaBytes/min.

Около 350 МБ/сек, или 2,8 Гбит/сек устойчивой реальной записи по SMB на NAS с шестью дисками в RAID 6.

Так и должно быть. Полезный вывод здесь не в том, что «нужно отключать LSO». Он в том, что если хранилище загадочно тормозит, рано или поздно стоит перестать тестировать само хранилище. iperf3 одним действием исключил из эксперимента NAS, файловую систему, RAID, кэш, SMB и диски. Как только выяснилось, что тормозит сама сеть, проблема резко сузилась. И иногда маленький чекбокс с подписью Large Send Offload способен заставить гигабитную карту работать так, будто на дворе 2004 год.

Итог: при включённом LSO V2 для IPv4 iperf3 между Windows и Linux выдавал около 313 Мбит/сек. Отключение одного этого offload-параметра подняло тот же самый тест до 7,03 Гбит/сек. Важная оговорка — именно на этой машине, поскольку в общем случае LSO полезен, и это не универсальная рекомендация отключать его повсеместно.