Ери чіпсетів: коли материнська плата вирішувала половину вашої продуктивності

Ви можете купити «правильний» процесор, вставити швидкий NVMe і все одно спостерігати, як ваша база даних тупцює, ніби читає з дискети.
Потім ви помічаєте неприємну правду: платформа — чіпсет, розводка ліній, uplink’и, вибір прошивки — тихо вирішувала вашу долю.

Це не ностальгія. Це польовий довідник для операторів: як ми сюди дісталися (північний/південний міст, DMI, політика PCIe-ліній),
і як довести — швидко — чи є материнська плата сьогодні вашим вузьким місцем.

Що насправді робив чіпсет (і що робить досі)

Романтична версія історії ПК каже: «CPU став швидшим, все інше пішло слідом.» Нудна версія — та, що пояснює ваші
виробничі графіки — полягає в тому, що платформи — це інженерія трафіку. Раніше чіпсети були буквальними регулювальниками руху. Тепер вони більше схожі
на набір платних пунктів і з’їздів, які ви помічаєте лише тоді, коли ваш вантажівка горить.

Традиційно чіпсет ділився на два великі блоки:

• Північний міст: високошвидкісні речі — контролер пам’яті, front-side bus, інтерфейс графіки (AGP/ранній PCIe) і часто шлях до всього, що мало значення.
• Південний міст: повільніші речі — SATA/PATA, USB, аудіо, спадкова шина PCI, інтерфейси прошивки та той самий клей, який робить материнську плату материнською платою.

Ключ не в назвах; ключ у топології. Продуктивність — це не тільки «наскільки швидкий CPU», а «скільки незалежних шляхів існує,
якої вони ширини та скільки конкуренції ви створили, засунувши все за одним uplink’ом».

Сучасні системи «інтегрували» багато функцій північного мосту в корпус процесора: контролер пам’яті, кореневий комплекс PCIe, іноді навіть I/O-дій
на окремому кремнії. Залишковий «чіпсет» (часто називають PCH на платформах Intel) досі забезпечує додаткові PCIe-лінії, USB,
SATA та іншій I/O — підключений до CPU через один uplink (DMI в Intel; подібні концепції в інших виробників).

Цей uplink — і є кульмінацією. Якщо ви підключаєте занадто багато пристроїв до чіпсета, ви відтворили старий вузький коридор південного мосту під новою гарною маркою.

Таймлайн ер чіпсетів: хто контролював вузьке місце

Ера 1: Монархія front-side bus (1990-ті — середина 2000-х)

В еру FSB ваш CPU спілкувався з північним мостом через спільний front-side bus. Пам’ять була позаду північного мосту. I/O — позаду південного мосту.
Північний і південний мости спілкувалися через виділений канал, який ніколи не був таким захопливим, як маркетинг обіцяв.

На практиці: затримки й пропускна здатність пам’яті сильно залежали від чіпсета, і «швидкий CPU» міг бути підбитий платою з
повільним FSB, слабшою реалізацією контролера пам’яті або поганою цілісністю сигналу, яка примушувала застосовувати консервативні таймінги. Оверклокери дізналися про це
першими, корпоративні покупці — пізніше, а операційні команди дізналися болісно, коли додаток «таємничо» вичерпувався на
пласкому графіку.

Зберігання в цю еру часто було позаду контролерів південного мосту з розділеними шинами (PCI, потім PCI-X у серверах), і можна було спостерігати,
як весь I/O системи танув у одній домені контенції. Якщо ви коли-небудь бачили RAID-контролер на 32-бітному/33MHz PCI — ви бачили трагедію.

Ера 2: Інтегрований контролер пам’яті (середина 2000-х — початок 2010-х)

AMD рано просунула інтегрований контролер пам’яті з Athlon 64. Intel приєднався пізніше з Nehalem. Це змінило все: CPU
отримав прямий контроль над пам’яттю, усунувши великий вузький коридор північного мосту. Воно також зробило поведінку пам’яті більш залежною від CPU та сокета,
ввівши сучасний світ NUMA як щоденну операційну реальність, а не дослідницьку тему.

Роль чіпсета змістилася. Замість обов’язкового шляху до пам’яті, він став блоком розширення I/O. Саме тут з’явився міф «чіпсет більше неважливий».
Він тоді був хибним і залишається хибним — просто інакше.

Ера 3: PCIe повсюди, але лінії — це політика (2010-ті)

PCI Express стандартизував високошвидкісний I/O. Чудово. Потім виробники стали випускати платформи, де CPU мав фіксовану кількість прямих PCIe-ліній,
а чіпсет — додаткові лінії… позаду одного uplink’а. Тож ви могли мати «багато слотів PCIe», але не багато незалежної пропускної здатності.

