Продуктивність ZFS по 10GbE: як довести, що мережа — вузьке місце

January 31, 2026 • February 3, 2026 • Читання: 7 хв • Views: 10

Було корисно?

Ваш сервер на ZFS чудово бенчмаркується локально, а потім повзає, коли клієнт підключається через 10GbE. У всіх є своя теорія. Стороні зберігання звинувачують комутатор. Мережа звинувачує ZFS. Команда застосунку каже «латентність». Тим часом ви дивитесь на діалог копіювання, який здається, ніби кожен пакет малюють вручну.

Ось як припинити гадати. Ви побудуєте базову лінію, ізолюєте шари і залишитесь з доказом: мережа або є вашою межею, або вона лише приносить погані новини звідкись ще.

Ментальна модель, яка переживає наради

Щоб довести вузьке місце, потрібно відділити стелі пропускної здатності від підсилення латентності та сериалізації.

1) 10GbE має жорстку стелю, але навантаження її переслідують по-своєму

На папері 10GbE — це 10 гігабіт на секунду. На практиці кращий TCP payload throughput зазвичай близько 9.4–9.8 Gbit/s, залежно від фреймування, offloads та CPU. Це приблизно 1.1–1.2 GB/s в термінах копіювання файлів, якщо все вирівняно і стрімінг йде стабільно.

Але навантаження ZFS не завжди стрімінгові. Дрібні I/O, метадані, синхронні записи або «балакучий» протокол можуть «втрачати» пропускну здатність на оверхед і «витрачати» час на кругові поїздки. 10GbE може здаватися повільним, коли насправді швидкий, але змушений працювати у режимі «стоп-і-чекати» через щось вище по стеку.

2) ZFS може бути швидшим за вашу мережу, і це пастка

Сучасний пул ZFS з достатньою кількістю дисків або NVMe може випередити 10GbE на послідовних читаннях. Чудово. Це означає, що мережева лінія стає обмежувачем для великих передач, і ви повинні бачити чисту плато: диск не завантажений, CPU не зашкалює, а NIC майже на лінійному режимі.

Якщо ви не бачите чистої плато, ви не «обмежені мережею». Ви «обмежені чимось іншим», і мережа лише бере участь.

3) Доведення мережевого вузького місця вимагає двох незалежних вимірів

Ви намагаєтесь відповісти на конкретне питання: Чи є мережа найвужчою точкою в цьому скін-ту-скін шляху?

Для доказу вам потрібні:

Мережевий тест без дисків і файлових систем, який наближається до лінійної швидкості.
Тест збереження локально на сервері, який перевищує те, що ви бачите по мережі.
І поєднаний тест (NFS/SMB/iSCSI), який співпадає з мережевою стелею.

Якщо будь-який з них не сходиться, у вас немає чистого мережевого вузького місця. У вас багаторівнева проблема, що гірше, але й більш виправна.

Операційне правило, яке варто приклеїти до лоба: Не налаштовуйте ZFS для мережевої проблеми і не налаштовуйте мережу для проблеми ZFS, поки не проведено ізоляційні тести.

Цікаві факти та коротка історія (щоб ви припинили повторювати міфи)

10GbE спочатку не створювали для дешевого крученного дроту. Ранні розгортання були здебільшого на оптиці; 10GBASE-T з’явився пізніше і споживав багато енергії в порівнянні з SFP+ optics/DAC.
Jumbo frames існували до масової популярності 10GbE. Їх використовували для зниження навантаження на CPU на завантажених лінках задовго до того, як кожен комутатор мав «можливо підтримку».
ZFS створювали з цілісністю даних end-to-end як ключовою функцією. Контрольні суми та copy-on-write — це не «фічі», це сенс, і вони мають вплив на продуктивність.
NFS мав кілька еволюцій. v3 — безстанний і поширений в пристроях; v4 додає стан, блокування і інші режими відмов, які проявляються як «проблеми продуктивності».
Продуктивність SMB кардинально змінилася з мульти-каналами та сучасними стек-технологіями. Стара фольклорна настройка SMB досі копіюється в середовища, які не відповідають їй.
TCP window scaling зробив можливими високопропускні лінки з великою латентністю. Без нього ваш «10GbE» поводився б як ввічлива порада.
Interrupt moderation і offloads — це компроміс. Вони можуть зменшити навантаження на CPU на пакет, але також можуть збільшити латентність або приховати баги драйвера.
recordsize в ZFS не те саме, що «розмір блоку на диску», але він сильно впливає на патерн I/O і на те, наскільки ефективно мережеві протоколи можуть стрімити дані.
Буфери комутаторів не безмежні, і мікробурсти можуть скидати пакети навіть коли середнє завантаження виглядає прийнятним.

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

Перший: доведіть, що мережа може робити 10GbE між саме цими двома хостами

Запустіть iperf3 в обох напрямках з кількома потоками.
Перевірте погоджену швидкість NIC, PCIe width, драйвер і помилки.
Шукайте дропи/ретрансмиси. Якщо вони є — зупиніться і виправте це до того, як торкатися ZFS.

Другий: доведіть, що сервер ZFS може читати/писати швидше локально, ніж бачить клієнт

