Північний міст, що зник: як інтеграція переписала архітектуру ПК

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

Північний міст не просто зменшився. Він розчинився в CPU, забравши з собою контроль пам’яті, високошвидкісний I/O і часом графіку.
Цей архітектурний зсув переписав усе: де ховається латентність, де зникає пропускна здатність і як ви діагностуєте проблему, коли продакшн палає.

Що насправді робив північний міст

У класичну епоху чипсетів були дві важливі мікросхеми: північний міст і південний міст. Назви ніколи не були про географію. Вони про відстань
від CPU і швидкість шин, які вони керували.

Північний міст стояв між CPU і найшвидшими пристроями: ОЗП, високошвидкісною графікою (AGP, пізніше ранній PCIe) і іноді лінком до південного моста.
Це був високочастотний перетин, куди йшов кожен cache miss на вирішення. Південний міст обробляв «повільний» I/O: SATA/PATA, USB, аудіо, старий PCI
та подібне.

Це мало значення, бо шини були вже вужчі, часові домени простіші, і CPU не міг безпосередньо говорити DDR-сигналами або домовлятися про PCIe-зв’язки.
Отже, чипсет транслював, арбітрував і буферизував. Якщо пам’ятаєте дні «overclocking FSB», ви возилися з трасою від CPU до північного моста,
а не з якимось містичним тактом ядра.

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

Жарт №1: Радіатор північного моста був емоційною підтримкою ПК — маленький, декоративний і тихо переповнений реальністю.

Що він контролював, практично

• Контролер пам’яті: таймінги, арбітраж каналів і планування операцій читання/запису до DRAM.
• Інтерконект CPU: фронт-сайд бас (FSB) на багатьох Intel-платформах; HyperTransport у AMD підключався інакше, але мав подібні ролі.
• Графіка: AGP, а потім ранній PCIe графічні контролери часто «термінувалися» в північному мосту.
• Міст до «повільного» I/O: інтерфейс-хаб до південного моста, який експонував SATA/USB/PCI тощо.

Як він зник: хронологія інтеграції

Північний міст не помер за один драматичний реліз. Його поглинали функція за функцією, підштовхнуті фізикою і економікою: коротші трасси, менша латентність,
менше контактів і менше чипів для валідації. Це можна назвати «інтеграцією». Я називаю це «переміщенням радіусу ураження».

Цікаві факти й історичний контекст (коротко, конкретно)

1. FSB був загальною шиною на багатьох Intel-платформах: кілька агентів ділили пропускну здатність, і латентність погіршувалася з ростом ядер.
2. AMD пішла першою з контролером пам’яті у K8 (Athlon 64 / Opteron): інтегрований контролер пам’яті суттєво покращив латентність DRAM.
3. Intel пішов слідом з Nehalem (ера Core i7), перемістивши контролер пам’яті в кристал і відмовившись від класичного FSB на багатьох топових частинах.
4. «Північний міст» став «uncore» в термінології Intel: контролер пам’яті, сегменти LLC та інтерконект опинилися поза ядрами, але в межах пакета CPU.
5. Platform Controller Hub (PCH) консолідував те, що раніше було південним мостом плюс трохи проміжної логіки; «чипсет» став здебільшого I/O і політикою.
6. DMI став новим вузьким місцем на багатьох мейнстрім Intel-платформах: одиночний uplink, що з’єднує PCH з CPU для SATA, USB, NIC і «чипсетного» PCIe.
7. PCIe перемістився в CPU для основних ліній: GPU і високошвидкісні NVMe часто приєднуються безпосередньо до CPU, минаючи чипсетний uplink.
8. NUMA перестав бути екзотикою коли сервери з кількома сокетами і пізніше чиплетні дизайни зробили «де живе пам’ять» першочерговою змінною продуктивності.
9. On-die fabric став новим північним мостом: Intel ring/mesh і AMD Infinity Fabric — це тепер внутрішні автодори, яких ви не торкаєтесь, але яких треба поважати.

