Повільні копії на NAS: налаштування SMB, що справді мають значення

Що насправді уповільнює копії SMB

SMB (Server Message Block) — це не одна річ. Це сімейство протоколів із версіями, переговором діалекту, опційною цілісністю, опційним шифруванням, опційним multichannel і купою «корисної» поведінки клієнта. Швидкість копіювання — це властивість, що виникає внаслідок взаємодії таких чинників:

• Латентність зберігання (особливо малі випадкові записи при «безлічі дрібних файлів»).
• Пропускна здатність мережі (очевидно), а також втрати, повторні передачі та bufferbloat (менш очевидно).
• Цикли CPU на клієнті й сервері для підпису/шифрування та для будь-яких антивірусних/фільтрувальних драйверів.
• Flow control SMB: кредити, незавершений I/O і те, скільки запитів може бути «в польоті».
• Хаос метаданих: створення файлів, закриття, читання атрибутів, перевірки ACL, durable handles, перерахування директорій.
• Поведінка застосунку: копія через Explorer проти robocopy проти застосунка, що робить синхронізацію.

Два завдання копіювання одного «розміру» можуть поводитися як різні планети:

• Один 50 ГБ ISO — головно послідовні I/O. Він прагне пропускної здатності та великих буферів.
• Два мільйони файлів по 16 КБ — це метадані й випадкові I/O. Він прагне низької латентності, швидких операцій з директоріями та адекватних політик антивірусу.

Налаштування продуктивності SMB, зроблене правильно, означає не боротися з вашим вузьким місцем. Зроблене неправильно — це культ: більше MTU, більше потоків, більше кешу, більше «оптимізації». Так ви отримуєте NAS, «оптимізований» до дуже дорогого обігрівача.

Жарт №1: налаштування SMB як приправляння супу — додавайте сіль повільно, бо «висипати всю сільницю» — це як отримати дзвінок о 2-й ранку.

Швидкий план діагностики (перший/другий/третій)

Якщо ви запам’ятаєте лише одне, то запам’ятайте це: відокремлюйте диск від мережі від SMB-фіч. Не починайте зі зміни налаштувань. Почніть з доведення того, де знаходиться стеля.

Перший крок: класифікуйте робоче навантаження

• Одиночний великий файл? Очікуйте лінійної швидкості, якщо диски в порядку і SMB не виконує дорогих безпекових операцій.
• Багато дрібних файлів? Очікуйте повільніше. Потім запитайте: «Це значно повільніше, ніж минулого місяця?»
• Читання чи запис? Записи часто повільніші через синхронну поведінку, снапшоти, паритет RAID або відсутність SLOG (для ZFS).

Другий крок: доведіть сиру мережеву здатність (без SMB)

• Використовуйте iperf3 між клієнтом і NAS (або між NAS і тестовим хостом в тій самій VLAN).
• Якщо тут ви не близькі до очікуваної пропускної здатності, SMB вам не допоможе.

Третій крок: доведіть можливість зберігання NAS (без SMB)

• Виміряйте пропускну здатність диска й латентність на самому NAS (fio ідеально; базові інструменти теж працюють).
• Якщо NAS вже завантажений на 80–100% CPU, ваші SMB-налаштування — косметика.

Четвертий крок: перевірте діалект SMB і дорогі фічі

• Перевірте версію SMB, стан підписування, шифрування, multichannel, RSS.
• Шукайте антивірус, DLP, file screening або накладання квот, що додають накладні витрати.

П’ятий крок: зафіксуйте один чистий тест і одну «реальну» копію

• Один великий файл, згенерований на клієнті (щоб читання клієнтом не обмежувало).
• Одна представницька «проблемна» папка.
• Порівняйте поведінку. Якщо лише навантаження з дрібними файлами погане, налаштовуйте для метаданих/латентності, а не для пропускної здатності.

Факти та історія, що пояснюють сучасну дивність

Проблеми продуктивності SMB часто виглядають як таємниця, поки ви не згадаєте, звідки SMB походить і що протокол намагається гарантувати.