Використовуйте fio локально проти dataset (і опційно zvol) з direct I/O, щоб уникнути ілюзій «це просто ARC».
Використовуйте zpool iostat -v щоб підтвердити, що диски роблять те, що ви очікуєте.
Слідкуйте за використанням CPU і затримками по пристроях; якщо пул не може годувати 1+ GB/s, мережа не є основним обмежувачем.

Третій: протестуйте реальний протокол (NFS/SMB/iSCSI) і корелюйте з обох сторін

Запустіть контрольоване копіювання файлу або fio через NFS/SMB.
Одночасно збирайте: статистику NIC, статистику ZFS і клієнтські retransmits.
Якщо протокольна пропускна здатність збігається з iperf3-стелею і серверні диски недовантажені — ви мережево обмежені (заплановано, а не випадково).

Якщо ви зробите лише одну річ: запустіть iperf3 і зафіксуйте retransmits. Якщо мережа хвора — вона швидко зізнається.

Базові орієнтири для 10GbE та як виглядає «добре»

Орієнтири змінюються залежно від ОС, NIC і CPU. Але для одного 10GbE-лінку на сучасному Linux:

iperf3 single stream: часто 6–9 Gbit/s залежно від TCP tuning і латентності.
iperf3 4–8 паралельних потоків: має наближатися до 9.4–9.8 Gbit/s в чистій LAN.
TCP retransmits: повинні бути близькими до нуля в стабільній LAN. Декілька під час розігріву можливі; постійні retransmits означають дропи, проблемні оптики/кабелі, проблеми з узгодженням duplex/speed або тиск на буфери.
NIC errors/drops: повинні бути нульовими або надзвичайно низькими. «Трохи» — це не план.
Server local sequential read (fio): бажано > 1.2 GB/s, якщо ви хочете наситити 10GbE з запасом; інакше ваш пул є обмежувачем.

Також: не ігноруйте клієнта. Багато інцидентів «NAS повільний» насправді — «у клієнта драйвер NIC з плійстоцену».

Жарт #1: 10GbE-лінк, що максимум дає 2 Gbit/s, все ще «10GbE» так само, як спортивна машина з пробитою шиною все ще «спортивна машина».

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

Це реальні завдання, які ви можете виконати сьогодні. Кожне включає команду, прикладний вивід і яке рішення з нього випливає. Запускайте їх на сервері ZFS та на клієнті, коли це доречно.

Завдання 1: Перевірити швидкість лінку, duplex та погоджений стан

cr0x@server:~$ sudo ethtool enp65s0
Settings for enp65s0:
        Supported ports: [ FIBRE ]
        Supported link modes:   10000baseT/Full
        Supported pause frame use: Symmetric
        Supports auto-negotiation: No
        Advertised link modes:  10000baseT/Full
        Advertised pause frame use: Symmetric
        Advertised auto-negotiation: No
        Speed: 10000Mb/s
        Duplex: Full
        Port: FIBRE
        PHYAD: 0
        Transceiver: internal
        Auto-negotiation: off
        Link detected: yes

Що це означає: Якщо ви не бачите 10000Mb/s Full з Link detected, зупиніться. Ви не зможете перекрутити поганий лінк налаштуваннями.

Рішення: Якщо швидкість не 10Gb, виправте кабелі/оптику/налаштування комутатора спочатку. Якщо є невідповідність auto-negotiation (поширено для 10GBASE-T), виправте її.

Завдання 2: Перевірити PCIe link width/speed (так, це має значення)

cr0x@server:~$ sudo lspci -s 65:00.0 -vv | egrep -i "LnkCap|LnkSta"
LnkCap: Port #0, Speed 8GT/s, Width x8, ASPM L0s, Exit Latency L0s <512ns, L1 <64us
LnkSta: Speed 8GT/s, Width x8

Що це означає: NIC у PCIe-слоті, що працює x1 або на низькій швидкості, може обмежувати пропускну здатність або спричиняти стрибки латентності під навантаженням.

Рішення: Якщо width/speed нижче очікуваного, перемістіть NIC, змініть налаштування BIOS або перестаньте ділити лінії з HBA для збереження смуги, якщо материнська плата скнобить.

Завдання 3: Перевірити лічильники помилок інтерфейсу і дропи

cr0x@server:~$ ip -s link show dev enp65s0
2: enp65s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP mode DEFAULT group default qlen 1000
    link/ether 3c:fd:fe:aa:bb:cc brd ff:ff:ff:ff:ff:ff
    RX:  bytes  packets  errors  dropped  missed  mcast
    9876543210  1234567  0       0        0       1234
    TX:  bytes  packets  errors  dropped  carrier collsns
    8765432109  2345678  0       0        0       0

Що це означає: Будь-які ненульові errors/dropped під час тесту — підозрілі. Dropped також може бути переповненням host queue.

Рішення: Якщо дропи ростуть під навантаженням, досліджуйте ring sizes, драйвер, IRQ affinity і затори в комутаторі. Не чіпайте ZFS поки що.

Завдання 4: Шукати TCP retransmits на Linux (клієнт і сервер)

cr0x@server:~$ sudo nstat -az | egrep "TcpRetransSegs|TcpOutSegs|TcpInErrs"
TcpInErrs                    0                  0.0
TcpOutSegs                   4863921            0.0
TcpRetransSegs               12                 0.0