Саме тоді питаннями продуктивності стали біфуркація ліній, PLX/PCIe-комутатори та «який слот підключений до чого». Ви могли вставити
карту в слот форми x16 і все одно отримати x4 електрично. Посібник материнської плати став документом про продуктивність.

Ера 4: Платформа як сітка кристалів і зв’язків (кінець 2010-х — сучасність)

Сьогодні серверні CPU — складні системи: кілька каналів пам’яті, іноді кілька кристалів і кілька I/O-шляхів. «Чіпсет» може
бути менш центральним, але рішень щодо платформи стало більше: який NVMe йде прямо до CPU, який висить на чіпсеті, що за ретаймером,
де знаходиться PCIe-комутатор і чи ви вже насичуєте uplink, про який не підозрювали.

Профіль продуктивності зазвичай відмінний — поки ні. Коли щось ламається, це виглядає як помилки додатку, проблеми зі сховищем або «хмарка повільна».
Часто винна материнська плата.

Цікаві факти та контекстні моменти

1. AGP існував здебільшого тому, що PCI був занадто повільним для графіки; це був виділений шлях, бо спільні шини були тупиковими для продуктивності.
2. PCI (32-bit/33MHz) теоретично максимально близько 133MB/s — а реальна пропускна здатність гірша. Один зайнятий пристрій міг «залякати» шину.
3. Athlon 64 від AMD інтегрував контролер пам’яті, зменшивши затримки пам’яті і зробивши вибір чіпсета більше про I/O, а не про пам’ять.
4. Nehalem від Intel (ера Core i7) переніс пам’ять в CPU і ввів QPI, змістивши вузькі місця від FSB до топології інтерконекту.
5. DMI став тихим вузьким місцем: чіпсет може виставляти багато портів, але вони ділять єдиний uplink до CPU.
6. NVMe не лише додав швидкості; він усунув рівні (AHCI, спадкові переривання), тому він болісно карає погану розводку PCIe.
7. Ранні SATA-контролери сильно різнилися за якістю; маркування «SATA II» на коробці не гарантувало хорошого чергування або зрілості драйвера.
8. NUMA — це сучасний «чіпсетний» прикритий симптом: пам’ять швидка, доки ви не читаєте чиєсь інше пам’ять через посилання.
9. Споживчі платформи часто ділять лінії між слотами; заповнення одного M.2 слота може відключити SATA-порти або зменшити GPU-слот до x8.

Де вмирає продуктивність: класичні точки задушення

1) Спільні uplink’и (південний міст тоді, DMI/PCH нині)

Найпоширеніша сучасна відмова виглядає так: «Ми додали швидші SSD, але затримки не покращилися.» Ви тестуєте диски — вони в порядку — поодинці. Під навантаженням вони разом досягають потолка.
Цей потолок — uplink між CPU і чіпсетом.

Все, що позаду того uplink’а, конкурує: SATA-контролери, USB-контролери, додаткові PCIe-лінії від чіпсета, деякі вбудовані NICи,
іноді навіть Wi‑Fi (не ваша дата-центрівська проблема, але все одно підказка).

Коли uplink насичений, ви бачите черги всюди: вища затримка I/O, більше часу CPU в iowait і «випадковий» джиттер, який змушує SLO пропускати піки.
Це не випадково. Це контенція.

2) Розводка ліній і тренування лінків: x16-слот, що насправді x4

PCIe — point-to-point, що чудово — поки хтось не прокладе слот через чіпсет, не поділить лінії з M.2 або не змусить карту
тренуватися на нижшій швидкості через якість сигналу.

Ви побачите «LnkSta: Speed 8GT/s, Width x4», коли очікували x16, або знайдете HBA за PCIe-комутатором з вузьким апстрімом.
На папері це «працює». В продакшені це означає, що ваш трафік зберігання сам з собою бореться.

3) Канали пам’яті, правила заповнення і реальність NUMA

В еру північного мосту чіпсет контролював пам’ять. В еру інтеграції CPU контролює — але материнська плата вирішує, чи можна її правильно використовувати.
Якщо заповнити неправильні слоти, ви втрачаєте канали. Неправильне поєднання DIMMів знижує швидкість. Неправильне розміщення процесів — і ви переходите в remote‑NUMA
і платите затримки, на які не заклали бюджет.

Стек зберігання чутливий до затримок. Бази даних гіперчутливі. «Половина вашої продуктивності» — не перебільшення, якщо ви переходите NUMA‑кордон на гарячому шляху.

4) Значення прошивки за замовчуванням і енергоменеджмент

Прошивка материнської плати може перетворити стабільну платформу на джиттер-машину. Налаштування ASPM, C‑state’и, енергоменеджмент PCIe‑лінків, «енергоефективні» режими NIC — все це може додавати мікрозатримки, що стають макроболем під увагою tail‑latency.

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