1. SMB виник у 1980-х (корені в IBM, пізніше прийнятий і розширений Microsoft). Багато «балакучої» поведінки — це історичний спадок.
2. SMB1 був розроблений для LAN з іншими припущеннями; його неефективність (і проблеми з безпекою) — чому сучасне середовище має поводитися з SMB1 як з «ні».
3. SMB2 (ера Vista/Server 2008) значно зменшив балакучість і покращив pipeline — це одна з причин, чому SMB2/3 може бути значно швидшим на лінках з високою RTT.
4. SMB3 ввів шифрування і multichannel (ера Windows 8/Server 2012). Чудові фічі, але вони можуть навантажувати CPU або виявити дивну поведінку NIC/драйверів.
5. Підпис SMB існував задовго до того, як «zero trust» став лозунгом; він захищає цілісність, але має відчутну вартість продуктивності — особливо на слабких CPU або коли відсутні апаратні оффлоади.
6. Копіювання через Explorer змінювало поведінку від релізу до релізу Windows (розміри буферів, повторні спроби, «дружній» UI). Robocopy часто більш передбачуваний для тестів.
7. Oplocks і leasing були введені, щоб зменшити кількість мережевих раунтріпів шляхом кешування — поки застосунок або сканер не скинуть кеш і не примусять постійні розриви.
8. Кредити SMB — це flow control; на широких каналах із високою RTT (або завантажених серверах) неправильна поведінка кредитів може обмежити кількість незавершених I/O.
9. Jumbo frames стали модними з 10GbE, але SMB не вимагає їх як магії; jumbo зменшують навантаження на CPU і кількість переривань, коли все налаштовано правильно скрізь по шляху.

Практичні завдання: команди, виводи та рішення (12+)

Це ті завдання, які я реально виконую, коли кажуть «SMB повільний». Кожне включає: команду, як виглядає «добре», і яке рішення приймати.

Завдання 1: Підтвердьте діалект SMB, шифрування, підпис (Windows клієнт)

cr0x@server:~$ powershell -NoProfile -Command "Get-SmbConnection | Select-Object ServerName,ShareName,Dialect,Encrypted,Signed,NumOpens | Format-Table -Auto"
ServerName ShareName Dialect Encrypted Signed NumOpens
--------- --------- ------- --------- ------ --------
nas01     data      3.1.1   False     True   12

Що це означає: Ви на SMB 3.1.1, шифрування вимкнене, підпис увімкнений. «Signed=True» може бути нав’язаним політикою.

Рішення: Якщо продуктивність низька і CPU високий, перевірте, чи підпис обов’язковий. Якщо політика вимагає підпису — припиніть сперечатися і оптимізуйте в іншому місці (RSS, multichannel, CPU, драйвери NIC).

Завдання 2: Виміряйте сиру пропускну здатність мережі за допомогою iperf3

cr0x@server:~$ iperf3 -c nas01 -P 4 -t 10
Connecting to host nas01, port 5201
[SUM]   0.00-10.00  sec  4.65 GBytes  3.99 Gbits/sec  0             sender
[SUM]   0.00-10.00  sec  4.64 GBytes  3.99 Gbits/sec                  receiver

Що це означає: Ваш мережевий шлях реально може близько 4 Гбіт/с з чотирма стрімами. Чудово.

Рішення: Якщо iperf3 низький, виправте швидкість/дуплекс NIC, кабелі, конфігурацію комутатора, VLAN, QoS або Wi‑Fi перш ніж торкатися SMB.

Завдання 3: Перевірте швидкість лінку та помилки NIC (Linux NAS)

cr0x@server:~$ sudo ethtool eno1
Settings for eno1:
	Speed: 10000Mb/s
	Duplex: Full
	Auto-negotiation: on
Link detected: yes

Що це означає: Лінк піднятий на 10GbE повний дуплекс. Це відправна точка.

Рішення: Якщо показує 1000Mb/s, коли ви очікуєте 10GbE — зупиніться. Знайдіть поганий кабель, неправильний SFP або конфіг порту комутатора.

Завдання 4: Перевірте лічильники інтерфейсу на предмет дропів/підказок про ретрансміти (Linux)

cr0x@server:~$ ip -s link show dev eno1
2: eno1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP mode DEFAULT group default qlen 1000
    RX:  bytes packets errors dropped  missed   mcast
    987654321  1234567      0      12       0    1234
    TX:  bytes packets errors dropped carrier collsns
    123456789  2345678      0       8       0       0

Що це означає: Ненульові дропи. Декілька можуть бути шумом; стійке зростання під час тестів — червоний прапор.

Рішення: Якщо дропи ростуть під час копіювання, ви маєте справу з заторами, проблемами буферів або проблемами оффлоаду/драйвера. Виправте це перед налаштуванням Samba.

Завдання 5: Підтвердьте MTU скрізь шлях (Linux)

cr0x@server:~$ ping -M do -s 8972 nas01 -c 2
PING nas01 (10.20.0.10) 8972(9000) bytes of data.
8972 bytes from 10.20.0.10: icmp_seq=1 ttl=64 time=0.321 ms
8972 bytes from 10.20.0.10: icmp_seq=2 ttl=64 time=0.299 ms

--- nas01 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1001ms

Що це означає: Скоріш за все jumbo frames (MTU 9000) працюють на цьому шляху.