Що це означає: Retransmits повинні бути надзвичайно низькими в LAN. Постійні retransmits вказують на втрату пакетів або сильне переставляння.

Рішення: Якщо retransmits збільшується під час тесту, виправте мережевий шлях (кабелі/оптика, буфери комутатора, LACP hashing, MTU mismatch) перед тим як звинувачувати ZFS.

Завдання 5: Встановити сирий мережевий throughput з iperf3 (режим сервера)

cr0x@server:~$ iperf3 -s
-----------------------------------------------------------
Server listening on 5201 (test #1)
-----------------------------------------------------------
Accepted connection from 10.20.30.41, port 49822
[  5] local 10.20.30.10 port 5201 connected to 10.20.30.41 port 49824
[ ID] Interval           Transfer     Bitrate
[  5]   0.00-10.00  sec  10.8 GBytes  9.27 Gbits/sec

Що це означає: 9+ Gbit/s — хороший знак. Якщо ви застрягли на 3–5 Gbit/s, мережа або стек хоста обмежують.

Рішення: Якщо iperf3 не може розігнатися, не марнуйте час на налаштування NFS/SMB/ZFS. Виправляйте просту трубу спочатку.

Завдання 6: Використати кілька потоків, щоб досягти лінійної швидкості

cr0x@client:~$ iperf3 -c 10.20.30.10 -P 8 -t 15
[SUM]   0.00-15.00  sec  17.1 GBytes  9.80 Gbits/sec                  receiver

Що це означає: Multi-stream часто ховає обмеження single-flow (window sizing, CPU scheduling, offload quirks).

Рішення: Якщо multi-stream дає ~9.5–9.8, а single-stream низький, мережа в порядку; фокусуйтеся на TCP tuning, CPU і поведінці застосунку/протоколу (одно-потокове копіювання, sync-записи, дрібне I/O).

Завдання 7: Підтвердити MTU end-to-end (без фрагментації)

cr0x@client:~$ ping -M do -s 8972 10.20.30.10 -c 3
PING 10.20.30.10 (10.20.30.10) 8972(9000) bytes of data.
8972 bytes from 10.20.30.10: icmp_seq=1 ttl=64 time=0.215 ms
8972 bytes from 10.20.30.10: icmp_seq=2 ttl=64 time=0.207 ms
8972 bytes from 10.20.30.10: icmp_seq=3 ttl=64 time=0.209 ms

--- 10.20.30.10 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2035ms

Що це означає: Якщо це не вдається, у вас немає працюючих jumbo frames по всьому шляху. Часткові jumbo гірші за відсутність.

Рішення: Або зробіть MTU послідовним на NIC/VLAN/порті комутатора, або залишайтесь на 1500 скрізь і припиніть сперечатися про це.

Завдання 8: Перевірити NIC offloads і основні налаштування (TSO/GSO/GRO/RX/TX)

cr0x@server:~$ sudo ethtool -k enp65s0 | egrep "tcp-segmentation-offload|generic-segmentation-offload|generic-receive-offload|rx-checksumming|tx-checksumming"
rx-checksumming: on
tx-checksumming: on
tcp-segmentation-offload: on
generic-segmentation-offload: on
generic-receive-offload: on

Що це означає: Offloads можуть покращити throughput і зменшити CPU, але багаті драйвери/прошивка можуть спричиняти дропи або дивну латентність.

Рішення: Якщо ви бачите retransmits/drops і підозрюєте offload-проблеми, перемикайте фічі по одній під час контрольованого тесту. Не вимикайте все підряд «тому що Reddit».

Завдання 9: Спостерігати розподіл переривань (один «гарячий» CPU може вас обрізати)

cr0x@server:~$ grep -i enp65s0 /proc/interrupts | head
  72:  1203987   1123340   1189021   1098877   PCI-MSI 524288-edge      enp65s0-TxRx-0
  73:    23411     21987     24010     22022   PCI-MSI 524289-edge      enp65s0-TxRx-1
  74:    11234     10988     12001     11102   PCI-MSI 524290-edge      enp65s0-TxRx-2
  75:     9876      9455     10012      9666   PCI-MSI 524291-edge      enp65s0-TxRx-3

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

Рішення: Якщо розподіл перекошений — налаштуйте RSS/RPS/XPS, перевірте irqbalance і впевніться, що кілька TX/RX черг активні.

Завдання 10: Підтвердити здоров’я пулу ZFS і базове розміщення (ні, resilvering «не неважливий»)

cr0x@server:~$ sudo zpool status -v tank
  pool: tank
 state: ONLINE
  scan: scrub repaired 0B in 02:31:14 with 0 errors on Sun Dec 22 03:10:18 2025
config:

        NAME                        STATE     READ WRITE CKSUM
        tank                        ONLINE       0     0     0
          raidz2-0                  ONLINE       0     0     0
            sda                     ONLINE       0     0     0
            sdb                     ONLINE       0     0     0
            sdc                     ONLINE       0     0     0
            sdd                     ONLINE       0     0     0
            sde                     ONLINE       0     0     0
            sdf                     ONLINE       0     0     0
            sdg                     ONLINE       0     0     0
            sdh                     ONLINE       0     0     0

errors: No known data errors

Що це означає: Якщо у вас resilvering, scrub або pool degraded, висновки про продуктивність заражені.

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

Завдання 11: Виміряти серверну пропускну здатність дисків і затримки під час роботи клієнтів

cr0x@server:~$ sudo zpool iostat -v tank 1 5
                              capacity     operations     bandwidth
pool                        alloc   free   read  write   read  write
--------------------------  -----  -----  -----  -----  -----  -----
tank                        3.12T  21.8T    210    180   1.15G   320M
  raidz2-0                  3.12T  21.8T    210    180   1.15G   320M
    sda                         -      -     26     22    142M    40M
    sdb                         -      -     26     22    144M    39M
    sdc                         -      -     26     22    143M    40M
    sdd                         -      -     26     22    142M    40M
    sde                         -      -     26     22    143M    40M
    sdf                         -      -     26     22    143M    40M
    sdg                         -      -     26     22    144M    41M
    sdh                         -      -     26     22    144M    41M
--------------------------  -----  -----  -----  -----  -----  -----

Що це означає: Якщо ваш пул читає приблизно ~1.15G і ваш NIC показує ~9.5 Gbit/s, мережа може бути обмежувачем. Якщо пропускна здатність пулу набагато нижча і пристрої показують багато операцій, ви обмежені IOPS/латентністю.

Рішення: Якщо пул не може локально надати більше, ніж ви бачите по мережі — припиніть називати це мережею.

Завдання 12: Виміряти локальну продуктивність з fio (щоб обійти ілюзії кешу)

cr0x@server:~$ sudo fio --name=seqread --directory=/tank/test --rw=read --bs=1M --ioengine=libaio --direct=1 --iodepth=32 --numjobs=1 --size=20G --runtime=30 --time_based
seqread: (g=0): rw=read, bs=(R) 1024KiB-1024KiB, (W) 1024KiB-1024KiB, (T) 1024KiB-1024KiB, ioengine=libaio, iodepth=32
fio-3.33
seqread: (groupid=0, jobs=1): err= 0: pid=28144: Fri Dec 25 10:12:01 2025
  read: IOPS=1342, BW=1342MiB/s (1407MB/s)(40.0GiB/30538msec)
    slat (usec): min=6, max=214, avg=17.32, stdev=7.11
    clat (msec): min=1, max=41, avg=23.76, stdev=4.12

Що це означає: Локальний read BW (~1.4 GB/s) перевищує те, що може нести 10GbE. Чудово: сховище може годувати лінк.

Рішення: Якщо локальний BW набагато вище 1.2 GB/s, але мережеві читання значно нижчі — вузьке місце у мережі/протоколі/CPU, а не в дисках.

Завдання 13: Виміряти чутливість синхронних записів локально (SLOG — тест на правду)

cr0x@server:~$ sudo fio --name=syncwrite --directory=/tank/test --rw=write --bs=16K --ioengine=libaio --direct=1 --iodepth=1 --numjobs=1 --size=5G --runtime=20 --time_based --fsync=1
syncwrite: (g=0): rw=write, bs=(R) 16.0KiB-16.0KiB, (W) 16.0KiB-16.0KiB, (T) 16.0KiB-16.0KiB, ioengine=libaio, iodepth=1
fio-3.33
syncwrite: (groupid=0, jobs=1): err= 0: pid=28410: Fri Dec 25 10:14:44 2025
  write: IOPS=820, BW=12.8MiB/s (13.4MB/s)(256MiB/20008msec)
    clat (usec): min=340, max=8241, avg=1169.55, stdev=422.12

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

Рішення: Якщо ваш застосунок/протокол синхронно навантажений (бази даних, VM-образи, NFS з sync), ви не наситите 10GbE без роботи над синхронною латентністю (SLOG, налаштування, дизайн навантаження).

Завдання 14: Перевірити налаштування dataset ZFS, що впливають на стрімінг проти балакучості

cr0x@server:~$ sudo zfs get -o name,property,value -s local,default recordsize,atime,compression,sync tank/data
NAME       PROPERTY     VALUE
tank/data  recordsize   1M
tank/data  atime        off
tank/data  compression  lz4
tank/data  sync         standard

Що це означає: recordsize впливає на ефективність послідовних операцій; atime може додавати зайвих записів; compression може підвищувати видимий throughput (якщо дані добре стискаються) або коштувати CPU.

Рішення: Не чіпайте це, поки мережевий базлайн не доведений. Потім налаштовуйте під навантаження: великі файли хочуть більший recordsize; дрібні випадкові — менший і, можливо, окрема стратегія vdev/metadev.

Завдання 15: Спостерігати насичення CPU і softirq під час передачі

cr0x@server:~$ mpstat -P ALL 1 3
Linux 6.1.0 (server)  12/25/2025  _x86_64_  (32 CPU)

12:16:11 AM  CPU   %usr %nice  %sys %iowait  %irq %soft  %steal  %idle
12:16:12 AM  all   12.4  0.0   18.1   0.7    0.0  22.8    0.0   46.0
12:16:12 AM   7   10.0  0.0   21.0   0.0    0.0  65.0    0.0    4.0
12:16:12 AM  15   11.0  0.0   20.0   0.0    0.0  62.0    0.0    7.0

Що це означає: Якщо один або два CPU майже «вбиті» в %soft, ви обмежені стеком мережі хоста, а не лінійною швидкістю. Це виглядає як «10GbE повільний», але насправді «хост не може обробити пакети швидко».

Рішення: Виправте IRQ/RSS, подумайте про швидший CPU, кращий NIC/драйвер, або змініть поведінку протоколу (менше дрібних операцій, більше великого I/O).

Завдання 16: Перевірити монтування NFS і поведінку експорту (з боку клієнта)

cr0x@client:~$ nfsstat -m
/tank/data from 10.20.30.10:/tank/data
 Flags: rw,relatime,vers=4.1,rsize=1048576,wsize=1048576,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,clientaddr=10.20.30.41,local_lock=none

Що це означає: Маленькі rsize/wsize або невірна версія можуть приборкати throughput. v4.1 з 1M rsize/wsize зазвичай адекватні для великого стрімінгу.

Рішення: Якщо rsize/wsize малі — виправте mount options або конфіг сервера. Якщо використовується UDP (рідко зараз) — припиніть.

Завдання 17: Спостерігати retrans і RPC-поведінку NFS з боку клієнта

cr0x@client:~$ nfsstat -rc
Client rpc stats:
calls      retrans    authrefrsh
987654     12         0

Client nfs v4:
null         read         write        commit       open
0            120034       60012        0            320

Що це означає: Зростання retrans корелює з втратою пакетів або перевантаженням сервера. Це вбиває throughput, бо RPC чекає.

Рішення: Якщо retrans росте під навантаженням — досліджуйте дропи мережі або CPU contention сервера; не «зробіть timeo більшим» і не називайте це лікуванням.

Завдання 18: SMB сервер/клієнт: перевірити multi-channel і поведінку throughput

cr0x@server:~$ sudo smbstatus -b
Samba version 4.18.6
PID     Username     Group        Machine                                   Protocol Version  Encryption           Signing
-----------------------------------------------------------------------------------------------------------------------------
12011   alice        staff        10.20.30.41 (ipv4:10.20.30.41:52144)      SMB3_11           -                    partial(AES-128-GMAC)

Service      pid     Machine       Connected at                     Encryption   Signing
------------------------------------------------------------------------------------------
data         12011   10.20.30.41   Fri Dec 25 00:18:12 2025        -            partial(AES-128-GMAC)

Що це означає: SMB signing/encryption можуть коштувати CPU; multi-channel може працювати або ні залежно від конфігурації клієнта й сервера.

Рішення: Якщо CPU обмежує і SMB signing/encryption включено без потреби в захищеній LAN, вирішіть з безпекою чи зменшувати. Якщо потрібне — плануйте запас CPU.

Завдання 19: Відстежувати пропускну здатність по протоколу проти NIC-пропускної здатності (з боку сервера)

cr0x@server:~$ sar -n DEV 1 3
Linux 6.1.0 (server)  12/25/2025  _x86_64_  (32 CPU)

00:20:01     IFACE   rxpck/s   txpck/s    rxkB/s    txkB/s   rxcmp/s   txcmp/s  rxmcst/s
00:20:02   enp65s0   82000     79000     1150000   180000      0         0       120
00:20:03   enp65s0   83000     80000     1165000   175000      0         0       130

Що це означає: ~1,150,000 kB/s ≈ ~1.15 GB/s receive. Це близько до практичної стелі 10GbE для payload.

Рішення: Якщо NIC близький до стелі, але користувачі все ще скаржаться, ви, ймовірно, насичуєте лінк або маєте нерівномірний поділ між клієнтами. Розгляньте LACP (обережно), швидші лінки або QoS — не обряди з recordsize ZFS.

Завдання 20: Перевірити ARC і тиск пам’яті (бо «кеш» ховає проблеми)

cr0x@server:~$ sudo arcstat 1 3
    time  read  miss  miss%  dmis  dm%  pmis  pm%  mmis  mm%  arcsz     c
00:21:10   951    21      2     8   38    13   62     0    0   96G   112G
00:21:11  1002    24      2     9   37    15   63     0    0   96G   112G

Що це означає: Низький miss% під час читань означає, що ARC обслуговує багато. Ваш «мережевий тест пропускної здатності» може бути тестом RAM.

Рішення: Для доказу використовуйте direct I/O тести або великі робочі набори. Якщо ARC робить роботу — це нормально, але не приписуйте це продуктивності дисків.

Це більше ніж десяток завдань; використовуйте ті, що підходять під ваш стек. Суть не в накопиченні фактів — суттю є прийняття рішення після кожної команди.

Інтерпретація результатів: як довести вузьке місце

Як виглядає «мережеве вузьке місце», коли воно справжнє

Ви можете назвати мережу вузьким місцем, коли одночасно істинні ці пункти:

iperf3 між тими ж хостами досягає ~9.4–9.8 Gbit/s з низькими retransmits.
Локальне сховище сервера може перевищити 1.2 GB/s для вашого патерну доступу (або принаймні перевищує те, що ви отримуєте через NFS/SMB).
Під час реального доступу до файлів NIC близький до стелі, диски не насичені і CPU не задушений у softirq.
Протокольно-специфічна статистика (NFS retrans, SMB credit stalls, iSCSI retrans) не показує патологій.

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

Як виглядає «не мережеве вузьке місце»

Зазвичай «10GbE повільний» — одне з цих:

Випадок A: Втрата пакетів і retransmits під навантаженням

iperf3 може виглядати нормально для коротких стрибків, але тривалі передачі показують дропи, retransmits і крах throughput. Ви побачите зростання TcpRetransSegs, NIC d rops або дискард на порту комутатора. Це мережна проблема — навіть якщо лінк технічно 10Gb.

Типові винуватці: погана оптика/DAC, маргінальний кабель 10GBASE-T, MTU mismatch що викликає фрагментацію/чорні діри, виснаження буферів комутатора і перевантажені uplink-и.

Випадок B: Боттлнек CPU/переривань на сервері або клієнті

NIC на 10Gb, але хост — ні. Високе %soft на одному CPU, нерівномірні переривання або одно-потокова копія можуть обмежити throughput на 3–6 Gbit/s. Це дуже поширено на старих CPU або з невдалою конфігурацією драйверів.

Випадок C: Невідповідність протоколу/навантаження (дрібні I/O через балакучий протокол)

10GbE блищить на великих послідовних I/O. Якщо ваше навантаження — багато дрібних випадкових читань, операцій з метаданими або синхронних записів, throughput буде визначатися IOPS і латентністю, а не пропускною здатністю. Це не мережеве вузьке місце — це реалії навантаження.

Випадок D: ZFS синхронна записова латентність (і міф «SLOG врятує нас»)

Якщо ви робите sync-записи, throughput може бути крихітним, тоді як мережа просто сидить у спокої. Ви побачите низькі MB/s, але багато операцій і підвищену латентність. Без належного SLOG (і правильних очікувань) ви не виправите це MTU-налаштуванням.

Цитата, яку варто тримати в каналі інцидентів

«Сподівання — це не стратегія.» — парафразована ідея, поширена в інженерних і операційних колах

Чи чули ви це на постмортемі чи ні, суть: вимірюйте, ізолюйте, вирішуйте.

Жарт #2: Якщо ви «пофіксували» продуктивність 10GbE вимиканням контрольних сум — ви не налаштували систему, ви вчинили злочин проти реальності.

Три корпоративні міні-історії (болісні, реальні, корисні)

Міні-історія №1: Аутедж через невірне припущення

Команда мала новий NAS на ZFS, що обслуговував VM-образи по NFS до невеликого кластера. Тести пам’яті здавались сильними: локальні читання були вище 1 GB/s, латентність здавалася нормальною, всі давали п’ять. А потім в понеділок вранці VM-boot-уни тягнулись як зомбі.

Миттєве припущення було класичним: «NFS повільний» і «ZFS треба настроїти». Хтось запропонував змінити recordsize, відключити atime повсюди (добре, але не по справі) і пограти з sync. Мережна команда сказала, що 10GbE лінки «up», тож це не вони.

Один SRE запустив iperf3 і отримав 9.7 Gbit/s протягом 10 секунд. Кейс закрито, правда? Але біль трапився під час тривалого навантаження. Вони повторили iperf3 на 10 хвилин з кількома потоками і побачили пилку throughput. Retransmits росли. Лічильники порту комутатора показали періодичні дискард-строки.

Корінь: NAS і гіпервізори були підключені через leaf switch pair з аплінком, який тихо був oversubscribed під час бекапів. Лінк технічно «10GbE» і «здоровий», але недоступний коли потрібен. Неправильне припущення — прирівнювати погоджену швидкість до доставленої здатності.

Виправлення: перемістили трафік бекапів, додали ємність там, де була конкуренція, і ввели простий алертинг на дискард порту комутатора та на host retransmits. Налаштування ZFS не торкалися. Проблеми зникли.

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

Інша компанія мала сервер ZFS для спільного зберігання медіа по SMB. Хотіли швидші копії великих відеофайлів. Хтось запропонував jumbo frames і підняв MTU 9000 на сервері та кількох робочих станціях. Комутатор «підтримував jumbo», тож все має бути добре.

Протягом дня стало краще. Потім пішли тікети: випадкові застої, передачі зависали на 95%, іноді копія перезапускалась з початку. Wireshark показав TCP retransmissions і іноді ICMP «fragmentation needed», які доставлялися не послідовно.

Проблема була не в jumbo frames як концепті. Проблема була в частковому розгортанні jumbo. Один сегмент комутатора мав MTU 9000, інший застряг на 1500 через старий інтерконект, а firewall в шляху трактував великі фрейми як підозрливі.

«Оптимізація» підвищила ймовірність важко діагностованого чорного відкидання і зробила систему менш надійною. Середній throughput підвищився в вузькому випадку, але хвостова латентність і частота збоїв зросли — саме так користувачі відчувають продуктивність.

Виправлення: або розгортати jumbo end-to-end з валідацією (включаючи кожен хоп і VLAN), або відкотити до 1500 і працювати над протоколом і layout дисків. Вони відкотилися, потім покращили SMB налаштування і клієнтську конкуренцію. Результат: трохи нижчий піковий throughput, але значно менше зависань. Користувачі перестали скаржитись — це єдиний істинний метрик.

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

Фінансова компанія мала ZFS appliance для нічних завантажень. Нічого особливого: NFS, кілька 10GbE лінків і суворий change-процес. Їхня секретна зброя не була магічним sysctl. Це була нудна дисципліна.

Вони тримали квартальний runbook базових тестів: iperf3 між відомими хостами, локальний fio послідовний read/write і протокольний тест, що імітував продакшн. Вони архівували виводи в систему тікетів. Це було так само захоплююче, як дивитися, як сохне фарба. Намагано.

Одного кварталу iperf3 паднув з near line rate до ~6 Gbit/s. Ніхто ще не скаржився. Вони все одно відреагували, бо базові лінії не брешуть без допомоги.

Розслідування виявило BIOS-оновлення, що скинуло параметри керування енергоспоживання PCIe і підсумувало NIC у менш оптимальний стан під навантаженням. Зміна не порушила зв’язок; вона просто тихо зменшила throughput. Оскільки були збережені базові лінії, вони довели регресію, ізолювали її і відкотили на правильні налаштування.

Урок: нудні тести, що виконуються регулярно, виявляють проблеми до того, як користувачі їх помітять. «Але вчора все працювало» стає «у нас є diff». Це — операційна зрілість.

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

1) Симптом: «Маємо лише 3–5 Gbit/s на 10GbE»