5) Маршрутизація переривань, IOMMU і вартість «розумних» рішень

MSI‑X — це дар. Погана афінність переривань — прокляття. Якщо ви поставите переривання NVMe на неправильні ядра, ви побачите «CPU завантажений» без пропускної здатності.
Увімкнення IOMMU-функцій без розуміння навантаження може додати накладні витрати саме там, де ви їх ненавидите: в I/O-шляху.

Саме одна цитата, бо людям з надійності варто дати останнє слово:
Надія — це не стратегія. — Генерал Гордон Р. Салліван

План швидкої діагностики

Ви на виклику. Графік жахливий. Потрібна швидка відповідь: CPU, пам’ять, пристрій зберігання, шлях PCIe, uplink чіпсета чи мережа?
Не починайте з бенчмарків. Почніть з топології та лічильників.

Перш за все: підтвердьте домен вузького місця (CPU vs I/O vs пам’ять)

• Перевірте завантаженість CPU і iowait, щоб зрозуміти, чи ви обмежені обчисленнями, чи очікуєте на I/O.
• Перевірте затримку диску і глибину черги, щоб визначити, чи обмежує стек зберігання.
• Перевірте softirq/навантрення переривань, щоб впіймати вузькі місця в драйверах/IRQ, які маскуються під «завантажений CPU».

По-друге: перевірте швидкість/ширину PCIe лінку і розміщення пристроїв

• Підтвердьте, що кожен критичний пристрій тренується на очікуваному поколінні PCIe і ширині ліній.
• Змапте кожен пристрій до його NUMA-вузла і сокета CPU.
• Визначте, що сидить позаду чіпсета (а отже — позаду спільного uplink’а).

По-третє: перевірте симптоми насичення спільного uplink’а

• Кілька пристроїв уповільнюються разом під сумарним навантаженням.
• Піки затримки з’являються, коли відбувається «неспоріднений» I/O (USB‑бекапи, відновлення RAID по SATA, додатковий трафік NIC на лінії чіпсета).
• Продуктивність різко покращується, коли ви переміщаєте один пристрій на лінії, підключені напряму до CPU, або на інший сокет.

По-четверте: перевірте налаштування BIOS/прошивки і ядра, що впливають на затримки

• Функції енергоменеджменту, які додають час пробудження.
• PCIe ASPM/електроживлення лінків.
• Режим IOMMU і розподіл преривань.

Жарт №1: Якщо ваша «x16» карта працює на x4 — вітаю, ви виявили, що пластик швидший за мідь.

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

Це перевірки рівня production. Вони не скажуть вам «автоматично купіть нову материнську плату», але скажуть, куди дивитися і що змінювати. Кожне завдання містить реалістичну команду, приклад виводу, що це означає, і рішення.

Завдання 1: Швидка триаж CPU vs iowait

cr0x@server:~$ mpstat -P ALL 1 3
Linux 6.5.0 (db01)  01/09/2026  _x86_64_ (64 CPU)

12:10:31 PM  CPU   %usr  %nice  %sys  %iowait  %irq  %soft  %steal  %idle
12:10:32 PM  all  18.20   0.00  6.10   22.40   0.00  1.10    0.00  52.20
12:10:33 PM  all  17.90   0.00  5.80   24.10   0.00  1.00    0.00  51.20
12:10:34 PM  all  18.50   0.00  6.00   23.60   0.00  1.20    0.00  50.70

Що це означає: iowait високий і стабільний. CPU не завантажений; система чекає завершення I/O.

Рішення: Припиніть сперечатися про апгрейд CPU. Перейдіть негайно до перевірок шляху зберігання/PCIe та метрик затримки.

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

cr0x@server:~$ iostat -x 1 3
Linux 6.5.0 (db01)  01/09/2026  _x86_64_ (64 CPU)

Device            r/s   w/s  rkB/s  wkB/s  await  svctm  %util
nvme0n1         320.0  80.0  51200  12800   2.10   0.15  65.0
nvme1n1         310.0  85.0  49600  13600   8.90   0.16  92.0
sda              12.0  40.0    800   5200  45.00   1.20  55.0

Що це означає: nvme1n1 має високе await і майже насичена. sda має жахливу затримку (ймовірно SATA SSD/HDD або активність відновлення RAID).

Рішення: Якщо навантаження охоплює ці пристрої, ізолюйте його. Дослідіть, чому один NVMe гірший (ширина ліній, NUMA, IRQ, терморегулювання або спільне використання за чіпсетом).

Завдання 3: Перевірити швидкість/ширину PCIe для конкретного пристрою