Чому індустрія зробила це (і чому ви не повернулися назад)

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

Це також змінило відповідальність. З зовнішнім північним мостом виробник материнської плати міг обрати чипсет, налаштувати підтримку пам’яті й іноді приховати помилки
за агресивним буферуванням. З контролером пам’яті в кристалі, вендор CPU бере на себе більше історії таймінгів. Добре для консистентності. Погано, коли ви намагаєтесь
розбиратися в відмовах, використовуючи інстинкти 2006 року.

Що його замінило: PCH, DMI та on-die fabrics

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

Новий блок-схема, перекладена у моделі відмов

Уявіть сучасну платформу так:

• Пакет CPU: ядра, кеші, інтегрований контролер пам’яті і частина PCIe-ліній (часто найшвидші).
• On-die інтерконект: ring/mesh/fabric, що з’єднує ядра, LLC, контролери пам’яті й корені PCIe.
• PCH/chipset: SATA, USB, аудіо, інтерфейси управління і «додаткові» PCIe-лінії (зазвичай повільніші й розділені).
• Uplink між CPU і PCH: DMI (Intel) або еквівалент; фактично PCIe-подібний лінк з обмеженим бюджетом пропускної здатності.

Тут інженери часто отримують удари: пристрій може на папері бути «PCIe x4 Gen3», але фактично стояти за чипсетомний uplink. Тоді він конкурує з усіма
іншими пристроями, приєднаними до чипсета: SATA-диски, вбудовані NIC, USB-контролери, іноді навіть додаткові NVMe-слоти. Раніше північний міст теж був великою
спільною зоною — але тепер вечірка розділилася: деякі гості — VIP, підключені безпосередньо до CPU, інші — за дверима в коридорі за DMI.

Інтеграція не зникла складності; вона її приховала

На папері простіше: менше чипів. В продакшні ви замінили видимий «північний міст» на невидимі внутрішні fabric та політики прошивки:
стани живлення, PCIe ASPM, memory training і розподіл ліній. Якщо діагностуєте стрибки латентності, ви тепер сперечаєтесь із мікрокодом і ACPI, а не з дискретною
мікросхемою, на яку можна вказати.

Цитата, яку варто тримати на моніторі:

«Сподівання — не стратегія.» — Генерал Гордон Р. Салліван

Чому це важливо у 2026 році

Бо вузькі місця, які ви бачите в реальних системах, рідко відповідають маркетинговим специфікаціям. Інтеграція змінила, де виникає контеншен і що означає «близько».
Ваша панель моніторингу може показувати високу латентність диска, але справжня проблема — PCIe-транзакції, що стоять у черзі за насиченим чипсетним uplink,
або пакунок CPU, що тротлиться через обмеження «uncore».

Що змінилось для роботи з продуктивністю

• Латентність пам’яті тепер залежить від CPU: доступ до DRAM залежить від контролера пам’яті CPU і поведінки внутрішнього fabric, а не лише від характеристик DIMM.
• Топологія PCIe знову має значення: «який слот?» — це не питання для новачка; це питання кореневої причини.
• NUMA повсюди: навіть односокетні системи можуть поводитись як NUMA через чиплети і кілька контролерів пам’яті.
• Керування енергоспоживанням — це фіча продуктивності: C-states, P-states, ліміти пакету і масштабування uncore можуть робити латентність стрибкоподібною.

Що змінилось для надійності

Менше чипів означає менше пайок — так. Але коли щось ламається, воно ламається «всередині пакета CPU», що не підлягає полюванню в полі.
Також прошивка тепер бере участь у коректності. Баги memory training і проблеми PCIe link можуть виглядати як нестабільне апаратне забезпечення. Іноді так і є.

Жарт №2: Нічого так не загартовує, як відлагодження «апаратних» проблем, які зникають після оновлення BIOS — раптом ваше кремнієве серце набрало ввічливості.

Швидка послідовність діагностики