Корінь: Один TCP потік обмежений (window sizing, CPU, interrupt affinity) або клієнт не встигає.

Виправлення: Підтвердіть з iperf3 -P 8. Якщо multi-stream швидкий, налаштуйте навантаження на паралелізм (кілька потоків копіювання), виправте IRQ/RSS або покращіть CPU/NIC.

2) Симптом: Throughput пікиють потім падають кожні кілька секунд

Корінь: Втрата пакетів через мікробурсти, виснаження буферів комутатора або перевантажені uplink-и; TCP сильно відступає.

Виправлення: Перевірте discard комутатора і retransmits на хості. Зменшіть конкуренцію, додайте пропускну здатність або застосуйте QoS. Не чіпайте ZFS спочатку.

3) Симптом: Великі послідовні читання швидкі, записи — повільні

Корінь: Sync-записи (NFS/VM/БД) обмежені латентністю ZIL; немає підходящого SLOG; або SLOG є, але не має захисту від втрати живлення.

Виправлення: Підтвердіть fio sync тести і характеристики навантаження. Додавайте SLOG лише якщо навантаження виграє, і обирайте пристрій з низькою латентністю і захистом від втрати живлення.

4) Симптом: «Jumbo frames покращили один клієнт, але зламали інших»

Корінь: MTU mismatch на шляху або змішані MTU-домени без коректної маршрутизації/PMTUD.