cr0x@server:~$ sudo lspci -s 5e:00.0 -vv | egrep -i "LnkCap|LnkSta"
LnkCap: Port #0, Speed 16GT/s, Width x16, ASPM L1, Exit Latency L1 <64us
LnkSta: Speed 8GT/s (downgraded), Width x4 (downgraded)

Що це означає: Пристрій може працювати на PCIe Gen4 x16, але працює як Gen3 x4. Це проблема платформи: розводка слота, біфуркація, BIOS, райзер або якість сигналу.

Рішення: Перемістіть карту в слот, підключений до CPU, видаліть конфліктні M.2, перевірте налаштування PCIe в BIOS та перевірте райзер/кабель.

Завдання 4: Змапити NVMe до шляхів PCIe і NUMA-вузлів

cr0x@server:~$ for d in /sys/class/nvme/nvme*; do echo "== $d =="; cat $d/device/numa_node; readlink $d/device; done
== /sys/class/nvme/nvme0 ==
0
../../../0000:3b:00.0
== /sys/class/nvme/nvme1 ==
1
../../../0000:86:00.0

Що це означає: nvme0 локальний до NUMA вузла 0, nvme1 — до вузла 1. Це добре — якщо ваші потоки та виділення пам’яті вирівняні.

Рішення: Прив’яжіть IRQ та процеси так, щоб кожний NVMe обслуговувався CPU, локальними щодо його NUMA-вузла для затраточутливих навантажень.

Завдання 5: Підтвердити розклад NUMA та топологію CPU

cr0x@server:~$ lscpu | egrep -i "Socket|NUMA|CPU\(s\)|Thread|Core"
CPU(s):                               64
Thread(s) per core:                   2
Core(s) per socket:                   16
Socket(s):                            2
NUMA node(s):                         2
NUMA node0 CPU(s):                    0-31
NUMA node1 CPU(s):                    32-63

Що це означає: Два сокети, два NUMA-вузли. Доступ до пам’яті з іншого вузла реальний і вимірюваний.

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

Завдання 6: Виявити використання віддаленої NUMA-пам’яті у процесі

cr0x@server:~$ sudo numastat -p 1247
Per-node process memory usage (in MBs) for PID 1247 (postgres)
Node 0          22048.5
Node 1           1024.2
Total           23072.7

Що це означає: Пам’ять процесу здебільшого на вузлі 0. Якщо найгарячіші переривання сховища на вузлі 1, ви платите за віддалений трафік.

Рішення: Вирівняйте: або перемістіть обробку IRQ на вузол 0, або прив’яжіть процес до вузла 1 з локальною пам’яттю (або розділіть навантаження за сокетами).

Завдання 7: Виявити дисбаланс переривань (класичний прихований обмежувач)

cr0x@server:~$ grep -E "nvme|mlx|eth" /proc/interrupts | head -n 8
  55:  1209931        0        0        0   PCI-MSI 524288-edge      nvme0q0
  56:  1187722        0        0        0   PCI-MSI 524289-edge      nvme0q1
  57:  1215540        0        0        0   PCI-MSI 524290-edge      nvme0q2
  58:  5401120        0        0        0   PCI-MSI 524291-edge      mlx5_comp0

Що це означає: Переривання потрапляють лише на CPU0 (перший стовпець вибухає, інші нулі). Це генератор вузького місця.

Рішення: Налаштуйте irqbalance належним чином або вручну прив’яжіть IRQ по ядрах локальних до NUMA-вузла пристрою.

Завдання 8: Перевірити лічильники помилок NVMe і скидання лінків

cr0x@server:~$ sudo nvme smart-log /dev/nvme1 | egrep -i "media_errors|num_err_log_entries|warning_temp_time"
media_errors                    : 0
num_err_log_entries             : 12
warning_temp_time               : 0

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

Рішення: Витягніть детальні журнали помилок, перевірте dmesg на наявність PCIe AER і огляньте слот/ретаймер/кабель. Не ігноруйте це: воно стає «випадковими» піками затримки.

Завдання 9: Підтвердити, чи пристрій сидить за PCIe-містком/комутатором (спільний апстрім)

cr0x@server:~$ sudo lspci -t
-[0000:00]-+-00.0  Intel Corporation Host bridge
           +-01.0-[01-3f]----00.0  PCIe switch upstream port
           |               \-02.0-[02-3f]----00.0  Non-Volatile memory controller
           \-1d.0-[40-7f]----00.0  Ethernet controller

Що це означає: NVMe знаходиться за PCIe-комутатором. Це може бути нормально — але апстрім може бути вужчим, ніж розгалуження вниз.

Рішення: Перевірте ширину/швидкість апстріму. Якщо це x8, що живить кілька x4 NVMe, очікуйте контенцію при паралельному навантаженні.

Завдання 10: Визначити SATA-пристрої і шлях драйвера контролера