Коли продуктивність падає або латентність стрибає, у вас немає часу ставати археологом. Потрібна відтворювана черговість перших/других/третіх перевірок, яка швидко
скаже, чи ви маєте справу з CPU, пам’яттю, топологією PCIe, сховищем або задусом uplink чипсета.

Перше: доведіть, де чек (CPU vs I/O vs memory)

• Перевірте насичення CPU і чергу виконання (run queue). Якщо load високий, але використання CPU низьке, можливо, ви в обмеженні I/O або стоїте на пам’яті.
• Перевірте латентність диска і глибини черг. Якщо латентність висока, але використання пристрою низьке, вузьке місце може бути вище пристрою (PCIe/DMI) або нижче (блокування файлової системи).
• Перевірте тиск на пам’ять. Свопінг підмінює «проблему зі сховищем», тоді як реальна причина — нестача RAM або неконтрольований кеш.

Друге: підтвердіть топологію (хто куди підключений)

• Замапте шляхи PCIe. Підтвердіть, чи «швидкий» пристрій підключено до CPU напряму або через чипсет.
• Підтвердіть швидкість і ширину лінку. Пристрій на x1 або Gen1 тихо зруйнує вам день.
• Перевірте локальність NUMA. Віддалений доступ до пам’яті або переривання, прикріплені до неправильного вузла, збільшать латентність.

Третє: перевірте політики живлення і прошивки

• Поведінка частоти CPU. Стрибкоподібна латентність може корелювати з агресивним енергозбереженням або пониженням uncore.
• Power management PCIe. ASPM може додавати латентності на деяких платформах; відключити — інструмент діагностики, не релігія.
• Налаштування BIOS. Bifurcation ліній, Above 4G decoding, SR-IOV і інтерлівінг пам’яті можуть радикально змінити результат.

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

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

Завдання 1: Ідентифікуйте модель CPU і базову топологію

cr0x@server:~$ lscpu
Architecture:                         x86_64
CPU(s):                               32
Thread(s) per core:                   2
Core(s) per socket:                   16
Socket(s):                            1
NUMA node(s):                         1
Vendor ID:                            GenuineIntel
Model name:                           Intel(R) Xeon(R) CPU
CPU MHz:                              1200.000
L3 cache:                             30 MiB

Що це означає: Ви дізнаєтесь, чи маєте справу з кількома сокетами/NUMA-вузлами і чи CPU зараз простоює на низькій частоті.

Рішення: Якщо NUMA nodes > 1, плануйте перевірку локальності процесів і IRQ. Якщо CPU MHz низький під навантаженням, перевірте governor та ліміти пакета.

Завдання 2: Перевірте поточний governor частоти CPU (латентність vs енергозбереження)

cr0x@server:~$ cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
powersave

Що це означає: «powersave» може бути нормальним для пропускних навантажень, але часто ворожий до хвостової латентності.

Рішення: Для систем чутливих до латентності розгляньте «performance» або платформо-специфічне налаштування. Валідовуйте бенчмарками; не слідуйте сліпо.

Завдання 3: Швидка перевірка I/O wait і run queue

cr0x@server:~$ vmstat 1 5
procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st
 2  0      0 412312  81216 921344    0    0    12    40  510  980 12  4 81  3  0
 5  1      0 401120  81216 920512    0    0    20   300  720 1200 10  5 60 25  0

Що це означає: Зростання wa вказує на час очікування I/O. Зростання r при низькому us може означати, що runnable-потоки блокуються десь ще.

Рішення: Якщо wa стабільно високий, переходьте до перевірок сховища/PCIe. Якщо si/so ненульові, відбувається свопінг — вирішуйте це в першу чергу.

Завдання 4: Подивіться, які блочні пристрої є і який у них scheduler

cr0x@server:~$ lsblk -o NAME,MODEL,TRAN,TYPE,SIZE,MOUNTPOINT
NAME        MODEL            TRAN TYPE  SIZE MOUNTPOINT
nvme0n1     Samsung SSD      nvme disk  3.5T
├─nvme0n1p1                  part  512M /boot
└─nvme0n1p2                  part  3.5T /
sda         ST4000NM000A     sas  disk  3.6T