Виправлення: Або розгорніть MTU end-to-end з валідацією через ping -M do, або стандартизуйтесь на 1500.

5) Симптом: SMB копіювання повільне і CPU високе

Корінь: Витрати на SMB signing/encryption, одно-потокова поведінка клієнта або CPU сервера перевантажений в kernel/network stack.

Виправлення: Виміряйте CPU і SMB налаштування. Узгодьте з безпекою чи можна послабити signing/encryption в довіреній LAN; інакше забезпечте CPU і розгляньте зміну протоколу.

6) Симптом: NFS стає зависати і з’являються «server not responding»

Корінь: Втрата пакетів/retrans, сервер перевантажений або стрибки латентності сховища спричиняють RPC timeout-и.

Виправлення: Перевірте NFS retrans, TCP retrans і латентність сервера. Збільшувати timeo лише після виправлення причини, не як заспокійливе.

7) Симптом: Супер результати в синтетичних тестах, а в продакшні погано

Корінь: Бенчмарки потрапляють у ARC, обходять метадані або використовують послідовний I/O, відмінний від реального навантаження.

Виправлення: Тестуйте з робочим набором більшим за RAM, використовуйте --direct=1 для fio і імітуйте розмір I/O та конкуренцію реального навантаження.

8) Симптом: Додали LACP, але один клієнт все одно не може перевищити ~10GbE