cr0x@server:~$ lsblk -o NAME,TYPE,TRAN,MODEL,SIZE,MOUNTPOINT
NAME        TYPE TRAN MODEL            SIZE MOUNTPOINT
nvme0n1     disk nvme Samsung SSD      3.5T
nvme1n1     disk nvme Samsung SSD      3.5T
sda         disk sata ST4000NM0035      3.7T

Що це означає: Є SATA у міксі. Якщо він на чіпсеті, то ділить uplink-пропускну здатність з іншими пристроями чіпсета.

Рішення: Залишайте SATA для холодних даних або логів. Не вважайте його «ще одним диском» у пулах, чутливих до затримки, без ізоляції.

Завдання 11: Перевірити журнали ядра на помилки PCIe і downtraining

cr0x@server:~$ sudo dmesg -T | egrep -i "AER|pcieport|Downstream|link.*down|corrected error" | tail -n 12
[Tue Jan  9 11:58:22 2026] pcieport 0000:00:01.0: AER: Corrected error received: id=00e0
[Tue Jan  9 11:58:22 2026] pcieport 0000:00:01.0: PCIe Bus Error: severity=Corrected, type=Physical Layer
[Tue Jan  9 11:58:22 2026] pcieport 0000:00:01.0:   device [8086:460d] error status/mask=00000001/00002000
[Tue Jan  9 11:58:22 2026] pcieport 0000:00:01.0:    [ 0] RxErr

Що це означає: Фізичні кориговані помилки шару (RxErr). Вони можуть викликати повтори, піки затримки і іноді downtraining лінку.

Рішення: Розглядайте як стан шини/платформи: пере-встановіть, змініть слот, оновіть BIOS/прошивку, перевірте райзери/ретаймери і відстежуйте частоту помилок у часі.

Завдання 12: Виміряти потолок пропускної здатності PCIe простим тестом fio read (саніті-чек)

cr0x@server:~$ sudo fio --name=readtest --filename=/dev/nvme1n1 --direct=1 --ioengine=libaio --rw=read --bs=1M --iodepth=32 --numjobs=1 --runtime=15 --time_based=1
readtest: (g=0): rw=read, bs=(R) 1024KiB-1024KiB, (W) 1024KiB-1024KiB, ioengine=libaio, iodepth=32
fio-3.36
read: IOPS=2900, BW=2900MiB/s (3041MB/s)(43.0GiB/15101msec)

Що це означає: 2.9GiB/s підозріло схоже на «Gen3 x4-ish» для послідовного читання, залежно від диска. Пристрій, що підтримує Gen4 x4, у правильному слоті може показувати більше.

Рішення: Перевірте за допомогою lspci -vv. Якщо лінк Gen3 x4 — обмежувач не SSD, а материнська плата.

Завдання 13: Перевірити політику швидкості лінків і стан ASPM (грім затримки)

cr0x@server:~$ cat /sys/module/pcie_aspm/parameters/policy
default

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

Рішення: Для систем, критичних до затримки, оцініть відключення ASPM в BIOS або через параметри ядра — лише після вимірювання впливу на енергоспоживання/тепловий режим і стабільність.

Завдання 14: Підтвердити поведінку частоти CPU під навантаженням (енергоменеджмент vs продуктивність)

cr0x@server:~$ grep -E "cpu MHz|model name" /proc/cpuinfo | head -n 6
model name	: Intel(R) Xeon(R) Silver 4314 CPU @ 2.40GHz
cpu MHz		: 1198.734
model name	: Intel(R) Xeon(R) Silver 4314 CPU @ 2.40GHz
cpu MHz		: 1200.112

Що це означає: CPU зараз у режимі низьких частот. Саме по собі це не проблема. Але якщо ви бачите повільне підняття або постійно низькі такти під навантаженням, політика живлення може саботувати затримку.

Рішення: Для серверів, де важлива хвостова затримка, встановіть профіль прошивки «Performance» і перевірте частоту під реальним навантаженням.

Завдання 15: Визначити, чи NIC підключений до чіпсета чи до CPU (поширено на змішаних платах)

cr0x@server:~$ sudo ethtool -i eth0
driver: mlx5_core
version: 6.5.0
firmware-version: 22.38.1002
bus-info: 0000:40:00.0

Що це означає: Ви можете зіставити 0000:40:00.0 у lspci -t, щоб побачити, чи він маршрутизований через мости чіпсета.

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

Жарт №2: Посібник материнської плати — єдина повість, де сюжетний поворот: «Слот 3 вимикає Слот 5».

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

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

Середня компанія мігрувала latency‑чутливе key-value сховище на «новіші, швидші» 1U сервери. Покоління CPU було помітним кроком уперед,
а в закупівельному листі гордо писалося «dual NVMe». Рол-аут виглядав чисто: той самий образ ОС, той самий ядро, ті самі налаштування та конфіг менеджмент. Що могло піти не так?