Що це означає: Ви відрізняєте NVMe (ймовірно PCIe) від SATA/SAS (можливо за HBA, потенційно за чипсетом).

Рішення: Для «швидкого» шляху зосередьтесь на розміщенні NVMe і шляху PCIe. Для HDD-масивів фокусуйтеся на HBA-лінку і поведінці черг.

Завдання 5: Виміряйте латентність і завантаження по пристроях

cr0x@server:~$ iostat -x 1 3
Device            r/s     w/s   rkB/s   wkB/s  await  svctm  %util
nvme0n1         220.0   180.0  28000   24000   2.10   0.20  12.0
sda              10.0    80.0    640    8200  45.00   2.10  80.0

Що це означає: await — це end-to-end латентність. Високий %util з високим await вказує на насичення пристрою. Низький %util з високим await — підозра на upstream контеншен.

Рішення: Якщо NVMe має високий await але низький %util, підозрюйте проблеми PCIe link, переривання або контеншен за чипсетним uplink.

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

cr0x@server:~$ sudo nvme smart-log /dev/nvme0
SMART/Health Information (NVMe Log 0x02)
critical_warning                    : 0x00
temperature                         : 41 C
available_spare                     : 100%
percentage_used                     : 3%
media_errors                        : 0
num_err_log_entries                 : 0

Що це означає: Це перевірка здорового глузду: якщо ви бачите media errors або багато записів помилок, припиніть звинувачувати «платформу».

Рішення: Пристрій здоровий? Перейдіть вище по стеку до топології й шляхів ядра. Пристрій хворий? Плануйте заміну і зменшення ампліфікації записів.

Завдання 7: Замапте PCIe-пристрої і знайдіть адреси для подальшої перевірки

cr0x@server:~$ sudo lspci -nn | grep -E "Non-Volatile|Ethernet|RAID|SATA"
17:00.0 Non-Volatile memory controller [0108]: Samsung Electronics Co Ltd NVMe SSD Controller [144d:a808]
3b:00.0 Ethernet controller [0200]: Intel Corporation Ethernet Controller [8086:10fb]
00:1f.2 SATA controller [0106]: Intel Corporation SATA Controller [8086:2822]

Що це означає: Ви ідентифікуєте пристрої і їхні PCI-адреси для глибшої інспекції.

Рішення: Далі опитайте кожну адресу на статус лінку. Якщо лінк деградований — ви знайшли димлячий пістолет.

Завдання 8: Прочитайте статус PCIe-лінку (швидкість/ширина) для пристрою

cr0x@server:~$ sudo lspci -s 17:00.0 -vv | grep -E "LnkCap:|LnkSta:"
LnkCap: Port #0, Speed 16GT/s, Width x4
LnkSta: Speed 8GT/s (downgraded), Width x2 (downgraded)

Що це означає: Пристрій здатний на Gen4 x4, але працює на Gen3 x2. Це не «трохи повільніше». Це жорстке обмеження.

Рішення: Пересадіть у слот, змініть слот, перевірте налаштування BIOS bifurcation, перевірте riser-и і спільні лінії з іншими слотами.

Завдання 9: Візуалізуйте топологію PCIe, щоб побачити, чи пристрій стоїть за чипсетом

cr0x@server:~$ sudo lspci -t
-[0000:00]-+-00.0
           +-01.0-[0000:17]----00.0
           +-1c.0-[0000:3b]----00.0
           \-1f.0

Що це означає: Мости і root-порти показують дерево. Деякі root-порти підключені до CPU; інші — до PCH в залежності від платформи.

Рішення: Якщо ваш NVMe висить на шляху, що ділиться uplink-ом з кількома пристроями, очікуйте контеншен; розміщуйте критичні пристрої на CPU-лініях першими.