Корінь: LACP не збільшує пропуск для одного потоку; хешування прив’язує потоки до одного фізичного лінка.

Виправлення: Використовуйте кілька сесій/клієнтів, SMB multichannel, NFS sessions або перейдіть на швидший одиночний лінк (25/40/100GbE), якщо потрібна швидкість для одного хоста.

Чеклісти / покроковий план

Покроковий план, щоб довести (а не гадати) вузьке місце

Заморозити поле бою: переконайтесь, що немає resilver/scrub, немає великих фоновых робіт, і тестуйте в контрольованому вікні.
Записати топологію: точний шлях client ↔ switch ports ↔ VLAN ↔ server port. Якщо не можете це намалювати — не зможете відладити.
Підтвердити лінк і PCIe: ethtool, lspci, лічильники помилок, дропи.
Запустити iperf3 базлайн: single stream, потім multi-stream, потім в зворотному напрямку. Зафіксуйте retransmits до та після.
Перевірити MTU-політику: або 1500 скрізь, або jumbo скрізь. Доведіть за допомогою ping -M do.
Виміряти локальне сховище: fio послідовне read/write з --direct=1; опційно тест синхронних записів, якщо релевантно.
Виміряти реальний протокол: NFS/SMB/iSCSI з репрезентативним тестом. Тримайте його відтворюваним.
Корелювати під час тесту: сервер zpool iostat, NIC throughput (sar), CPU softirq (mpstat), клієнтські retrans (nstat).
Прийняти рішення: оберіть найвужчу точку, підтверджену даними. Запишіть це з прикріпленими виводами.
Змінити одну річ: повторіть той самий тест. Якщо ви змінили три речі — ви нічого не навчилися.