Рішення: Якщо це не вдається, не вмикайте jumbo frames «бо швидше». Часткові jumbo гірші за їхню відсутність; вони викликають фрагментацію або blackhole залежно від обладнання.

Завдання 6: Перевірте стан SMB multichannel (Windows)

cr0x@server:~$ powershell -NoProfile -Command "Get-SmbMultichannelConnection | Format-Table -Auto"
Server Name Client IP   Server IP   Client Interface Index Server Interface Index RSS Capable RDMA Capable
----------- ---------   ---------   ---------------------- --------------------- ----------- ------------
nas01       10.20.0.21  10.20.0.10  14                     12                    True        False

Що це означає: Multichannel присутній і RSS підтримується. Якби було кілька інтерфейсів, ви б бачили кілька рядків.

Рішення: Якщо multichannel очікується, але відсутній — перевірте підтримку сервера SMB (версія/config Samba), налаштування RSS NIC або чи є тільки один життєздатний шлях.

Завдання 7: Перевірте RSS / оффлоад на клієнті (Windows)

cr0x@server:~$ powershell -NoProfile -Command "Get-NetAdapterRss | Select-Object Name,Enabled,NumberOfReceiveQueues,Profile | Format-Table -Auto"
Name        Enabled NumberOfReceiveQueues Profile
----        ------- --------------------- -------
Ethernet0   True    8                     ClosestProcessor

Що це означає: RSS увімкнено. Добре: SMB може розподілити обробку.

Рішення: Якщо RSS відключено на 10GbE клієнті/сервері, ви часто загрузнете на одному ядрі CPU. Виправте RSS перед тим, як лізти в Samba.

Завдання 8: Переконайтеся, що CPU сервера не насичений (Linux NAS)

cr0x@server:~$ mpstat -P ALL 1 5
Linux 6.6.0 (nas01)  02/05/2026  _x86_64_  (16 CPU)

03:11:01 PM  CPU   %usr %nice %sys %iowait %irq %soft %idle
03:11:02 PM  all   22.10  0.00  8.33   1.50 0.00  2.10 66.0
03:11:02 PM    7   91.00  0.00  6.00   0.00 0.00  0.00  3.0

Що це означає: Одне ядро завантажене ~91%, тоді як загальний CPU у нормі. Класичний знак проблеми з афінітетом/перериваннями/RSS або однонитковою роботою (крипто, один черга).

Рішення: Якщо одне ядро зафіксоване під час SMB-копіювання, дослідіть RSS, переривання NIC і чи підпис/шифрування не навантажує одне ядро.

Завдання 9: Спостерігайте латентність диска під час копіювання (Linux NAS)

cr0x@server:~$ iostat -x 1 5
avg-cpu:  %user %nice %system %iowait  %idle
          18.12  0.00   6.44    4.10  71.34

Device            r/s   w/s  rkB/s  wkB/s  await  svctm  %util
nvme0n1          2.0  450.0   64.0 51200.0  2.10  0.20   9.5
md0              0.0  820.0    0.0 52000.0 18.50  0.00  98.0

Що це означає: Бекінг-рейд (md0) близький до 100% завантаження з ~18 ms await. Це ваш ліміт для записів.

Рішення: Перестаньте «налаштовувати SMB» і виправте зберігання: write cache, рівень RAID, ZFS recordsize, SLOG, кількість шпинделів або перемістіть навантаження на SSD.

Завдання 10: Підтвердьте, що Samba дійсно використовує aio і розумні socket-опції (Linux NAS)

cr0x@server:~$ testparm -s | egrep -i "aio|socket|smb2 leases|server multi channel|server signing|smb encrypt"
	aio read size = 1
	aio write size = 1
	server multi channel support = yes
	server signing = mandatory
	smb encrypt = disabled
	socket options =
	smb2 leases = yes

Що це означає: AIO увімкнено (поріг 1 означає фактично завжди), multichannel підтримується, підпис обов’язковий.

Рішення: Якщо підпис обов’язковий і CPU — вузьке місце, розгляньте «signing desired» (якщо політика дозволяє) або оновіть CPU / увімкніть апаратне прискорення крипто. Якщо multichannel вимкнено, ввімкніть його тільки після перевірки стабільності NIC і комутатора.

Завдання 11: Перевірте, чи SMB не відкотилося до SMB1 або NT1 десь (логи Linux)

cr0x@server:~$ sudo journalctl -u smbd --since "1 hour ago" | egrep -i "SMB1|NT1|deprecated|protocol"
Feb 05 14:22:18 nas01 smbd[2143]: protocol negotiation failed: client requested NT1

Що це означає: Деякий клієнт намагається використовувати SMB1 (NT1). Це може викликати жахливу продуктивність і відкривати вразливості.