Завдання 10: Перевірте логи ядра на помилки PCIe і NVMe

cr0x@server:~$ sudo dmesg -T | grep -E "AER|pcie|nvme" | tail -n 8
[Tue Jan  9 10:12:01 2026] pcieport 0000:00:01.0: AER: Corrected error received: id=00e0
[Tue Jan  9 10:12:01 2026] nvme 0000:17:00.0: PCIe bus error: severity=Corrected, type=Physical Layer
[Tue Jan  9 10:12:01 2026] nvme 0000:17:00.0: AER: [ 0] RxErr

Що це означає: Corrected errors — це все ще помилки. Проблеми фізичного рівня часто вказують на сигнальну цілісність: слот, riser, материнську плату або живлення.

Рішення: Ставтеся до повторюваних corrected errors як до проблеми надійності. Заплануйте обслуговування для пересадки/переміщення обладнання і розгляньте примусове зниження Gen-режиму, якщо потрібно.

Завдання 11: Проінспектуйте макет NUMA і локальність пам’яті

cr0x@server:~$ numactl --hardware
available: 1 nodes (0)
node 0 cpus: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31
node 0 size: 128709 MB
node 0 free: 41212 MB

Що це означає: Тут один вузол, тому класичний NUMA не винен. На багатовузлових системах цей вивід каже, де знаходиться пам’ять і скільки вільно.

Рішення: Якщо є кілька вузлів, прикріпіть навантаження і переривання до вузлів, або забезпечте, щоби додаток був NUMA-aware.

Завдання 12: Знайдіть, які CPU обробляють переривання для NVMe або NIC

cr0x@server:~$ grep -E "nvme|ixgbe|mlx|enp" /proc/interrupts | head
 98:          0          0          0      81234   PCI-MSI 524288-edge      nvme0q0
 99:          0          0          0      40112   PCI-MSI 524289-edge      nvme0q1
100:          0          0          0      39998   PCI-MSI 524290-edge      nvme0q2

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

Рішення: Якщо є перекіс, налаштуйте IRQ affinity (або виправте політику driver/irqbalance), щоб черги рівномірно розподілялись по ядрах поблизу пристрою.

Завдання 13: Перевірте поведінку глибини черги сховища (NVMe)

cr0x@server:~$ cat /sys/block/nvme0n1/queue/nr_requests
1023

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

Рішення: Для систем чутливих до латентності не збільшуйте бездумно черги. Налаштовуйте за виміряною хвостовою латентністю, а не за відчуттями.

Завдання 14: Перевірте, чи ваш «швидкий» файловий шар фактично не блокується flush-ами

cr0x@server:~$ sudo blktrace -d /dev/nvme0n1 -o - | blkparse -i - | head -n 6
  8,0    0        1     0.000000000  1234  Q  WS 0 + 8 [postgres]
  8,0    0        2     0.000120000  1234  G  WS 0 + 8 [postgres]
  8,0    0        3     0.000300000  1234  D  WS 0 + 8 [postgres]
  8,0    0        4     0.001900000  1234  C  WS 0 + 8 [0]
  8,0    0        5     0.002000000  1234  Q  F  0 + 0 [postgres]
  8,0    0        6     0.004800000  1234  C  F  0 + 0 [0]

Що це означає: Ви бачите flush-и (F) і патерни синхронних записів (WS), які можуть серіалізувати продуктивність незалежно від сирої PCIe-пропускної здатності.

Рішення: Якщо хвости латентності збігаються зі сплесками flush-ів, налаштуйте параметри збереження додатка, опції монтування файлової системи або використайте WAL/commit-патерн, узгоджений з пристроєм.

Три міні-історії з реального життя

Міні-історія 1: Інцидент через хибне припущення

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

Вони поміняли NVMe між машинами. Повільна залишилася повільною. Це був перший корисний факт: причина не в SSD. Далі хтось помітив, що NVMe на повільному хості домовився про PCIe Gen3 x2, а інший працював Gen4 x4.
Та сама флешка, інший шлях. Виявилось, що «ідентична» збірка мала іншу ревізію riser-карти, бо закупівля «знайшла дешевший еквівалент».

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