Чекліст: ознаки, що ви справді мережево обмежені (чекліст «припиніть налаштовувати ZFS»)

iperf3 стабільно біля лінійної швидкості з низькими retransmits
NIC throughput близько 1.1–1.2 GB/s під час читання/запису файлів
Пул ZFS не насичений (дискова ширина і операції не максимальні)
CPU не зашкалює в softirq або на одному ядрі
Статистика протоколу чиста (немає сплесків NFS retrans, немає SMB stalls)

Чекліст: ознаки, що вузьке місце не в лінку, а в хості/протоколі

iperf3 швидкий з multi-stream, але single-stream повільний
високе %soft або перекошені переривання під час передач
низьке навантаження NIC при скаргах користувачів
синхронно-важке навантаження з низьким MB/s але високою латентністю операцій
висока частота передач пакетів (pps) при дрібних I/O і операціях з метаданими

Часті питання

1) Яку пропускну здатність очікувати від 10GbE для великого копіювання файлу?

В чистій LAN очікуйте приблизно 1.0–1.2 GB/s payload у кращому випадку. Якщо ви бачите ~800–1100 MB/s на великих послідовних передачах — ймовірно все в межах норми.

2) Чому iperf3 показує 9.8 Gbit/s, а SMB копія лише 400 MB/s?

