Користувачі кажуть: «файловий сервер повільний». Ви підключаєтесь по RDP, запускаєте копію і дивитесь, як вона кульгає на 80–120 MB/s у мережі 10GbE, яка мала б легко робити 900+ MB/s. Хтось пропонує: «може, це DNS». Інший каже: «перезавантажте свіч». Ви розглядаєте кар’єру кераміста.
У більшості випадків SMB повільний з непрестижної причини: у вас сучасна мережа з вузьким місцем в старому стилі. Та функція, яку люди забувають увімкнути — або перевірити — це SMB Multichannel. Це різниця між одним TCP-потоком і багатьма, між одним «гарячим» ядром ЦП і машиною, яка справді використовує куплене обладнання.
Функція, яку ви забули: SMB Multichannel (і чому це важливо)
SMB (Server Message Block) — це протокол, що лежить в основі файлового обміну Windows. На сучасних Windows «SMB» фактично означає SMB 3.x, який має реальні корпоративні можливості: шифрування, підпис, прозорий фейловер і (що тут важливо) Multichannel.
SMB Multichannel дозволяє одній SMB-сесії використовувати кілька мережевих з’єднань паралельно. Це може означати кілька NIC, кілька IP на одному NIC або кілька черг/шляхів на одному швидкому NIC, коли працюють потрібні апаратні можливості (RSS). Воно підвищує пропускну здатність, стійкість і часто знижує затримку під навантаженням, бо ви не змушуєте все йти через одну «соломинку» копіювання файлу.
Без Multichannel багато передач поводяться як один TCP-потік. А один TCP-потік має прогнозовані обмеження:
- Одне вікно заторів, яке зростає й зменшується.
- Один набір обробки пакетів, який може лягти важким тягарем на одне ядро ЦП.
- Один шлях, який може зупинитися через одну проблему.
Коли ви вмикаєте Multichannel і він реально активується, зазвичай бачите:
- Вищу пропускну здатність на 10/25/40/100GbE
- Кращий розподіл навантаження на ЦП по ядрах
- Кращу продуктивність для кількох одночасних клієнтів
- Деяку захищеність від відмови лінку (залежно від конфігурації)
Тепер неприємна правда: Multichannel може бути «увімкнений» і при цьому нічого не робити. Це функція з попередніми умовами. Якщо RSS відключений, якщо NIC неправильно налаштований, якщо ви випадково змусили SMB використовувати один інтерфейс, якщо правила фаєрвола креативні — Multichannel чемно сидить і нічого не робить.
Що робити: Трактуйте Multichannel як виробничу залежність: перевірте, що він увімкнений, підтвердіть, що він погоджений, і що під навантаженням дійсно використовуються кілька з’єднань.
Швидкий план діагностики (перший/другий/третій)
Це швидкий шлях: у вас є звернення, скарга, копіювання, яке повзе. Ви хочете знайти вузьке місце, не витрачаючи половину дня на сварки зі свічем.
Перший: доведіть, чи активний SMB Multichannel
- Перевірте, чи функція увімкнена на клієнті й сервері.
- Перевірте, чи SMB-сесія має кілька з’єднань.
- Якщо це одноз’єднаньне, вважайте, що ви в зоні одного потоку, поки не доведено протилежне.
Другий: перевірте RSS / розподіл ЦП і реальність лінків NIC
- Підтвердіть швидкість лінку та дуплекс (так, це все ще важливо).
- Переконайтеся, що RSS увімкнений і має кілька черг.
- Спостерігайте ЦП: якщо одне ядро завантажується під час передачі, ймовірно, обробка пакетів не паралелізується.
Третій: ізолюйте мережу від сховища та накладних витрат SMB
- Запустіть сирий тест пропускної здатності мережі, щоб виключити дискову підсистему.
- Перевірте стан шифрування/підпису SMB; шифрування іноді потрібне, але воно не безкоштовне.
- Подивіться на затримки диска та глибину черги на сервері під час копіювання.
Цитата, яка повинна висіти в кожній команді операцій, бо рятує кар’єру:
«Сподівання — це не стратегія.» — генерал Гордон Р. Салліван
Цікаві факти й коротка історія (щоб дивна поведінка стала зрозумілою)
Проблеми з продуктивністю SMB здаються випадковими, поки ви не згадаєте, через що пройшов SMB: десятиліття сумісності, удари з безпеки й зміни апаратури. Декілька конкретних фактів допоможуть орієнтуватися під час діагностики.
- SMB народився в 1980-х і накопичував можливості з часом, тому поведінка може суттєво відрізнятися між SMB1, SMB2 і SMB3.
- SMB2 (ера Vista/Server 2008) був великим редизайном: менше раунтрипів, більші читання/записи, кращий пайплайнинг. Якщо ви колись порівнювали SMB1 і SMB2, бачите стрибок.
- SMB3 (Windows 8/Server 2012) додав Multichannel і SMB Direct (RDMA), що перетворило SMB з «офісного файлообміну» на «транспорт сховища для дата-центру».
- Після ери WannaCry SMB1 масово відключили в підприємствах. Добре з погляду безпеки; також це стимул для сучасних можливостей SMB.
- Масштабування вікна TCP і сучасні алгоритми керування заторами важливі на мережах з великою затримкою. Один потік на «довгому і товстому» каналі може не використовувати всю ширину пропуску без налаштувань і сприятливого RTT.
- Підпис SMB і шифрування — це не те саме: підпис перевіряє цілісність; шифрування забезпечує конфіденційність. Обидва додають навантаження на ЦП; шифрування особливо може стати вузьким місцем на старих процесорах або при великому навантаженні.
- Multichannel — це не «teaming». Teaming — це агрегація/фейловер на рівні NIC/драйвера; SMB Multichannel працює на рівні протоколу/сесії і може працювати без teaming.
- Receive Side Scaling (RSS) — тихий герой на зайнятих файлових серверах: він дозволяє обробці пакетів розподілятися по ядрах ЦП. Без нього одне ядро може задушити 25GbE як у 2009 році.
- Jumbo-кадри не чарівний перемикач швидкості. Вони можуть зменшити навантаження на ЦП, але невідповідності викликають втрату пакетів і повтори, через що SMB виглядає «повільним і ненадійним».
Жарт №1: SMB як корпоративне зібрання — один говорить за раз ввічливо, але так до п’ятниці нічого не закінчити.
Як SMB уповільнюється в реальному середовищі
«SMB повільний» — це не одна проблема. Це симптом. Найпоширеніші причини, які я бачу в продакшні, вкладаються у кілька категорій.
1) SMB-сесії з одним з’єднанням на швидких лінках
10GbE лінк може нести ~1.1 GB/s корисного трафіку в ідеальних умовах. Але один TCP-потік може бути обмежений через:
- обробку пакетів на одному ядрі (особливо коли RSS вимкнено або некоректно налаштовано)
- втрати/повтори (погані оптичні модулі, тиск буферів, mismatch дуплексу, невідповідність MTU)
- затримку (вищий RTT означає повільніше зростання вікна)
- поведінку кредитування SMB під певні робочі навантаження
Multichannel допомагає, бо розподіляє навантаження по кількох з’єднаннях і може використовувати кілька шляхів/черг NIC.
2) CPU-зв’язане шифрування/підпис
Функції безпеки важливі. Але якщо ви увімкнули шифрування SMB по всій інфраструктурі, не перевіривши запас ЦП, то можете «підвищити» себе до стелі пропускної здатності. На сучасних ЦП з AES-NI це зазвичай нормально. На старих серверах або при дуже швидких лінках — ні.
3) Сховище — це вузьке місце, а не мережа
SMB — це транспорт. Якщо сховище файлового сервера не може забезпечити потрібні IOPS чи пропускну здатність, швидкість копіювання буде обмежена дисками, а не NIC. Це ускладнюється, коли сховище «швидке іноді» (попадання в кеш) і «повільне іноді» (місії кешу, операції parity RAID, снапшоти, сканування антивірусом).
4) Антивірус, фільтри файлів і драйвери фільтра
Захист кінцевих точок на файлових серверах може перетворити послідовні записи на стоп-енд-гоу парад. Якщо копії мають періодичні паузи, і піки затримки диска співпадають, перевірте реальне сканування й драйвери фільтра.
5) Мережева «оптимізація», яка не оптимізує
Вимкнення оффлоадів бо «хтось читав блог», увімкнення jumbo frames на половині шляху, вмикання LACP коли потрібен був SMB Multichannel, або примусове використання одного інтерфейсу SMB для «контролю» — так добрі наміри перетворюються на аварії.
Практичні завдання: 12+ команд, виводів та рішень
Нижче — реальні завдання, які я виконую, коли SMB повільний. Кожне містить команду, приклад реалістичного виводу, що це значить, і яке рішення прийняти.
Примітка: Ці команди виконуються в Windows (PowerShell / CMD). Формат блоків коду нижче зафіксований згідно з вашим запитом; сприймайте підказку як маркер.
Завдання 1: Підтвердити, що SMB Multichannel увімкнено на клієнті
cr0x@server:~$ powershell -NoProfile -Command "Get-SmbClientConfiguration | Select EnableMultichannel,EnableSecuritySignature,RequireSecuritySignature"
EnableMultichannel EnableSecuritySignature RequireSecuritySignature
----------------- ----------------------- ------------------------
True False False
Що це значить: Клієнт спробує використати Multichannel. Підпис не є обов’язковим тут.
Рішення: Якщо EnableMultichannel — False, увімкніть його (Завдання 3). Якщо True, не святкуйте — перевірте переговори (Завдання 5).
Завдання 2: Підтвердити, що SMB Multichannel увімкнено на сервері
cr0x@server:~$ powershell -NoProfile -Command "Get-SmbServerConfiguration | Select EnableMultichannel,EncryptData,RejectUnencryptedAccess"
EnableMultichannel EncryptData RejectUnencryptedAccess
----------------- ----------- ------------------------
True False False
Що це значить: Сервер дозволяє Multichannel і не примушує шифрування.
Рішення: Якщо Multichannel на сервері вимкнено, увімкніть його (Завдання 4). Якщо шифрування примусове, заплануйте перевірку впливу на ЦП і пропускну здатність (Завдання 10).
Завдання 3: Увімкнути SMB Multichannel на клієнті (якщо вимкнено)
cr0x@server:~$ powershell -NoProfile -Command "Set-SmbClientConfiguration -EnableMultichannel $true -Force; Get-SmbClientConfiguration | Select EnableMultichannel"
EnableMultichannel
-----------------
True
Що це значить: Налаштування на стороні клієнта встановлено.
Рішення: Повторіть на серверах/VDI-образах через GPO/desired state. Потім перевірте активні з’єднання (Завдання 5).
Завдання 4: Увімкнути SMB Multichannel на сервері (якщо вимкнено)
cr0x@server:~$ powershell -NoProfile -Command "Set-SmbServerConfiguration -EnableMultichannel $true -Force; Get-SmbServerConfiguration | Select EnableMultichannel"
EnableMultichannel
-----------------
True
Що це значить: Файловий сервер буде погоджувати Multichannel, коли клієнти його підтримують.
Рішення: Якщо продуктивність була поганою, повторно протестуйте передачі і перевірте активні SMB-з’єднання (Завдання 5/6).
Завдання 5: Підтвердити, що SMB-сесія дійсно використовує кілька з’єднань
cr0x@server:~$ powershell -NoProfile -Command "Get-SmbMultichannelConnection | Select ServerName,ClientInterfaceIndex,ServerInterfaceIndex,ClientIPAddress,ServerIPAddress,RSSCapable | Format-Table -AutoSize"
ServerName ClientInterfaceIndex ServerInterfaceIndex ClientIPAddress ServerIPAddress RSSCapable
---------- -------------------- -------------------- ------------- ------------- ----------
FS01 12 9 10.10.20.51 10.10.20.10 True
FS01 13 10 10.10.21.51 10.10.21.10 True
Що це значить: Два з’єднання активні і RSS-підтримувані. Це бажана конфігурація.
Рішення: Якщо ви бачите лише один рядок, фактично у вас single-channel. Перейдіть до перевірок RSS/NIC (Завдання 7–9).
Завдання 6: Перевірити SMB-з’єднання та діалект (чи ми на SMB3?)
cr0x@server:~$ powershell -NoProfile -Command "Get-SmbConnection | Select ServerName,ShareName,Dialect,NumOpens,Encrypted | Format-Table -AutoSize"
ServerName ShareName Dialect NumOpens Encrypted
---------- --------- ------- -------- ---------
FS01 data 3.1.1 42 False
Що це значить: Клієнт використовує SMB 3.1.1 (добре). Шифрування для цього шару/сесії вимкнено.
Рішення: Якщо діалект нижчий, можливо, ви маєте політику/обмеження сумісності. Якщо Encrypted=True і продуктивність погана, перевірте запас ЦП (Завдання 10).
Завдання 7: Перевірити швидкість лінку NIC на клієнті/сервері
cr0x@server:~$ powershell -NoProfile -Command "Get-NetAdapter | Select Name,Status,LinkSpeed | Format-Table -AutoSize"
Name Status LinkSpeed
---- ------ ---------
Ethernet0 Up 10 Gbps
Ethernet1 Up 10 Gbps
Що це значить: Лінки підключені на очікуваній швидкості.
Рішення: Якщо ви бачите 1 Gbps замість 10GbE, зупиніться. Виправте кабелі/оптику/налаштування порту свіча перед тим, як звинувачувати SMB.
Завдання 8: Перевірити, що RSS увімкнений і має черги (клієнт і сервер)
cr0x@server:~$ powershell -NoProfile -Command "Get-NetAdapterRss | Select Name,Enabled,NumberOfReceiveQueues,MaxNumberOfReceiveQueues | Format-Table -AutoSize"
Name Enabled NumberOfReceiveQueues MaxNumberOfReceiveQueues
---- ------- --------------------- ------------------------
Ethernet0 True 8 16
Ethernet1 True 8 16
Що це значить: RSS увімкнений з кількома чергами. Це фундаментально для високої пропускної здатності SMB на одному швидкому NIC і корисно для Multichannel.
Рішення: Якщо RSS відключений або черга лише 1, увімкніть RSS (Завдання 9). Потім протестуйте повторно і спостерігайте розподіл ЦП.
Завдання 9: Увімкнути RSS (обережно) на адаптері
cr0x@server:~$ powershell -NoProfile -Command "Enable-NetAdapterRss -Name Ethernet0; Get-NetAdapterRss -Name Ethernet0 | Select Name,Enabled,NumberOfReceiveQueues"
Name Enabled NumberOfReceiveQueues
---- ------- ---------------------
Ethernet0 True 8
Що це значить: RSS тепер увімкнено на цьому NIC.
Рішення: Якщо увімкнення RSS спричиняє нестабільність (рідко, специфічно для драйвера), оновіть драйвери/прошивку NIC. Не «вирішуйте» проблему вимкненням RSS постійно, якщо не хочете викликів о 2:00 ранку.
Завдання 10: Перевірити, чи шифрування SMB примусове, і оцінити ризик по ЦП
cr0x@server:~$ powershell -NoProfile -Command "Get-SmbShare | Select Name,EncryptData | Format-Table -AutoSize"
Name EncryptData
---- -----------
data False
secure True
Що це значить: Тільки шар secure вимагає шифрування.
Рішення: Якщо «все повільно» і шифрування ввімкнено всюди, виміряйте ЦП під час копій. Якщо ЦП — стеля, розгляньте вибіркове шифрування (за класифікацією даних) або оновлення ЦП/апаратні оффлоади NIC — не вимикайте шифрування лише через зручність.
Завдання 11: Спостерігати гарячі ділянки ЦП під час копіювання (на сервері)
cr0x@server:~$ powershell -NoProfile -Command "Get-Counter '\Processor(*)\% Processor Time' -SampleInterval 1 -MaxSamples 5 | Select -ExpandProperty CounterSamples | Sort CookedValue -Descending | Select -First 5 Path,CookedValue"
Path CookedValue
---- -----------
\\FS01\processor(3)\% processor time 96.8125
\\FS01\processor(7)\% processor time 22.125
\\FS01\processor(5)\% processor time 18.4375
\\FS01\processor(_total)\% processor time 31.020
\\FS01\processor(1)\% processor time 14.625
Що це значить: Одне ядро завантажене, тоді як загальне ЦП не на межі. Класична ситуація «одна черга / один потік / поганий розподіл».
Рішення: Повторно перевірте RSS, черги та Multichannel-з’єднання. Якщо шифрування увімкнено, можливо, ви вдаряєте по однопотоковому шифруванню в частинах стеку залежно від навантаження й системи.
Завдання 12: Перевірити вибір мережевого інтерфейсу клієнтом і його можливості
cr0x@server:~$ powershell -NoProfile -Command "Get-SmbClientNetworkInterface | Select InterfaceIndex,IPAddress,RSSCapable,LinkSpeed | Format-Table -AutoSize"
InterfaceIndex IPAddress RSSCapable LinkSpeed
-------------- --------- ---------- ---------
12 10.10.20.51 True 10 Gbps
13 10.10.21.51 True 10 Gbps
Що це значить: Клієнт бачить два SMB-спроможні інтерфейси, обидва RSS-можливі і швидкі.
Рішення: Якщо очікувані інтерфейси тут не відображаються, SMB не зможе їх використати для Multichannel. Виправте маршрутизацію, прив’язку NIC або правила фаєрвола, щоб інтерфейси були доступні.
Завдання 13: Виміряти сирий мережевий пропуск (щоб виключити диски)
cr0x@server:~$ iperf3 -c fs01 -P 4 -t 10
Connecting to host fs01, port 5201
[ 5] local 10.10.20.51 port 53122 connected to 10.10.20.10 port 5201
[ 7] local 10.10.20.51 port 53124 connected to 10.10.20.10 port 5201
[ 9] local 10.10.20.51 port 53126 connected to 10.10.20.10 port 5201
[ 11] local 10.10.20.51 port 53128 connected to 10.10.20.10 port 5201
[SUM] 0.00-10.00 sec 10.6 GBytes 9.10 Gbits/sec 0 sender
[SUM] 0.00-10.00 sec 10.6 GBytes 9.09 Gbits/sec receiver
Що це значить: Мережа може дати ~9.1 Gbps. Сьогодні дріт не ваша проблема.
Рішення: Якщо iperf також повільний — виправляйте шлях мережі/MTU/втрати. Якщо iperf швидкий, а SMB повільний — зосередьтесь на налаштуваннях SMB, ЦП, шифруванні та сховищі.
Завдання 14: Перевірити повтори та помилки (швидкий сниф без Wireshark)
cr0x@server:~$ powershell -NoProfile -Command "netstat -s -p tcp | Select-String -Pattern 'Retransmitted|Segments Retransmitted|Errors'"
Segments Retransmitted = 1842
Що це значить: Є повторы. Невеликі повтори нормальні, але багато їх під час однієї копії — підозріло.
Рішення: Якщо повтори швидко зростають під час передач, перевірте невідповідність MTU, дуплексу, оптику, лічильники скидань на свічі та драйвери NIC. SMB виглядає «повільним», бо TCP виконує відновлення.
Завдання 15: Перевірити узгодженість MTU/jumbo frames (сторона Windows)
cr0x@server:~$ powershell -NoProfile -Command "Get-NetIPInterface | Where-Object {$_.InterfaceAlias -like 'Ethernet*' -and $_.AddressFamily -eq 'IPv4'} | Select InterfaceAlias,NlMtu | Format-Table -AutoSize"
InterfaceAlias NlMtu
-------------- -----
Ethernet0 9000
Ethernet1 1500
Що це значить: У вас невідповідність MTU між інтерфейсами. Якщо SMB Multichannel поширює трафік по обох, це може призвести до непередбачуваної поведінки.
Рішення: Стандартизувати MTU в кінці в кінець згідно з дизайном мережі. Якщо не можна, обмежте інтерфейси, які використовує SMB (обережно), або виправте другий інтерфейс.
Завдання 16: Перевірити затримку диска на сервері під час копіювання
cr0x@server:~$ powershell -NoProfile -Command "Get-Counter '\PhysicalDisk(_Total)\Avg. Disk sec/Read','\PhysicalDisk(_Total)\Avg. Disk sec/Write' -SampleInterval 1 -MaxSamples 5 | Select -ExpandProperty CounterSamples | Format-Table -AutoSize Path,CookedValue"
Path CookedValue
---- -----------
\\FS01\physicaldisk(_total)\avg. disk sec/read 0.0021
\\FS01\physicaldisk(_total)\avg. disk sec/write 0.0385
Що це значить: Записи в середньому ~38 ms — це не «швидке сховище». Це обмежить швидкість SMB запису незалежно від мережі.
Рішення: Якщо піки затримки диска корелюють зі сповільненням SMB, ви маєте справу з проблемами сховища: штрафи RAID, снапшоти, антивірус, або обмеження бекенду.
Три корпоративні міні-історії (що насправді відбувається)
Міні-історія 1: Інцидент, спричинений хибним припущенням
Звернення було просте: «шари інженерії повільні; збірки таймаутяться». Це був понеділок, звісно, і відповідальний вже годину отримував повідомлення в Slack. Файловий сервер мав два порти 10GbE. Порти свіча виглядали чистими. Панель стану масиву зберігання була зеленою. Усі припустили, що мережа і сховище — норм, тож «SMB просто SMB».
Хибне припущення: «два NIC означають, що копіювання автоматично використовуватиме обидва». Хтось колись налаштовував NIC teaming, потім видалив це під час оновлення драйвера і ніколи не перевіряв продуктивність. SMB Multichannel на файловому сервері було відключено, бо старий базовий жорсткий профіль безпеки його вимкнув і ніхто цього не помітив.
Симптоми були класичні: один TCP-потік завантажував одне ядро, пропускна здатність коливалася на рівні того, що може обробити зайняте ядро, і кілька клієнтів ввічливо чекали у черзі. Сервер мав багато загального ЦП, але робота не розподілялася.
Виправлення було нудно просте: увімкнути SMB Multichannel, перевірити RSS і підтвердити, що для активних клієнтів з’явилися кілька SMB-з’єднань. Пропускна здатність подвоїлася для багатьох клієнтів одразу, і хорове «мережа повільна» вщухло до наступного інциденту, як це часто буває.
Урок не в тому, що Multichannel — магія. Урок: не припускайте, що апаратні можливості, за які ви платили, дійсно використовуються. Перевіряйте погоджені параметри, а не лише галочки.
Міні-історія 2: Оптимізація, що дала зворотний ефект
Інша організація, інший вид болю. Ініціатива безпеки вирішила, що всі файлові шари повинні вимагати шифрування SMB. Розумна мета. Роллаут був швидкий, широкий і благословенний багатьма комітетами — ознака того, що ніхто не робив бенчмарк.
За кілька днів користувачі скаржились, що великі копії стали «стрибкоподібними». Загальний ЦП сервера не був по максимуму, але система відчувалася обмеженою в пікові години. Команди сховища й мережі кидали одна на одну відповідальність. Тим часом розробники почали копіювати дані локально, що ніколи не є бажаним рішенням з погляду комплаєнсу.
Корінь проблеми був передбачуваний: шифрування додало навантаження на ЦП, і вузьке місце зрушило з NIC на ЦП; при певних робочих навантаженнях вартість криптооперацій концентрувалася так, що не масштабувалась лінійно по ядрах. Multichannel допоміг трохи, RSS допоміг трохи, але фундаментальна межа залишилася.
Команда відкотила загальну політику і замінила її на шифрування на рівні шару для чутливих наборів даних, плюс план оновлення обладнання для серверів, які дійсно потребували завжди увімкненого шифрування на високих швидкостях. Безпека отримала реальні покращення. Операції повернули продуктивність. Ніхто не міг більше ігнорувати закони фізики.
Жарт №2: Увімкнути шифрування скрізь без тестування — наче наклеїти «turbo» на машину й чекати, що двигун стане енергійнішим.
Міні-історія 3: Нудна, але правильна практика, яка врятувала
Ще одна організація, ще одна платформа файлів. Вони щоквартально виконували «нудні перевірки» на своїх Windows-файлових серверах: експортували конфіги SMB, фіксували версії драйверів NIC, перевіряли стан RSS і запускали стандартизований тест пропускної здатності з jump host. Без героїзму. Без ночних сюрпризів. Одна рутина.
Під час одного кварталу тест показав падіння пропускної здатності на одному вузлі кластера. Нічого не було «вимкнено». Користувачі ще не скаржились. Але тренд був очевидний: вузол значно повільніший за сусідів.
Оскільки були базові показники, вони порівняли конфіги і виявили, що після оновлення прошивки на тому вузлі RSS вимкнувся. Це була одна перемикач. Оновлення вендора не «зламало SMB»; воно змінило критичну для продуктивності поведінку NIC.
Вони знову увімкнули RSS, повторили тест, і вузол повернувся в норму. Ніяких інцидентів. Ніяких листів від керівництва. Найкращі аварії — це ті, яких не сталося.
Поширені помилки: симптом → коренева причина → виправлення
Розділ простий і різкий — ваш час цінний.
1) Пропускна здатність застрягла біля 80–200 MB/s на 10GbE
Симптом: Велике послідовне копіювання ніколи не досягає лінійної швидкості; ЦП показує одне гаряче ядро.
Корінна причина: Один SMB-з’єднання і/або RSS відключений (обробка на одному ядрі).
Виправлення: Увімкніть SMB Multichannel на обох кінцях; підтвердіть кілька Multichannel-з’єднань; увімкніть RSS і забезпечте кілька receive-черг; оновіть драйвери/прошивку NIC, якщо RSS працює неправильно.
2) Multichannel «увімкнений», але з’являється лише одне з’єднання
Симптом: EnableMultichannel=True, але Get-SmbMultichannelConnection показує один рядок.
Корінна причина: Лише один придатний інтерфейс/IP; список мережевих інтерфейсів клієнта SMB не включає другий NIC; фаєрвол/маршрут перешкоджає паралельному шляху; інтерфейси не RSS-спроможні.
Виправлення: Перевірте Get-SmbClientNetworkInterface і Get-SmbServerNetworkInterface; переконайтеся, що обидві сторони мають доступні IP на кожному інтерфейсі; підтвердіть RSS-можливість; виправте правила фаєрвола для SMB (TCP 445) на кожному інтерфейсі.
3) Копіювання швидке при читанні, жахливе при записі
Симптом: Завантаження з шару — нормально; відвантаження — повзає; затримки запису диска стрибкоподібні.
Корінна причина: Штраф/затримка запису бекенда сховища (RAID, снапшоти, thin provisioning, конфлікт) або антивірусне сканування при записі.
Виправлення: Виміряйте затримку запису диска під час копіювання; перевірте виключення антивірусу чи його налаштування; перевірте стан пулу сховища і поведінку кешу запису; не діагностуйте це як «мережу» без перевірки диска.
4) Продуктивність нестабільна: швидко, потім стоп
Симптом: Швидкість копіювання коливається; користувачі описують «зависання».
Корінна причина: Повтори через невідповідність MTU, мікросплески, скидання буферів на свічі або проблемні оффлоади; іноді драйвери фільтра.
Виправлення: Перевірте повтори; стандартизуйте MTU кінця-в-кінці; перевірте лічильники портів свіча; розгляньте вимкнення лише проблемної опції оффлоаду після доказів (не за відчуттями).
5) SMB повільний лише для однієї підмережі/VLAN
Симптом: Той самий сервер, інша клієнтська мережа, і зовсім інша пропускна здатність.
Корінна причина: Інший MTU-шлях, ACL, політика QoS або асиметрична маршрутизація; іноді «оптимізатор WAN».
Виправлення: Порівняйте результати iperf для кожної підмережі; перевірте MTU і повтори; підтвердіть симетрію маршруту; аудитуйте політики QoS.
6) Все стало повільніше після «закріплення безпеки»
Симптом: Після розгортання базових політик пропускна здатність SMB впала, ЦП зріс.
Корінна причина: Повсюдне вимагання підпису; примусове шифрування у всіх місцях; Multichannel відключено; налаштування сумісності для старих систем.
Виправлення: Проаналізуйте відмінності конфігурацій SMB клієнта/сервера; застосуйте шифрування вибірково; зберігайте підпис там, де потрібно; знову увімкніть Multichannel з перевіркою.
Чеклісти / покроковий план
Чекліст A: Повернути очікувану пропускну здатність у LAN 10/25GbE
- Підтвердити швидкість лінку на обох сторонах NIC (
Get-NetAdapter). - Підтвердити діалект SMB — 3.x (
Get-SmbConnection). - Увімкнути й перевірити SMB Multichannel на обох кінцях (
Get-Smb*Configuration,Get-SmbMultichannelConnection). - Переконатися, що RSS увімкнений з кількома чергами (
Get-NetAdapterRss). - Запустити iperf щоб перевірити сирий мережевий канал.
- Спостерігати розподіл ЦП під час тривалої передачі (Perf Counters).
- Перевірити затримку диска під час тієї ж передачі (Perf Counters).
- Лише після цього торкайтеся оффлоадів, jumbo frames і «розширених» перемикачів.
Чекліст B: Переконатися, що Multichannel реально працює (не тільки увімкнений)
- На клієнті перелічте інтерфейси SMB (
Get-SmbClientNetworkInterface). Потрібні кілька придатних інтерфейсів. - На сервері перелічте інтерфейси SMB (використовуйте
Get-SmbServerNetworkInterface, де доступно) і підтвердіть відповідні IP. - Розпочніть тривалу передачу (великий файл, не директорія з дрібними файлами).
- Перевірте
Get-SmbMultichannelConnectionпід час передачі. - Якщо досі одне з’єднання, дослідіть фаєрвол/маршрутизацію/MTU/RSS-правомочність.
Чекліст C: Визначити, чи є шифрування вашим вузьким місцем
- Підтвердіть, чи шифрування увімкнене на рівні шару/сесії (
Get-SmbShare,Get-SmbConnection). - Запустіть ту саму копію з вимкненим шифруванням на тестовому шарі (якщо політика дозволяє) для порівняння.
- Під час зашифрованої копії спостерігайте ЦП і гарячі ядра.
- Якщо ЦП — обмежувач, оберіть одне: більше ЦП, вибіркове шифрування або RDMA (SMB Direct), де доцільно.
Питання й відповіді
1) Чи SMB Multichannel те саме, що NIC teaming?
Ні. Teaming — це конструкція NIC/драйвера; Multichannel — SMB, що використовує кілька з’єднань на рівні протоколу/сесії. Ви можете використовувати Multichannel без teaming, і часто саме так варто робити.
2) Якщо в мене один 25GbE NIC, чи Multichannel все одно допоможе?
Іноді. Multichannel може створювати кілька з’єднань поверх одного інтерфейсу, але більший виграш на одиночному швидкому NIC зазвичай дає RSS і достатня кількість receive-черг та ЦП для обробки пакетів.
3) Чому одне SMB-копіювання не досягає лінійної швидкості?
Тому що один TCP-потік може бути обмежений обробкою пакетів на одному ядрі, алгоритмами керування заторами, втратами і затримкою. Multichannel і RSS зменшують ці вузькі місця паралелізацією роботи.
4) Чи Multichannel автоматично активується, коли ввімкнений?
Воно погоджується автоматично, але лише якщо обидві сторони підтримують його і бачать кілька придатних шляхів/інтерфейсів. «Увімкнено» ≠ «активно». Завжди перевіряйте Get-SmbMultichannelConnection.
5) Чи варто увімкнути jumbo frames, щоб виправити повільний SMB?
Не як перший крок. Jumbo-кадри можуть допомогти ефективності ЦП, але часткове розгортання створює втрати/повтори, що погіршують SMB. Спочатку виправте Multichannel/RSS і підтвердіть відсутність втрат.
6) Чи шифрування SMB вб’є продуктивність?
Залежить від можливостей ЦП, робочого навантаження і швидкості лінку. На сучасних ЦП це може бути прийнятно; на старих серверах або дуже швидких лінках шифрування може стати обмежувачем. Виміряйте до й після, і розгляньте вибіркове шифрування.
7) Чому копіювання багатьох дрібних файлів повільніше за один великий?
Операції метаданих, перерахунок каталогу і витрати на відкриття/закриття файлу домінують. Multichannel допомагає пропускній здатності, але не усуває балакучість і накладні витрати метаданих сховища при «мільйонах дрібних файлів».
8) Чи антивірус на файловому сервері може сповільнити SMB?
Так, особливо при записах. Режим реального часу може додавати затримку на кожну операцію і перетворювати рівномірну пропускну здатність у стрибкоподібну. Узгоджуйте виключення й режими сканування з командами безпеки і перевіряйте лічильники затримки диска.
9) У чому різниця між SMB Multichannel і SMB Direct?
Multichannel використовує кілька TCP-з’єднань. SMB Direct використовує RDMA (спеціальні NIC і конфігурацію), що дозволяє оминати частину стеку TCP/IP для нижчої затримки і меншого завантаження ЦП. Відмінно, коли можна його запустити; Multichannel — більш поширений виграш.
10) Який найшвидший спосіб довести, що проблема не в мережі?
Запустіть iperf між тими самими хостами на тих самих інтерфейсах і порівняйте. Якщо iperf дає очікувану пропускну здатність, а SMB — ні, то вузьке місце, ймовірно, у налаштуваннях SMB, ЦП, шифруванні або сховищі.
Висновок: наступні кроки, які ви можете зробити сьогодні
Якщо SMB повільний, припиніть трактувати це як містичну проблему Windows. Це система: NIC, черги ЦП, поведінка TCP, накладні витрати на безпеку і затримки диска — все це впливає на кінцеве число.
Ваші практичні наступні кроки:
- Перевірити, що SMB Multichannel увімкнений на клієнті й сервері, а потім підтвердити його активність за допомогою
Get-SmbMultichannelConnection. - Перевірити RSS і кількість черг на NIC, що несуть SMB-трафік.
- Виміряти сирий мережевий пропуск за допомогою iperf, щоб відокремити мережу від SMB/сховища.
- Виміряти ЦП і затримку диска під час тієї ж передачі; визначити, яка підсистема реально обмежує вас.
- Бути обережним із шифруванням: застосовувати його там, де потрібно, і закладати ресурси ЦП відповідно.
Зробіть це — і «SMB повільний» зазвичай перетворюється на конкретне, виправне вузьке місце. А це найкращий тип проблеми: той, що закінчується.