Виправлення було нудне: стандартизувати SKU riser-ів, оновити BIOS до версії з кращим link training і додати скрипт валідації під час завантаження, що фейлить хост,
якщо критичні пристрої downtrained. Батч-термін повернувся негайно. Постмортем був різким: «ідентичний» — це обіцянка, яку треба перевіряти, а не ярлик.

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

Інша організація вела low-latency API на локальному NVMe. Вони ганяли p99-латентність і вирішили «оптимізувати», підвищивши паралелізм I/O:
більші глибини черги, більше робочих потоків, більші batch-и. Пропускна здатність у синтетичних тестах зросла. У продакшні p99 погіршився, потім p999 став кошмаром.

Платформа була сучасною: NVMe прикріплений до CPU, достатньо ліній, явного DMI-блокування не було. Проблема була всередині пакета CPU: масштабування частоти uncore і політика живлення.
При зростанні конкурентності система проводила більше часу в стані high-throughput, але також періодично виникали зупинки, коли пакет CPU керував термікою і енергією.
Розподіл латентності став з довгим хвостом.

Гірше того, вони прикріпили найактивніші робочі потоки до підмножини ядер для локальності кешу. Гарна ідея. Але переривання для NVMe черг падали на інший набір ядер,
змушуючи міжядерний трафік і збільшення контеншену на внутрішньому інтерконнекті. Вони фактично відтворили маленьку проблему північного моста всередині CPU: занадто багато агентів
конкурували за ті ж внутрішні шляхи.

Виправлення не було «відкатити оптимізацію». Воно полягало в дорослому налаштуванні: підганяти глибини черг під SLO латентності, вирівняти IRQ affinity з pinning-ом CPU
і вибрати цілі по пропускній здатності, що не викликатимуть енергетичних тротлінгів. Вони отримали трохи меншу пікову пропускну здатність, але значно кращу хвостову латентність.
Перемога була не у більшому числі, а в меншій кількості незадоволених клієнтів.

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

Одна фінансово-орієнтована компанія (імена приховано — юристи мають хобі) запускала змішані навантаження на флоті робочих станцій, що перетворювались на build-агенти.
Вони не були гламурні. Вони також не були однорідні: різні моделі материнських плат, різні ревізії чипсетів, різне розташування PCIe-слотів. Ідеальний шторм для плутанини «північний міст зник».

У команди була нудна практика: під час провізії вони фіксували апаратний fingerprint, включаючи ширини PCIe-лінків, NUMA-розклад і шляхи до пристроїв збереження.
Зберігали це в CMDB і дифили при кожному буті. Якщо машина відхилялась — downtrained link, відсутній пристрій, несподівана топологія — її карантували.

Одного тижня партія агентів почала випадково падати під час збірок із симптомами пошкодження файлової системи. Логи були брудними. Пристрої сховища виглядали здоровими. Але
diff fingerprint виявив повторювані corrected PCIe errors і перемовлений лінк після «теплого» ребута. Машини були зняті з сервісу до того, як відмови поширилися.
Винуватцем виявився маргінальний канал живлення PSU, що викликав нестабільність PCIe під піковим навантаженням.

Нічого героїчного не сталося. Жодних хитрих патчів ядра. Нудна практика спрацювала: виявляти дрейф, карантувати рано і тримати флот передбачуваним. Ось як виглядає надійність, коли вона працює: без пригод.

Типові помилки (симптом → корінна причина → виправлення)

Інтеграція прибрала північний міст як названий компонент, але не як концепт. Концепт — спільні ресурси й арбітраж — просто перемістився. Ось пастки, що я бачу
у відгуках інцидентів.

1) NVMe повільніший за SATA «якимось чином»

Симптом: NVMe показує гіршу пропускну здатність, ніж очікується; латентність стрибає при помірному навантаженні.