Рішення: Знайдіть клієнта, вимкніть SMB1 і застосуйте мінімальний протокол SMB2_02 або вищий.

Завдання 12: Тест контрольованого запису великого файлу з Windows клієнта (robocopy)

cr0x@server:~$ powershell -NoProfile -Command "robocopy C:\temp \\nas01\data\perf-test bigfile.bin /np /r:0 /w:0 /mt:8"
-------------------------------------------------------------------------------
   ROBOCOPY     ::     Robust File Copy for Windows
-------------------------------------------------------------------------------

  Source : C:\temp\
    Dest : \\nas01\data\perf-test\

    Files : bigfile.bin

  Options : *.* /MT:8 /R:0 /W:0 /NP

------------------------------------------------------------------------------
               Total    Copied   Skipped  Mismatch    FAILED    Extras
    Dirs :         1         0         1         0         0         0
   Files :         1         1         0         0         0         0
   Bytes : 50.000 g  50.000 g         0         0         0         0
   Times :   0:02:10   0:02:10                       0:00:00   0:00:00
   Speed :           410.123 MegaBytes/min
   Speed :            6.835 MegaBytes/sec

Що це означає: 6.8 MB/s до NAS — катастрофічно мало для одного потоку. Тепер ви знаєте, що це не «дрібні файли». Щось фундаментально обмежує записи.

Рішення: Корелюйте це з iostat (зберігання), iperf3 (мережа) і CPU. Не ганяйтесь за oplocks; ганяйтесь за лімітером.

Завдання 13: Підтвердьте, що Windows не пише з патологічною буферною поведінкою (лічильники продуктивності)

cr0x@server:~$ powershell -NoProfile -Command "Get-Counter '\SMB Client Shares(*)\Avg. Write Queue Length' -SampleInterval 1 -MaxSamples 5 | Select-Object -ExpandProperty CounterSamples | Select-Object Path,CookedValue"
Path                                                     CookedValue
\\SMB Client Shares(\\nas01\data)\Avg. Write Queue Length 15

Що це означає: Велика черга записів SMB на клієнті свідчить, що клієнт чекає підтверджень від сервера (сервер повільний або контролюється flow).

Рішення: Якщо довжина черги залишається високою за умови, що мережа не завантажена, дослідіть латентність диска сервера, кредити SMB або CPU-навантаження від підпису/шифрування.

Завдання 14: Перевірте TCP ретрансміти на Linux (сервер або клієнт)

cr0x@server:~$ netstat -s | egrep -i "retransm|segments retransm"
    184 segments retransmitted

Що це означає: Є ретрансміти. Абсолютне число не головне; важлива тенденція під час тестів.

Рішення: Якщо ретрансміти швидко ростуть під час копій, виправте проблеми рівня 1/2/3, оффлоади або затори. Налаштування SMB не компенсує втрати пакетів.

Завдання 15: Підтвердіть опції шару Samba для шару, що впливають на кешування та стійкість

cr0x@server:~$ testparm -s --section=data | egrep -i "strict sync|sync always|durable handles|kernel oplocks|oplocks|vfs objects"
	strict sync = yes
	sync always = yes
	kernel oplocks = yes
	oplocks = yes
	durable handles = yes
	vfs objects = acl_xattr

Що це означає: sync always = yes примушує синхронні записи. Це вбивця продуктивності, якщо ви не дійсно цього не потребуєте.

Рішення: Якщо це загального призначення шар, вимкніть sync always. Якщо це для бази даних, яка вимагає синхронних семантик, то вам потрібне належне зберігання (SLOG, BBWC тощо), а не надії на конфігурацію.

Налаштування SMB, які справді мають значення

Більшість «SMB-налаштувань» в інтернеті або застаріли, або плацебо, або небезпечні в продакшені. Ось ті, що регулярно змінюють показники — бо вони відповідають реальним вузьким місцям.

1) Спочатку виправте нудні речі: швидкість/дуплекс, кабелі та симетрію шляху

Якщо ваш NAS обмінюється 1GbE з одного боку і 10GbE з іншого, SMB Ваше віддано доставлятиме продуктивність 1GbE. Те саме якщо у вас LACP, який хешує весь трафік на один фізичний лінк через один TCP-сеанс. Вам не потрібен гайд з налаштувань; потрібно припинити гадати.

2) SMB Multichannel: реальний виграш, але лише коли NIC поводяться

SMB Multichannel може використовувати кілька TCP-з’єднань через NIC (або через кілька черг на одному NIC із RSS). Це допомагає і по пропускній здатності, і по стійкості. Але додає складності: більше потоків, більше шансів натрапити на багатий драйвер і більша чутливість до асиметрії.