Першого тижня почалися сигнали p99 латентності під час пікового трафіку. Нічого драматичного — достатньо, щоб дратувати SRE і розпочати кілька «це, мабуть, аплікація» суперечок.
Команда аплікації вказувала на метрики хосту: CPU вільний, пам’ять мала резерв, мережа в порядку. Сховище виглядало дивно: обидва NVMe були «швидкими» поодинці, але під реальним навантаженням вони разом флуктуювали.

Неправильне припущення було простим: вони вважали, що обидва NVMe підключені до CPU. На цій материнській платі один слот M.2 був підключений до CPU,
інший — через чіпсет позаду uplink’а. Під час піків цей NVMe, підключений до чіпсета, конкурував з вбудованим 10GbE контролером, який теж був чіпсет‑прикріпленим.
Uplink став спільною чергою.

Виправлення було неефектним: перемістити другий NVMe на PCIe‑адаптер у слот, підключений до CPU, і перемістити NIC в інший слот, прив’язаний до іншого CPU.
Потрібно було ретельне мапування (і вікно обслуговування), але p99 латентність стабілізувалася одразу. «Швидший CPU» ніколи не був суттєвим.
Важлива була топологія платформи.

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

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

Інша команда хотіла більше пропускної здатності від вузла зберігання на розподіленій файловій системі. Через бюджетні обмеження вони купили плати споживчого типу з багатьма M.2 слотами і планували «масштабувати дешево».
План полягав у максимізації кількості пристроїв на вузол, щоб зменшити займаний простір у стійці й операційний оверхед.

В тестах це працювало — частково. Однопоточні послідовні бенчмарки виглядали добре. Випадковий I/O був прийнятним на помірній глибині. Але в багатонодовому продакшені пропускна здатність виходила на плато і затримка росла.
Моніторинг виявив підозрілу річ: додавання більше NVMe не збільшувало сумарну пропускну здатність пропорційно. Кожен новий диск давав менший приріст.

Справжній винуватець — PCIe‑топологія платформи: додаткові M.2 слоти були лініями чіпсета за єдиним uplink’ом. Вони побудували воронку. Під реальним навантаженням пристрої конкурували за той самий апстрім.
Гірше: деякі слоти ділили лінії з SATA і USB, тож фоновий трафік обслуговування створював непередбачуване перешкоджання.

Оптимізація відкотилася, бо оптимізувала неправильну метрику: кількість пристроїв. Правильна метрика для цього навантаження була незалежні домени пропускної здатності — лінії, підключені до CPU, кілька сокетів або плата, розроблена для зберігання з правильною розподілом ліній.

Остаточне рішення полягало в зменшенні кількості пристроїв на вузол і збільшенні кількості вузлів — нудніше, передбачуваніше і дешевше, ніж намагатися «винайти колесо» на топології, яка ніколи не була призначена для тривалого паралельного I/O.

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

Фінансова компанія керувала кластером баз даних з жорсткими SLO затримки. У них була одна звичка, яка здавалась зайвою зовні: кожне оновлення обладнання включало перевірочний список валідації платформи.
Не «вмикається чи ні», а «чи тренується PCIe на правильну швидкість», «чи узгоджене NUMA‑мапування» і «чи отримуємо очікувану пропускну здатність при активних кількох пристроях».

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

Їхній список перевірок виявив ці вузли до того, як вони почали обслуговувати клієнтів. Вони співвіднесли помилки з конкретною версією BIOS і певною ревізією райзера.
За підтримки вендора вони оновили BIOS і замінили райзери на ураженій партії. Кориговані помилки зникли, і разом з ними — «таємничі» піки затримки, які б з’явилися під навантаженням під кінець фінансового кварталу.

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

Практика, що врятувала день: забезпечуйте інваріанти платформи так само, як інваріанти конфігурації. Апаратне забезпечення — частина вашої конфігурації.

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

Це патерни, що повторюються, бо вони виглядають як «програмні проблеми», поки ви не простежите топологію.

1) Симптом: NVMe продуктивність в порядку поодинці, жахлива разом

• Корінь: Кілька пристроїв ділять єдиний апстрім (uplink чіпсета або апстрім PCIe-комутатора).
• Виправлення: Перемістіть найгарячіші пристрої на лінії, підключені напряму до CPU; перевірте ширину/швидкість апстріму; розділіть пристрої по сокетах, якщо доступно.

2) Симптом: «Оновили на Gen4 SSD, покращень немає»