Корінна причина: PCIe-лінк downtrained (x1/x2, Gen1/Gen2) або пристрій розміщений за uplink-ом чипсета і конкурує з іншим I/O.

Виправлення: Перевірте LnkSta, перемістіть пристрій у слот, приєднаний до CPU, пересадіть/замініть riser, налаштуйте BIOS bifurcation, розгляньте примусове фіксування стабільної швидкості Gen.

2) «Латентність сховища», що насправді — поведінка пакета CPU

Симптом: I/O латентність стрибає у кореляції з подіями живлення CPU; пропускна здатність в нормі, але p99/p999 жахливі.

Корінна причина: Пониження частоти uncore, C-states пакета або термічний/енергетичний тротлінг, що впливає на внутрішній fabric і контролер пам’яті.

Виправлення: Налаштуйте governor, перегляньте BIOS-параметри живлення, покращіть охолодження і перевірте поведінку під контрольованим навантаженням.

3) Випадкові I/O помилки під навантаженням, а потім «все ок» після ребута

Симптом: Corrected PCIe errors, періодичні таймаути, ресети; зникає після пересадки або ребута.

Корінна причина: Проблеми сигнальної цілісності: маргінальний слот, riser, кабель або подача живлення; іноді баги у тренуванні прошивки.

Виправлення: Збирайте AER-логи, замініть підозрілі компоненти, оновіть BIOS і уникайте запуску критичних пристроїв через сумнівні riser-и.

4) Багатосокетна система поступається очікуванням односокетної

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

Корінна причина: NUMA-ефекти: алокації пам’яті і переривання перетинають сокети; віддалений трафік пам’яті насичує інтерконнект.

Виправлення: Використовуйте NUMA-aware розподіл, прикріпіть навантаження до вузлів, вирівняйте IRQ affinity і розміщуйте PCIe-пристрої близько до споживаючих CPU.

5) «Додали другий NVMe і стало повільніше»

Симптом: Додавання пристроїв зменшує продуктивність кожного; періодичні затримки.

Корінна причина: Спільні PCIe-лінії, помилкова конфігурація bifurcation або насичення спільного uplink-у (чипсет/DMI або спільний root-порт).

Виправлення: Замапте топологію, забезпечте незалежні root-порти для високопропускних пристроїв і уникайте перевантаження PCIe-ліній чипсета для масивів зберігання.

6) Пропускна здатність мережі падає під час завантаження диска

Симптом: NIC втрачає пропускну здатність під час важкого дискового I/O; CPU не завантажений.

Корінна причина: NIC і сховище за тим самим uplink-ом чипсета або обробка переривань конкурує на тих самих ядрах.

Виправлення: Перемістіть NIC на CPU-лінії, якщо можливо, розділіть affinity і перевірте розподіл IRQ і налаштування черг.

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

Чекліст A: При купівлі або складанні систем (щоб уникнути сюрпризів топології)

1. Вимагайте діаграму топології PCIe від вендора (або виведіть самі) і позначте, які слоти підключені до CPU, а які — до чипсета.
2. Зарезервуйте CPU-лінії для ваших найцінніших пристроїв: первинного NVMe, високошвидкісного NIC, GPU/акселереатора.
3. Припускайте, що uplink чипсета — це спільний бюджет; уникайте складання «критичного» I/O за ним.
4. Стандартизуйте riser-и і бекплейни; ставтеся до них як до компонентів продуктивності, а не як до аксесуарів.
5. Впровадьте boot-time валідацію: провал провізії, якщо лінки downtrained або пристрої з’являються на несподіваних шинах.

Чекліст B: Коли продуктивність погіршилась після зміни

1. Зніміть «до/після» статус PCIe-лінків (lspci -vv) для критичних пристроїв.
2. Зніміть поведінку частоти CPU під навантаженням (governor + спостережувані MHz).
3. Зніміть латентність I/O і завантаження (iostat -x) і порівняйте з базою.
4. Перевірте логи ядра на AER і ресети пристроїв.
5. Підтвердіть NUMA-розміщення процесів і IRQ.