• Робіть це, коли у вас є 10/25/40GbE і сучасні Windows-клієнти, і ви можете верифікувати стабільну поведінку multi-queue.
• Уникайте «пів-multichannel», коли сервер це підтримує, але клієнт має RSS відключене (або навпаки). Так ви зафіксуєте одне ядро і дивуватиметесь, чому лінк простояний.

3) RSS і розподіл переривань: мовчазний обмежувач пропускної здатності

Якщо одне ядро CPU завантажене під час передач SMB, ви застопоритесь на підозрілої швидкості (часто кілька Гбіт/с або менше), поки решта системи відпочиває. RSS розподіляє обробку прийому. Правильна модерація переривань і кількість черг також важливі.

Що робити:

• Увімкніть RSS на Windows NIC; перевірте кількість receive-черг.
• На Linux переконайтеся, що multiqueue увімкнено, і переривання розподілені розумно.
• Оновіть прошивки/драйвери NIC. Так, це нудно. Так, це важливо.

4) Підпис і шифрування: знайте, за що платите

Підпис SMB забезпечує цілісність: він запобігає підміні. Шифрування SMB захищає конфіденційність. Обидва — хороші контролі безпеки. Обидва коштують CPU і можуть зменшувати пропускну здатність.

Правила, які я застосовую в продакшені:

• Якщо ви в довіреній LAN і політика безпеки дозволяє: не вимагайте підпису для кожного шару. Встановіть «desired», а не «mandatory».
• Якщо потрібно шифрувати: переконайтесь, що CPU NAS має AES‑NI (або еквівалент) і що крипто не прив’язане до одного ядра.
• Не шифруйте двічі (SMB шифрування плюс VPN шифрування), якщо ви не заклали CPU для цього.

Парафраз від одного важкового в надійності: парафраз: «Надія — не стратегія» — приписують Gene Kranz, часто цитують у інженерних та операційних дискусіях.

5) Не примушуйте синхронні записи, якщо ви цього не маєте на увазі

Налаштування як sync always (Samba) або поведінка зберігання «завжди синхронно» можуть перетворити NAS на машину високої латентності запису. Це може бути правильним для деяких транзакційних навантажень. Для загальних користувацьких шарів це зазвичай самошкодження.

Якщо ваша організація каже «нам потрібні нульові втрати даних при відключенні живлення», купіть апарат, що це підтримує (батарейний кеш, правильний журнал або дизайн ZFS intent log) і тестуйте. Не навішуйте «sync always» на масив із побутових SSD і не називайте це enterprise.

6) Налаштовуйте під навантаження: великі файли vs дрібні файли

Для великих послідовних трансферів зосередьтеся на:

• Пропускній спроможності, RSS, multichannel, запасі CPU і уникненні дорогих безпекових фіч, де політика дозволяє.

Для мільйонів дрібних файлів зосередьтеся на:

• Продуктивності метаданих на NAS (SSD для метаданих, достатньо RAM, швидкі операції з директоріями).
• Виключеннях антивірусу на клієнті й сервері (виважено).
• Зменшенні зайвих перевірок атрибутів/ACL там, де це можливо.

7) Samba AIO і sendfile: хороші налаштування за замовчуванням, але перевіряйте

Асиметричний I/O Samba і нуль-копійний sendfile можуть допомогти. На сучасних ядрах Samba загалом добре працює. Але ви повинні переконатися, що NAS не обмежений десь ще.

• AIO допомагає, коли є вигода від паралельного I/O і підлягаюча файлова система добре його підтримує.
• sendfile може зменшити навантаження на CPU для читань. Для повільних записів він не допоможе.

Будьте підозрілі до старих «socket options», витягнутих з 2009 року. Якщо хтось радить TCP_NODELAY і величезні буфери як універсальне рішення — ви читаєте фольклор.

8) Вимкніть SMB1. До сих пір. Завжди.

Якщо старий пристрій примушує SMB1, ізолюйте його в окремій VLAN/share, обмежте доступ і плануйте його виведення з експлуатації. SMB1 — це не «сумісність з спадщиною»; це «сумісність з атаками». Він також повільний, балакучий і неприємний при латентності.

Жарт №2: Якщо ви досі працюєте на SMB1, ви не «підтримуєте спадщину»; ви керуєте музейним експонатом, який час від часу отримує рансомваре.

Три корпоративні міні-історії з польових робіт

Міні-історія 1: Інцидент через неправильне припущення

Середня компанія розгорнула новий NAS, щоб замінити старий Windows file server. Покупку виправдовували «сирою пропускною здатністю» — багато дисків, 10GbE uplink-и і дашборд, який гордо показував низький CPU в простої. Міграція у вихідні пройшла нормально. Понеділок — ні.