• Корінь: Лінк downtrained до Gen3 або зменшена ширина через розводку слота, райзери, налаштування BIOS або помилки фізичного шару.
• Виправлення: Перевірте LnkSta через lspci -vv; оновіть BIOS; пере-вставте; поміняйте слот/райзер; переконайтеся, що немає конфліктного шарингу ліній з іншими слотами/M.2.

3) Симптом: піки p99 латентності корелюють з не пов’язаним I/O

• Корінь: Контенція спільного uplink’а: відновлення SATA, USB‑бекап або NIC, підключений до чіпсета, насичує той самий шлях, що й диски.
• Виправлення: Ізолюйте високошвидкісні пристрої на лініях CPU; плануйте гучні роботи; уникайте змішування «холодного зберігання» з гарячими NVMe у тому самому домені чіпсета.

4) Симптом: Високе завантаження CPU, але мала пропускна здатність; iowait не дуже більший

• Корінь: Вузьке місце в перериваннях/softirq або погана афінність IRQ; одне ядро обробляє більшість завершувальних робіт I/O.
• Виправлення: Перевірте /proc/interrupts; налаштуйте irqbalance; прив’яжіть MSI‑X вектори; тримайте обробку I/O на ядрах локальних до NUMA‑вузла пристрою.

5) Симптом: Продуктивність відрізняється між «ідентичними» серверами

• Корінь: Відмінності у версіях BIOS, різні райзери, різна заповненість слотів, помилки в заповненні каналів пам’яті або різні результати PCIe‑тренування.
• Виправлення: Застосуйте bill-of-materials для апаратури; стандартизуйте прошивку; захоплюйте й порівнюйте виходи топології (lspci -t, dmidecode, NUMA map).

6) Симптом: База даних сповільнилася після додавання ОЗП

• Корінь: Заповнення DIMM могло зменшити частоту пам’яті або кількість каналів; або локальність NUMA погіршилася, бо алокатор розподілив пам’ять по вузлах.
• Виправлення: Перевірте швидкість пам’яті і правила заповнення каналів; використовуйте правильні слоти; встановіть NUMA політики для бази даних; уникайте змішаних ранків/розмірів DIMM без валідації впливу.

7) Симптом: «Все швидко, крім малих записів»

• Корінь: Затримка, додана енергоменеджментом (ASPM/C‑state), накладні IOMMU або контролер за додатковим мостом з поганим розподілом преривань.
• Виправлення: Виміряйте хвостову затримку; протестуйте профілі прошивки; перевірте налаштування IOMMU; переконайтеся, що MSI‑X і розподіл IRQ адекватні.

8) Симптом: Помилки зберігання рідкісні, але піки затримки часті

• Корінь: Кориговані помилки PCIe фізичного шару, що викликають повтори; не фатальні, але достатні для шкоди.
• Виправлення: Моніторте AER повідомлення; замінюйте сумнівні компоненти; оновлюйте BIOS; переконайтеся, що лінки тренуються на очікувані швидкості після ремонту.

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

Контрольний список оцінки платформи (перед покупкою або розгортанням)

1. Попросіть карту ліній. Якщо ви не можете пояснити, які пристрої підключені до CPU, а які до чіпсета — ви купуєте коробку‑загадку.
2. Порахуйте незалежні домени пропускної здатності. Лінії CPU на сокет, пропускна здатність uplink’а та будь‑які PCIe‑комутатори.
3. Перевірте правила каналів пам’яті. «Підтримує 1TB» не те саме, що «підтримує 1TB на повній швидкості».
4. Перевірте взаємодію слотів. Який M.2 відключає які SATA? Який x16 стає x8 при заповненні іншого слота?
5. Підтвердьте розміщення NIC. Для вузлів зберігання не дозволяйте NIC і NVMe битися за той самий uplink.

Контрольний список валідації у стейджингу (для кожної моделі сервера)