Тому що мережева труба здорова, а щось вище її — ні: CPU-витрати на SMB signing/encryption, дрібні I/O, одно-потокове клієнтське копіювання, softirq на сервері або синхронна поведінка ZFS. Виміряйте CPU і протокольні статистики під час копіювання.

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

Ні. Вони можуть знизити навантаження на CPU при високих PPS, але також вводять режими відмов, якщо шлях не налаштований послідовно. Якщо не можете довести MTU end-to-end — використовуйте 1500 і рухайтесь далі.

4) Чи слід відключати NIC offloads, щоб «пофіксувати продуктивність»?

Тільки якщо є докази, що вони спричиняють дропи/retransmits або стрибки латентності з вашим драйвером/прошивкою. Перемикайте одну фічу за раз і повторюйте тест. Масове відключення часто підвищує використання CPU і знижує throughput.

5) Чи LACP — це відповідь на насичення 10GbE?

LACP підвищує агреговану пропускну здатність для кількох потоків, але не для одного потоку. Якщо один клієнт потребує >10Gb/s, вам потрібен швидший одиночний лінк (25/40/100GbE) або протокол/клієнт, який використовує кілька каналів.

6) Чи може стиснення ZFS покращити мережеву пропускну здатність?

Іноді так. Якщо ваші дані добре стискаються, сервер відправляє менше байтів по дроту, отже ефективна пропускна здатність зростає. Але ви платите CPU. Виміряйте і throughput, і CPU перед тим як рапортувати перемогу.

7) Як зрозуміти, чи обмежують мене sync-записи?

Якщо write throughput низький, латентність висока, і тести з fsync або бази даних поводяться аналогічно — швидше за все ви заблоковані латентністю підтвердження. Додавання відповідного SLOG може допомогти, але лише для sync-записів і лише якщо пристрій підходить.

8) Чому продуктивність змінюється залежно від часу доби?

Зазвичай через конкуренцію: oversubscribed uplink-и комутатора, вікна бекапів, реплікація або «шумні сусіди» в спільній інфраструктурі. Доведіть це, корелюючи падіння throughput з retransmits і дискард-рядками порту комутатора в ті проміжки.

9) Як зберегти тести чесними, коли ARC робить вигляд?

Використовуйте робочі набори більші за RAM, застосовуйте fio --direct=1 і повторюйте прогін після розігріву кешу з контрольованими розмірами файлів. Не бенчмаркьте пам’ять і не називайте це збереженням.

10) Якщо я дійсно мережево обмежений, які найкращі шляхи апгрейду?

Додайте пропускну здатність (25GbE — поширений крок), додайте паралелізм (кілька NIC/клієнтів) або розділіть навантаження по інтерфейсах. Правильний вибір залежить від того, чи потрібна вам швидкість для одного клієнта або агрегована багатьох.

Наступні кроки, які ви можете зробити цього тижня

Запустіть і збережіть три базові тести: iperf3 (single + multi-stream), локальний fio послідовний read і один протокольний тест (NFS/SMB), репрезентативний для продакшну.
Додайте два алерти: host TCP retransmits (client/server) і discard/drops на портах комутатора, що дивляться на NAS.
Визначте MTU-політику: 1500 скрізь або jumbo скрізь. Документуйте і забезпечте виконання.
Виберіть одне вузьке місце для виправлення: packet loss, CPU softirq, sync write latency або реальне насичення лінку. Не намагайтесь виправити все одним магічним sysctl.
Напишіть доказ: вставте виводи команд у тікет. Майбутнє-ви подякує теперішньому-ви, коли хтось скаже «це завжди так було».

Якщо ви зробите ізоляційні тести і числа все одно не зрозумілі — це не провал. Це дані, що кажуть, що реальна система цікавіша за діаграму. Ласкаво просимо у продакшн.