Чекліст C: Коли підозрюєте контеншен uplink-а чипсета

1. Складіть список всіх пристроїв, ймовірно підключених за чипсетом: SATA, USB-контролери, вбудований NIC, додаткові M.2 слоти.
2. Перемістіть найвимогливіший пристрій у слот, підключений до CPU, якщо можливо.
3. Тимчасово вимкніть непотрібні пристрої в BIOS, щоб перевірити, чи повернеться продуктивність (швидкий тест ізоляції).
4. Повторно протестуйте пропускну здатність і латентність; якщо покращилось — у вас контеншен, а не «поганий SSD».

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

1) Чи справді північний міст «зник», чи його просто перейменували?

Функціонально він розділився й був поглинений. Контролер пам’яті і первинні PCIe root complexes перемістилися в пакет CPU; решта I/O-хаба стала PCH.
Роль «північного моста» існує, але тепер це внутрішні fabric і on-die контролери.

2) Чому важливо, чи NVMe підключений до CPU чи до чипсету?

Бо пристрої за чипсетом ділять uplink до CPU. Під навантаженням вони можуть конкурувати з SATA, USB і іноді вбудованим NIC-трафіком.
Пристрої, підключені до CPU, мають більш прямий доступ і зазвичай нижчу, стабільнішу латентність.

3) Чи DMI — нове вузьке місце північного моста?

На багатьох мейнстрім Intel-платформах — так: це точка, що з’єднує все, що висить за PCH. Це не завжди вузьке місце, але це поширена причина.
Ставтеся до нього як до обмеженого ресурсу, який можна наситити.

4) Якщо PCIe інтегрований у CPU, навіщо тоді ще потрібні PCIe-лінії чипсета?

У CPU обмежена кількість ліній. Лінії чипсета дають більше підключень дешевше, але зазвичай вони за uplink-ом і ділять пропускну здатність.
Чудово для Wi‑Fi карт і додаткових USB-контролерів. Ризиковано для критично важливих масивів зберігання.

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

Так, бо BIOS/прошивка керує memory training, PCIe link training, дефолтами політик живлення і іноді поведінкою мікрокоду.
Воно може виправити downtraining, зменшити corrected errors або змінити boost-поведінку — іноді на краще, іноді — на «сюрприз».

6) Чи завжди вимикати ASPM і енергозбереження заради продуктивності?

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

7) Як це стосується інженерії зберігання конкретно?

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

8) Який найшвидший спосіб виявити проблему «не в тому слоті»?

Перевірте переговорену ширину і швидкість лінку через lspci -vv і порівняйте з очікуваною. Якщо бачите «downgraded», зупиніться і виправте це перед налаштуванням софту.

9) Чи зробило зникнення північного моста ПК надійнішими загалом?

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

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

Північний міст не зник; він перемістився всередину CPU і перетворився на політики, fabric і uplinks. Якщо ви продовжите діагностувати продуктивність так, ніби на материнській платі є дискретний регулювальник руху,
ви й надалі будете ганятися за примарами.

Практичні кроки:

1. Зафіксуйте топологію: зберігайте lspci -t і lspci -vv статус лінків для критичних пристроїв на робочих хостах.
2. Зробіть дрейф видимим: надсилайте алерти на downtrained PCIe-лінки і повторювані corrected AER-помилки.
3. Розділіть критичний I/O: розміщуйте топ-рівневі NVMe і NIC на CPU-лініях; ставтесь до uplink-а чипсета як до спільного і крихкого ресурсу.
4. Налаштовуйте під SLO, а не під пік: глибина черги і конкуренція можуть купувати пропускну здатність і продавати вам хвостову латентність.
5. Напишіть runbook: використайте порядок швидкої діагностики — тип очікування, топологія, потім живлення/прошивка — щоб ваша команда перестала гадати під тиском.