1. Захопіть PCIe‑топологію: lspci -t, плюс lspci -vv для критичних пристроїв.
2. Захопіть NUMA‑мапування для пристроїв: /sys/class/nvme/*/device/numa_node і NIC bus-info.
3. Запустіть одно-пристроєвий fio саніті‑тест і паралельний multi-device fio, щоб виявити потолки спільного uplink’а.
4. Перевірте dmesg на AER після стресу. Кориговані помилки — дефект до доведення протилежного.
5. Базуйте розподіл преривань. Переконайтеся, що ви не будуєте чергу завершень на одному ядрі.

План розгортання в продакшн (нудно, повторювано, ефективно)

1. Стандартизуйте версії BIOS і прошивки по флоту перед порівнянням продуктивності.
2. Зафіксуйте заповнення слотів у відомому‑хорошому патерні і документуйте це як контракт API.
3. Застосуйте ОС‑тюнінг для розподілу IRQ і політик NUMA лише після вимірювання; не робіть карго-культа налаштувань ядра.
4. Сигналізуйте про кориговані PCIe‑помилки та ознаки downtraining лінків; розглядайте їх як ранні попередження.
5. Зберігайте знімки топології, щоб «ідентичний хост» насправді означав ідентичний.

FAQ

1) Чи має значення чіпсет, якщо в CPU є контролер пам’яті?

Так. Чіпсет усе ще агрегує багато I/O за єдиним uplink’ом. Якщо ваші гарячі пристрої сидять за ним, ви можете наситити цей шлях і
створити джиттер затримок, що виглядає як проблема аплікації.

2) Як визначити, чи NVMe підключений до чіпсета чи до CPU?

Почніть з lspci -t і знайдіть контролер NVMe. Якщо він маршрутується через мости чіпсета (і документація плати підтверджує це),
вважайте, що він ділить пропускну здатність uplink’а. Також перевірте NUMA‑вузол; пристрої, підключені до CPU, часто коректно мапляться до вузла сокета.

3) Чому PCIe лінк downtrain’иться?

Загальні причини: обмеження розводки слота, конфлікти біфуркації/спільного використання ліній, якість райзера, ретаймери, налаштування BIOS і помилки фізичного шару.
Downtraining часто — рішення платформи заради стабільності. Воно може «працювати як задумано», але при цьому псувати вашу пропускну здатність.

4) Чи завжди PCIe-комутатор поганий?

Ні. PCIe‑комутатори звичні в серверах зберігання. Питання в апстрімі: якщо комутатор розгалужує багато пристроїв за вужчим апстрімом, ви побудували контенцію.
Якщо апстрім достатньо широкий — це може працювати добре.

5) Що є сучасним еквівалентом вузького місця північного мосту?

NUMA і спільні uplink’и. Пам’ять швидка, але віддалена пам’ять — ні. А uplink’и чіпсетів — це новий «все ділимо цю шину» момент,
тільки з кращим маркетингом.

6) Бачу кориговані PCIe‑помилки. Якщо вони кориговані, навіщо хвилюватися?

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

7) Чи варто вимикати ASPM і глибокі C‑state’и на серверах?

Для пакетних систем з високою пропускною здатністю — можливо, ні. Для систем зі строгими SLO по хвостовій затримці — часто так, але лише після тестування.
Вимкнення навмання може обміняти джиттер на проблеми з енергоспоживанням/тепловим режимом або зменшити запас турбо.

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

Так. BIOS може впливати на тренування PCIe, таймінги пам’яті, енергоменеджмент і сумісність пристроїв. Він може усунути бурю коригованих помилок, покращити стабільність при вищих поколіннях PCIe або — іноді — ввести регресії.
Валідуйте, а потім стандартизуйте.

9) Чому «ідентичні» сервери поводяться по‑різному під навантаженням?

Тому що вони не ідентичні в важливих аспектах: результати PCIe‑тренування, заповнення DIMM, версії прошивки і заповненість слотів можуть відрізнятися.
Дрифт топології реальний. Захоплюйте й порівнюйте дані топології.

10) Коли обирати серверну платформу замість плати типу workstation?

Коли вам важлива передбачуваність I/O під паралельним навантаженням, валідація карти ліній, стабільна поведінка прошивки і віддалене управління.
Плати робочих станцій можуть бути швидкими, але часто ховають шаринг ліній і припущення про uplink чіпсета, що погано старіють у продакшені.

Висновок: наступні кроки, які ви справді можете зробити

Якщо ви запам’ятаєте одну річ, нехай це буде ось що: продуктивність — це топологія. Ери чіпсетів змінили місце, де живе вузьке місце, але не те, існують вони чи ні.
Раніше материнська плата вирішувала половину вашої продуктивності, контролюючи пам’ять і спільні шини. Нині вона вирішує половину вашої продуктивності, визначаючи,
які пристрої ділять uplink’и, як розведені лінії і чи працюють ваші преривання та NUMA‑локальність на вашу користь або проти вас.

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

1. Інвентаризуйте топологію на найзавантаженіших хостах: захопіть lspci -t, критичні lspci -vv, NUMA‑мапування і розподіл преривань.
2. Виберіть одне навантаження і доведіть локальність: вирівняйте переривання зберігання, афінність процесів CPU і локальність пам’яті до одного NUMA‑вузла.
3. Запустіть паралельний I/O тест у стейджингу, щоб виявити потолки спільного uplink’а до того, як зробить це продакшн.
4. Стандартизуйте прошивку і сигналізуйте про кориговані PCIe‑помилки та downtraining лінків.
5. Під час вибору обладнання ставте карти ліній і пропускну здатність uplink’а на перше місце, як кількість ядер CPU і обсяг RAM: як параметри планування ємності першого порядку.