Користувачі скаржилися, що відкриття проектних папок займає вічность. Копії «зависали» випадково. Хелпдеск ескалював як «мережева проблема», бо ping був нормальний і веб‑додатки швидкі. Тим часом команда зберігання наполягала, що NAS «майже нічого не робить», бо графіки пропускної здатності не були завантажені.

Неправильним припущенням було те, що низька пропускна здатність означає, що система не зайнята. Насправді навантаження змінилося з «великих CAD-файлів» на «тисячі дрібних артефактів збірки» за роки. Explorer робив читання атрибутів, перевірки ACL і операції, пов’язані з мініатюрами. На NAS підлеглий RAID добре справлявся з послідовною пропускною здатністю, але мав посередню латентність під метаданим-чурном, а share мав strict sync увімкнений «для безпеки».

Коли хтось побудував графік дискової латентності (await), а не лише MB/s, усе стало зрозуміло. Масив витрачав час на маленькі записи і флеші. Виправлення не було магічним SMB-флагом. Вони перемістили метаданеві шарі на SSD-backed storage, прибрали sync always з загальних шарів і додали вузьконаправлене виключення антивірусу для директорій збірки. Швидкість копіювання підскочила, і «час відкриття папки» перестав породжувати тікети.

Міні-історія 2: Оптимізація, що зіграла проти

Інша організація мала повільні записи SMB до Samba‑NAS. Хтось прочитав блог з налаштувань і вирішив, що jumbo frames «розблокують продуктивність». Вони встановили MTU 9000 на NAS, core switch і кілька серверів. Десктопи та деякі access switch-и лишилися на 1500, бо «вони ймовірно залагоджують». Вони не залагоджувалися.

Протягом дня продуктивність була дивною: іноді — шалена, іноді — повільна, іноді — зависала на секунди. Захоплення пакетів показували ретрансміти і шаблони фрагментації, що не мали сенсу для LAN. Хелпдеск бачив випадкові «мережевий диск відключено» повідомлення. Команда зберігання не бачила помилок на дисках. Усі звинувачували одне одного — це круг життя.

Коренем проблеми була часткова конфігурація jumbo frames і непослідовний path MTU. Деякі потоки випадково залишалися в чистому MTU-домені; інші проходили через обладнання, що не підтримувало jumbo, спричиняючи дропи і повторні передачі. SMB, будучи надійним протоколом над TCP, старанно перезапускав — і пропускна здатність впала.

Зрештою вирішення було жорстко простим: повернути MTU 1500 всюди, а потім поступово вводити jumbo лише після аудиту кожного хопа (включно з віртуальними vSwitch і інтерфейсами фаєрвола). Продуктивність стала стабільною спочатку, а потім швидкою. «Оптимізація» провалилася не тому, що jumbo погані, а тому що мережу трактували як камінь настрою.

Міні-історія 3: Нудна, але правильна практика, що врятувала день

Велике підприємство мало повторювані скарги: «SMB повільний» після кожного квартального циклу патчів. Команда зберігання втомилася від реактивного гасіння пожеж, тому ввели нудну, але повторювану практику: відтворюваний SMB-спринг тест продуктивності, що запускався щотижня і зберігався разом із системними метриками.

Базовий набір включав три тести: iperf3 пропускна здатність, запис великого файлу robocopy і robocopy для дрібних метаданево-важких файлів. Вони записували версії драйверів NIC, діалект SMB, статус підпису/шифрування і CPU/disk latency NAS під час кожного запуску.

Одного тижня тест великого файлу впав удвічі, а iperf3 залишився нормальним. Латентність диска була в нормі. CPU показував пікове завантаження одного ядра. Тому що в них були історичні бази, вони швидко зіставили регресію з новим драйвером NIC на підмножині Windows-клієнтів, який вимкнув RSS через «суміснісну» опцію. Ніхто б не помітив цього в нормальному моніторингу, бо середній CPU був нормальний і графіки мережі виглядали нормально.

Вони відкотили драйвер, знову увімкнули RSS, і продуктивність повернулась. Перемога була не в якомусь хитрому налаштуванні. Перемога була в наявності бази і в підході до продуктивності SMB як до SLO, а не як до чуток.

Поширені помилки: симптом → корінна причина → вирішення

1) «Мережа швидка, але копії SMB повільні»

Симптом: iperf3 виглядає добре, але копії файлів впираються в низьку швидкість.

Корінна причина: Накладні витрати CPU через підпис/шифрування, або латентність диска на NAS, або одноядерне вузьке місце через RSS/оффлоади.

Вирішення: Перевірте стан підпису/шифрування SMB, виміряйте завантаження CPU по ядрах, підтвердьте RSS/multichannel, потім виміряйте disk await під час копіювання.

2) «Один великий файл швидко, але папки з багатьма дрібними файлами жахливо повільні»

Симптом: ISO копії літають; дереви з файлами повзуть.

Корінна причина: Накладні витрати на метадані (створення/закриття/перевірки ACL), антивірусне сканування, снапшоти або повільні операції директорій.

Вирішення: Використовуйте robocopy з і без багатопоточності; перегляньте виключення антивірусу; розмістіть метаданево-важкі шарі на SSD; зменшіть патологічні sync-настройки.

3) «Вчора було швидко; сьогодні повільно»

Симптом: Раптова регресія без змін топології (ніби).

Корінна причина: Оновлення драйвера/прошивки, зміна політики SMB (підпис став обов’язковим), зміни path MTU або новий inline security продукт.

Вирішення: Порівняйте властивості SMB-з’єднання і налаштування NIC; перевірте change logs; верифікуйте MTU скрізь; підтвердьте відсутність нових фільтруючих драйверів або оновлень NAS.

4) «Копія SMB зависає кожні кілька секунд»

Симптом: Пульсуюча пропускна здатність; паузи в індикаторі прогресу.

Корінна причина: Bufferbloat/затори, втрата пакетів і ретрансміти або поведінка збереження (sync‑флеші, шторми flush).

Вирішення: Перевірте дропи/ретрансміти інтерфейсу; перевірте черги/ QoS комутатора; виміряйте латентність диска і налаштування кешу NAS; приберіть примусовий sync, де він не потрібен.

5) «Лише деякі клієнти повільні»

Симптом: Один відділ скаржиться; інші — ні.

Корінна причина: Різні драйвери NIC, Wi‑Fi проти дротового підключення, різні GPO безпеки (підпис), або різні шляхи (інший стек комутаторів).

Вирішення: Порівняйте виводи Get-SmbConnection; запустіть iperf3 з повільних і швидких клієнтів; перевірте швидкість лінку, RSS і лічильники помилок.

6) «Включення jumbo frames зробило гірше»

Симптом: Періодичні зависання, ретрансміти, відключення.

Корінна причина: Часткова jumbo конфігурація або проміжний пристрій, що не пропускає jumbo.

Вирішення: Поверніть MTU 1500; доведіть jumbo з DF-пінгами через кожен хоп; потім або ввімкніть послідовно, або забийте на це.

7) «Ми ввімкнули шифрування SMB і тепер усе повільно»

Симптом: Пропускна здатність падає, CPU росте.

Корінна причина: CPU‑bound крипто, відсутність апаратного прискорення або однонитковий шлях шифрування на платформі.

Вирішення: Переконайтеся, що AES-прискорення доступне і використовується; масштабujte CPU; шифруйте лише чутливі шарі; підтвердьте multichannel/RSS для розподілу навантаження.

8) «Ми додали LACP, отже має бути швидше»

Симптом: Все ще обмежено швидкістю одного лінку.

Корінна причина: Один TCP-потік хешується на один фізичний учасник; SMB без multichannel не розбиває один файл між лінками.

Вирішення: Використовуйте SMB multichannel для паралельності; або тестуйте кілька одночасних потоків; налаштуйте політику хешування; не обіцяйте, що LACP збільшить швидкість одного потоку.

Контрольні списки / покроковий план

Покроково: стабілізуйте спочатку, потім прискорюйте

1. Виберіть два тести: один великий файл (10–50 GB) і одну представницьку папку «дрібні файли».
2. Запустіть iperf3, щоб валідувати сирі можливості мережі і поведінку ретрансмітів.
3. Перевірте швидкість лінку на клієнті і NAS, і перевірте лічильники на дропи.
4. Підтвердьте діалект SMB і чи увімкнено/вимкнено підпис/шифрування.
5. Виміряйте CPU NAS по ядрах під час копії; слідкуйте за зафіксованим ядром.
6. Виміряйте латентність диска NAS (await/%util) під час копії.
7. Якщо мережа лімітує: виправте консистентність MTU, затори на комутаторі, кабелі, драйвери NIC.
8. Якщо CPU лімітує: увімкніть RSS, валідуйте multichannel, розгляньте зменшення вимог підпису/шифрування там, де політика дозволяє, або оновіть CPU.
9. Якщо диск лімітує: перемістіть робоче навантаження на швидше зберігання, додайте SSD, виправте RAID/ZFS-розклад, приберіть примусовий sync для загальних шарів.
10. Лише тепер: налаштовуйте Samba/SMB опції, що відповідають доведеному вузькому місцю.
11. Перетестуйте тим самим набором даних і методом. Зберігайте результати.
12. Операціоналізуйте: створіть щотижневий baseline-джоб, щоб ловити регресії раніше за користувачів.

Короткий чеклист «робити / не робити»

• Робіть — розглядайте продуктивність SMB як систему: клієнт + сервер + мережа + зберігання.
• Робіть — вимірюйте латентність, а не лише пропускну здатність.
• Робіть — тримайте SMB1 відключеним і вимагайте SMB2+.
• Не робіть — не вмикайте jumbo frames, якщо не можете довести end-to-end підтримку MTU.
• Не робіть — не примушуйте синхронні записи на загальні шари.
• Не робіть — не вставляйте старі «socket options» Samba і не чекайте чудес.
• Не робіть — не плутайте агреговану пропускну здатність LACP з пропускною здатністю одного потоку.

Питання та відповіді

1) Чому копіювання через Windows Explorer відчувається повільнішим за robocopy?

Explorer оптимізований для користувацького досвіду: звіти прогресу, прев’ю і іноді інша буферна поведінка. Robocopy більш детермінований для тестів і може паралелізуватися з /mt.

2) Чи слід вмикати SMB Multichannel на Samba?

Якщо ваші клієнти — сучасні Windows, а стек NIC/драйверів стабільний, так — multichannel може збільшити пропускну здатність і зменшити одноядерні вузькі місця. Валідуйте через Get-SmbMultichannelConnection і спостерігайте за CPU/перериваннями.

3) Чи допомагають jumbo frames продуктивності SMB?

Іноді. Вони зменшують накладні витрати на пакет і можуть покращити ефективність CPU на 10GbE+. Але лише якщо кожний хоп підтримує MTU. Часткові jumbo — це пастка продуктивності.

4) Чому дрібні файли копіюються повільно навіть на SSD NAS?

Копіювання дрібних файлів визначається операціями метаданих, перевірками ACL та відкриттями/закриттями — а не масовою пропускною здатністю. Антивірус і снапшоти можуть посилити проблему. Вимірюйте латентність операцій з директоріями і CPU сервера, а не лише MB/s.

5) Чи вартий підпис SMB втрат продуктивності?

Підпис захищає від підміни і деяких класів атак. Чи вартий — це рішення безпеки. Операційно: якщо підпис потрібен — плануйте CPU і переконайтеся, що RSS/multichannel налаштовані правильно, щоб не зафіксувати одне ядро.

6) Чи слід вимкнути шифрування SMB, щоб прискоритись?

Тільки якщо політика дозволяє і мережа довірена. Краще спочатку переконатися, що доступне апаратне крипто-прискорення, і шифрувати лише чутливі шарі, де це доцільно.

7) Чому продуктивність SMB обмежується приблизно 110 MB/s навіть на «10GbE» NAS?

110 MB/s підозріло близько до лінійної швидкості 1GbE. Перевірте домовлену швидкість лінку, погані кабелі, 1GbE комутатор на шляху або док-кейс клієнта, що має лише гігабіт.

8) Який найпростіший спосіб дізнатися, чи диски NAS — вузьке місце?

Слідкуйте за iostat -x під час копіювання. Якщо %util близький до 100% і await стрибнув — диски вас обмежують. Якщо диски в нормі, але CPU або мережеві лічильники пішли вгору — дивіться туди далі.

9) Чи може LACP (bonding) подвоїти швидкість SMB-копії?

Не для одного TCP-потоку в більшості випадків. LACP збільшує агреговану пропускну здатність для багатьох потоків. SMB Multichannel — фіча, що може реально використати кілька з’єднань для сесії.

10) Які налаштування Samba найчастіше «ненавмисно шкідливі»?

sync always і агресивні «durability» налаштування, застосовані до невідповідних шарів. Також — обов’язковий підпис/шифрування без планування CPU. І випадкові socket options з старих постів оптимізації.

Висновок: практичні наступні кроки

Якщо копії SMB на ваш NAS повільні, вам не потрібен шаман. Вам потрібна коротка петля вимірювань і дисципліна змінювати по одній речі за раз.

1. Запустіть iperf3 і валідуйте швидкість лінку та помилки. Доведіть мережу.
2. Запустіть тест запису великого файлу robocopy і слідкуйте за CPU NAS по ядрах та латентністю диска. Доведіть, чи ви CPU- чи disk-limited.
3. Перевірте SMB-фічі: діалект, підпис, шифрування, multichannel, RSS. Визначте дорогі опції, за які ви платите.
4. Виправте корінне вузьке місце, а не симптом: проблеми латентності зберігання вимагають виправлень зберігання; втрата пакетів — мережевих виправлень; зафіксовані ядра — RSS/драйвери.
5. Встановіть базу, щоб ви помічали регресії після патчів, а не коли асистентка CFO намагається відкрити «Q4 Budget FINAL v7.xlsx».

Зробіть це, і «SMB повільний» перетвориться з розмитої скарги на вирішену проблему з доказами.