3D-стекінг і майбутнє чиплетів: куди рухаються CPU

Чому процесори змінилися: фізика, гроші і кінець «просто зменшіть техпроцес»

Десятиліттями прогрес CPU можна було сприймати як передбачувану підписку: кожне покоління ставало густішим, швидшим і (переважно) дешевшим за одиницю обчислень. Та ця ера не закінчилась драматичним пресрелізом. Вона завершилася тисячею малих компромісів — витік струму, вартість літографії, варіативність та незручний факт, що дроти не масштабуются так само, як транзистори.

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

Факти й історичний контекст (те, що дійсно допомагає міркувати)

• Факт 1: Dennard scaling (стабільна густина потужності при зменшенні транзисторів) фактично зупинилася в середині 2000-х, що змусило частотний ріст заякоритись і підштовхнуло до мультикорних дизайнів.
• Факт 2: Затримка міжз’єднань уже кілька років є першорядним вузьким місцем; внутрішні дроти не стають пропорційно швидшими з кожним вузлом, тож «більшою пластинкою» означає більше часу на переміщення бітів.
• Факт 3: Ліміти ретиклу обмежують, наскільки великим може бути одне експонування літографії; дуже великі кристали стають кошмаром за виходом придатних виробів, якщо їх не розбивати або не зшивати.
• Факт 4: Індустрія давно використовує мульти-чіп модулі (згадайте: ранні пакети з двома кристалами, серверні модулі), але сьогоднішні чиплети значно стандартизованіші й критичніші за продуктивність.
• Факт 5: High Bandwidth Memory (HBM) стала практичною завдяки стекуванню DRAM-чіпів і з’єднанню їх TSV; це показало, що вертикальна інтеграція може перевершити традиційну пропускну здатність DIMM.
• Факт 6: 3D-стекування кешу в мейнстримних CPU показало дуже конкретний урок: додавання SRAM вертикально може підвищити продуктивність без збільшення найбільш гарячого логічного кристала.
• Факт 7: Гетерогенні ядра (концепти big/little) існували в мобільних пристроях роками; тепер вони поширені в серверах, бо пропускна здатність і теплові обмеження, а не пікова частота, визначають пропускну спроможність.
• Факт 8: Складні пакувальні технології (2.5D інтерпозери, силіконові мости, fan-out) тепер є конкурентною відмінністю, а не лише деталлю бекенду виробництва.

Операційний висновок: наступні 10–15% приросту продуктивності менш ймовірно прийдуть від нових інструкцій, і більш ймовірно — від кращої локальності, розумніших ієрархій пам’яті та більш щільних зв’язків між кристалами. Якщо ваше навантаження чутливе до варіації латентності, треба ставитися до пакування і топології так само, як до маршрутизації в мережі.

Чиплети, міжз’єднання і чому «сокет» більше не означає те, що ви думаєте

Чиплет CPU — це пакет, що містить кілька кристалів, кожен із яких спеціалізується на чомусь: ядра, кеш, контролери пам’яті, IO, акселератори, іноді навіть процесори безпеки. Сам пакет — це продукт. «CPU» більше не є одною плитою; це невелика розподілена система під тепловим розподільником.

Чиплети існують з трьох прямих причин:

1. Вихід придатних виробів (yield): менші кристали мають кращий вихід; дефекти не вбивають весь величезний кристал.
2. Комбінація технологічних вузлів: швидка логіка на передовому вузлі, IO на дешевшому, зрілому вузлі.
3. Продуктова гнучкість: повторно використовувати відпрацьований IO-кристал у кількох SKU; варіювати кількість ядер і кеш-тайлів без повної переробки.

Міжз’єднання — тепер архітектура

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

Сучасні пакети використовують власні fabric-рішення, і галузь рухається в бік інтероперабельних стандартів die-to-die, наприклад UCIe. Ключова думка не в абревіатурі. Важливо, що зв’язки між кристалами обслуговуються як високошвидкісний IO: серіалізовані, синхронізовані, керовані по живленню, треновані, іноді з повторними спробами. Отже, стан лінку, лічильники помилок і стани живлення можуть впливати на продуктивність у способи, що здаються «випадковими», якщо їх не вимірювати.

Жарт №1: Чиплети — як мікросервіси: усім подобається гнучкість, поки не треба дебажити затримки через межі, які ви спеціально створили.

NUMA не був новим. Ви просто перестали його поважати.

Чиплетні CPU перетворюють кожен сервер на більш нюансовану NUMA машину. Іноді «NUMA-вузли» відповідають контролерам пам’яті; іноді — комплексам ядер; іноді — обом. У будь-якому випадку локальність важлива: яке ядро звертається до якої пам’яті, який тайл останнього рівня кешу ближчий, і як часто ви перетинаєте міжз’єднання.

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

3D-стекінг: вертикальна пропускна здатність, вертикальні проблеми

3D-стекінг — це використання кількох кристалів, складених вертикально з щільними з’єднаннями (часто TSV, мікро-бампси або гібридне бондування). Його застосовують для кешу, DRAM (HBM) і все частіше для логіки-на-логиці.

Навіщо стекувати?

• Пропускна здатність: вертикальні з’єднання можуть бути значно щільнішими, ніж маршрутизація по краю пакета.
• Латентність: ближча фізична відстань може знизити час доступу для певних структур (особливо кешу).
• Ефективність площі: можна додати ємність, не збільшуючи 2D-підпис найгарячішого логічного кристала.

Але нічого не дається просто так. 3D-стекінг вводить неприємний операційний трикутник: термальність, вихід придатних виробів (yield) і надійність.

Стекований кеш: чому це працює

Стекований SRAM над обчислювальним кристалом дає великий кеш останнього рівня, не роблячи обчислювальний кристал гігантом. Це може бути величезною перевагою для навантажень зі робочими наборами трохи більшими за традиційні розміри кешу: багато ігор, деякі EDA-потоки, певні in-memory БД, key-value сховища з “гарячими” ключами та аналітичні конвеєри з повторними сканами.

З операційної точки зору стекований кеш змінює дві речі:

1. Продуктивність стає більш бімодальною. Якщо ваше навантаження вміщується в кеш — ви герой. Якщо ні — ви повертаєтесь до DRAM і виграш зникає.
2. Тепловий резерв стає цінним. Додатковий кремній над обчислювальним кристалом впливає на тепловий потік; поведінка turbo і стійкі частоти може змінитися так, що це виявиться як варіація латентності.

HBM: чит-код пропускної здатності з цінником

HBM стекує DRAM-чіпи і розміщує їх близько до обчислювального кристала (часто через інтерпозер). Це дає величезну пропускну здатність у порівнянні з традиційними DIMM, але є обмеження по ємності на стек і висока вартість. Це також змінює режими відмов і спостережуваність: помилки пам’яті можуть проявлятися інакше, і планування ємності стає іншим видом спорту.

3D і 2.5D пакування також нав’язують нове правило проєктування: ваше програмне забезпечення має розуміти рівні. HBM проти DDR, близька пам’ять проти далекої, кеш-на-пакеті проти кеш-на-кристалі. «Просто аллоцювати пам’ять» стає рішенням щодо продуктивності.

Жарт №2: Стекувати кристали — чудово, поки ви не згадаєте, що тепло теж стекується, і на відміну від списку завдань його не можна відкласти.

Справжній ворог: байти, а не FLOPS

Більшість продакшн-систем не обмежені сирою арифметичною пропускною здатністю. Вони обмежені переміщенням даних: від пам’яті до кешу, від кешу до ядра, від ядра до NIC, від сховища до пам’яті і назад. Чиплети і 3D-стекінг — це визнання індустрією того, що пам’ять і міжз’єднання — це головна дія.

Тут інстинкти SRE допомагають. Коли пакет CPU стає фабрикою, вузькі місця виглядають як:

• Високий IPC але низький пропуск (чекає на пам’ять або конкуренцію за блокування).
• CPU не завантажений, але латентність висока (стали, промахи кешу, віддалена пам’ять).
• Продуктивність падає після масштабування (трафік між чиплетами зростає сверхлінійно).

Що змінюється з чиплетами і стекуванням

Локальність пам’яті більше не опціональна. На великому монолітному кристалі «віддалений» доступ усе ще може бути досить швидким. У чиплетах віддалений доступ може проходити через hops fabric і конкурувати з іншим трафіком. На SKU зі стекованим кешом «локальний» кеш може бути більший, але штраф за промах може бути більш помітним через змінену частоту/теплову поведінку.

Пропускна здатність не була однорідною. Деякі кристали мають ближчий доступ до певних контролерів пам’яті. Деякі ядра тісніше діляться певними кеш-тайлами. Топологія може винагороджувати хороше планування і карати наївне розміщення.

Варіація латентності стає нормою. Стани управління живленням, відсікання годин fabric і алгоритми бусту можуть змінювати внутрішні латентності. Ваш p99 помітить це раніше, ніж середні величини.

Теплові режими і енергоспоживання: пакет — нове поле битви

На папері ви купуєте CPU з TDP і частотою boost і вважаєте, що це кінець історії. Насправді сучасні CPU — це системи з управлінням енергією, які постійно домовляються про частоти на основі температури, струму й характеристик навантаження. Чиплети й 3D-стеки ускладнюють ці домовленості.

Гарячі точки і теплові градієнти

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

Дві операційні наслідки:

• Бенчмарки частіше брешуть. Короткі бенчмарки ловлять boost; продакшн ловить steady-state і ліміти потужності.
• Охолодження — це продуктивність. Маргінальне охолодження або проблеми з повітряним потоком не лише спричинять тротлінг; вони спричинять варіацію, яку важче діагностувати.

Надійність: більше з’єднань — більше місць для проблем

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

Корисний операційний афоризм, переказ ідеї відомого голосу в надійності: Складні системи виходять з ладу складними способами; зменшуйте невідомі і вимірюйте потрібні речі. (парафраз ідеї, натхненної підходами інженерії надійності)

Переклад: не припускайте однорідності між хостами і не припускайте, що два сокети поводяться однаково лише через те, що SKU співпадає.

Що це означає для SRE: продуктивність, надійність і шумні сусіди

Вам не потрібно ставати інженером пакування. Але потрібно припинити сприймати «CPU» як один скалярний ресурс. У світі чиплетів і стеків ви керуєте:

• Топологічними обчисленнями (ядра не однакової відстані від пам’яті і кешу)
• Пропускною здатністю міжз’єднання (внутрішній fabric може насичуватися)
• Тепловим резервом (стійкі частоти, тротлінг і p99)
• Політикою енергоспоживання (ліміти, turbo і взаємодія з планувальником)

Спостережуваність повинна розширитися

Традиційний моніторинг хостів — CPU%, load average, пам’ять у використанні — дедалі частіше не пояснюватиме вузькі місця. Вам потрібен мінімум базового розуміння:

• NUMA локальність (чи вирівняні потоки й пам’ять?)
• Поведіна кешу (LLC misses, тиск на пропускну здатність)
• Частота й тротлінг (чи обмежені ви потужністю?)
• Розміщення планувальника (чи Kubernetes або systemd не перемістили ваше навантаження по вузлах?)

І так, це дратує. Але це менше дратує, ніж квартал апгрейдів CPU з очікуванням прискорення і отримання уповільнення.

Швидка діагностика: знаходьте вузьке місце за хвилини

Це потік тріажу, який я використовую, коли сервіс гальмує на новій платформі з чиплетами/стеками або гіршає після масштабування. Мета — не ідеальний корінь проблеми. Мета — зробити правильне наступне рішення швидко.

Перше: визначте, чи ви обмежені обчисленнями, пам’яттю чи «fabric»

1. Перевірте частоту CPU і тротлінг: якщо частоти низькі під навантаженням — ви обмежені потужністю/термально.
2. Перевірте пропускну здатність пам’яті і тиск промахів кешу: якщо LLC misses і пропускна здатність високі — ви обмежені пам’яттю.
3. Перевірте NUMA локальність: якщо віддалених звернень багато — ви, ймовірно, обмежені топологією/планувальником.

Друге: підтвердіть топологію і розміщення

1. Перевірте NUMA-вузли і відповідність CPU → вузлам.
2. Перевірте афінітет процесу до CPU і політику пам’яті.
3. Перевірте, чи навантаження не стрибає між вузлами (міграції планувальника).

Третє: ізолюйте одну змінну і повторіть

1. Зафіксуйте навантаження на одному NUMA-вузлі; порівняйте p95/p99.
2. Примусьте локальне виділення пам’яті; порівняйте пропускну здатність.
3. Застосуйте консервативну політику енергоспоживання; порівняйте варіацію.

Якщо ви не можете відтворити істотних змін, контролюючи розміщення і стани живлення, проблема ймовірно на вищому шарі (блокування, GC, IO), і не варто звинувачувати пакет CPU. Сучасні CPU складні, але не магічні.

Практичні завдання з командами: що запускати, що означає, що вирішувати

Ось реальні завдання, які можна виконати на Linux-хостах, щоб зрозуміти поведінку, пов’язану з чиплетами/3D-стекінгом. Команди навмисно нудні. Нудні інструменти тримають вас чесними.

Завдання 1: Швидко відобразіть NUMA-топологію

cr0x@server:~$ lscpu | egrep 'Model name|Socket|Thread|Core|NUMA|CPU\(s\)'
CPU(s):                               128
Model name:                           AMD EPYC 9xx4
Thread(s) per core:                   2
Core(s) per socket:                   64
Socket(s):                            1
NUMA node(s):                         8

Що означає вивід: У вас 8 NUMA-вузлів на одному сокеті. Це топологія, притаманна чиплетам: кілька доменів пам’яті і hops між ними в одному пакеті.

Рішення: Якщо латентність важлива, плануйте прив’язувати ключові сервіси в межах NUMA-вузла й тримати пам’ять локально. За замовчуванням планувальник може бути «достатній», але «достатній» — це те, як гине p99.

Завдання 2: Дивіться, які CPU належать яким NUMA-вузлам

cr0x@server:~$ numactl --hardware
available: 8 nodes (0-7)
node 0 cpus: 0-15
node 0 size: 64000 MB
node 0 free: 61234 MB
node 1 cpus: 16-31
node 1 size: 64000 MB
node 1 free: 60110 MB
node 2 cpus: 32-47
node 2 size: 64000 MB
node 2 free: 59872 MB
node 3 cpus: 48-63
node 3 size: 64000 MB
node 3 free: 62155 MB
node 4 cpus: 64-79
node 4 size: 64000 MB
node 4 free: 60990 MB
node 5 cpus: 80-95
node 5 size: 64000 MB
node 5 free: 61801 MB
node 6 cpus: 96-111
node 6 size: 64000 MB
node 6 free: 61644 MB
node 7 cpus: 112-127
node 7 size: 64000 MB
node 7 free: 62002 MB

Що означає вивід: Кожен NUMA-вузол володіє діапазоном CPU і частиною пам’яті. Якщо ваш процес працює на CPU вузла 0, але аллоцює пам’ять з вузла 6, він платитиме “фабричну” плату за кожен віддалений доступ.

Рішення: Для сервісів з чутливою латентністю вирівняйте CPU pinning і політику пам’яті. Для завдань на пропускну здатність можливо краще інтерлеювати пам’ять для більшої сумарної пропускної здатності.

Завдання 3: Перевірте, чи ядро записує проблеми NUMA-локальності

cr0x@server:~$ numastat -p 1 3
Per-node process memory usage (in MBs) for PID 1 (systemd)
Node 0 Node 1 Node 2 Node 3 Node 4 Node 5 Node 6 Node 7 Total
----- ----- ----- ----- ----- ----- ----- ----- -----
Numa_Hit      12     10      9      8      9     10      8      9    75
Numa_Miss      1      0      0      0      0      0      0      0     1
Numa_Foreign   0      0      0      0      0      0      0      0     0
Interleave_Hit 0      0      0      0      0      0      0      0     0
Local_Node    12     10      9      8      9     10      8      9    75
Other_Node     1      0      0      0      0      0      0      0     1

Що означає вивід: Для PID 1 усе в порядку. Для вашого реального сервісу, якщо Other_Node великий, ви платите за віддалені доступи.

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

Завдання 4: Перевірте поведінку частоти CPU під навантаженням

cr0x@server:~$ sudo turbostat --Summary --quiet --show CPU,Avg_MHz,Busy%,Bzy_MHz,PkgTmp,PkgWatt --interval 5
CPU  Avg_MHz  Busy%  Bzy_MHz  PkgTmp  PkgWatt
-    2850     62.10  4588     86      310.12

Що означає вивід: Завантажені ядра працюють високо (Bzy_MHz), температура пакета висока, і потужність суттєва. Якщо Bzy_MHz падає з часом, а Busy% залишається високим — швидше за все ви обмежені потужністю/теплом.

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

Завдання 5: Підтвердьте, що політика живлення (governor) не саботує вас

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

Що означає вивід: Governor встановлено в performance. Якщо там powersave на хості, чутливому до латентності, ви фактично просите джиттер.

Рішення: Встановіть відповідну політику для ролі кластера. Пакет для пакетних задач може економити енергію; OLTP-кластер не повинен вдавати вигляд ноутбука.

Завдання 6: Виміряйте міграції планувальника (тихий NUMA-вбивця)

cr0x@server:~$ pidstat -w -p $(pgrep -n myservice) 1 5
Linux 6.5.0 (server)  01/12/2026  _x86_64_  (128 CPU)

01:10:01 PM   UID       PID   cswch/s nvcswch/s  Command
01:10:02 PM  1001     43210   120.00     15.00  myservice
01:10:03 PM  1001     43210   135.00     20.00  myservice
01:10:04 PM  1001     43210   128.00     18.00  myservice

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

Рішення: Розгляньте прив’язку CPU для найгарячіших потоків або налаштуйте час виконання (GC-потоки, кількість воркерів) щоб зменшити оборот.

Завдання 7: Перевірте тиск пропускної здатності пам’яті за допомогою pcm-memory (якщо встановлено)

cr0x@server:~$ sudo pcm-memory 1 -csv
Time,Ch0Read,Ch0Write,Ch1Read,Ch1Write,SystemRead,SystemWrite
1.00,12.3,5.1,11.8,4.9,198.4,82.1
2.00,12.5,5.0,12.1,4.8,201.0,80.9

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

Рішення: Зменште трафік пам’яті: виправте макет даних, зменшіть копіювання, підвищіть хит-рейти кешу або переходьте на платформу зі стекованим кешом/HBM, якщо ваш робочий набір підходить.

Завдання 8: Спостерігайте сигнали промахів кешу і стагнацій за допомогою perf

cr0x@server:~$ sudo perf stat -p $(pgrep -n myservice) -e cycles,instructions,cache-misses,branches,branch-misses -a -- sleep 10
 Performance counter stats for 'system wide':

    38,112,001,220      cycles
    52,880,441,900      instructions              #    1.39  insn per cycle
       902,110,332      cache-misses
     9,221,001,004      branches
       112,210,991      branch-misses

      10.002113349 seconds time elapsed

Що означає вивід: Багато промахів кешу. IPC непоганий, але промахи можуть домінувати над часом виконання залежно від навантаження. На чиплетних CPU промахи можуть транслюватися у трафік fabric і віддалені звернення пам’яті.

Рішення: Якщо промахи кешу корелюють зі спайками латентності, пріоритезуйте локальність: прив’яжіть потоки, зменшіть спільний стан і протестуйте SKU зі стекованим кешем, коли робочий набір трохи перевищує LLC.

Завдання 9: Перевірте помилки пам’яті та шторми скоректованих помилок

cr0x@server:~$ sudo ras-mc-ctl --summary
Memory controller events summary:
  Corrected errors: 24
  Uncorrected errors: 0
  No DIMM labels were found

Що означає вивід: Є скоректовані помилки. Зростаючий рівень може спричинити деградацію продуктивності та непередбачувану поведінку; на просунутих платформах пакування ви хочете помічати це рано.

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

Завдання 10: Підтвердьте стан лінків/PCIe (IO-кристал теж частина історії)

cr0x@server:~$ sudo lspci -vv | sed -n '/Ethernet controller/,+25p' | egrep 'LnkSta:|LnkCap:'
LnkCap: Port #0, Speed 16GT/s, Width x16
LnkSta: Speed 16GT/s (ok), Width x16 (ok)

Що означає вивід: Лінк працює на очікуваній швидкості/ширині. Якщо ви бачите downtrained лінки — IO-продуктивність падає і CPU цикли витрачаються на обробку переривань/пакетів.

Рішення: Downtrained лінки вимагають перевірки: riser-и, BIOS-настройки, прошивка та фізичне встановлення. Не «оптимізуйте» ПО навколо зламаного обладнання.

Завдання 11: Підтвердіть розподіл переривань (щоб уникнути pileup на одному ядрі)

cr0x@server:~$ cat /proc/interrupts | egrep 'eth0|mlx|ens' | head
  55:   10223342          0          0          0   IR-PCI-MSI 524288-edge      ens3f0-TxRx-0
  56:          0    9981221          0          0   IR-PCI-MSI 524289-edge      ens3f0-TxRx-1
  57:          0          0    9875522          0   IR-PCI-MSI 524290-edge      ens3f0-TxRx-2

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

Рішення: Прив’яжіть IRQ близько до NUMA-вузла NIC і до сервісних потоків, які обробляють пакети. Локальність стосується й IO.

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

cr0x@server:~$ numactl --cpunodebind=2 --membind=2 ./bench --duration 30
throughput=118223 ops/s
p99_latency_ms=3.4

Що означає вивід: Ви примусили і CPU, і пам’ять бути на вузлі 2. Порівняйте це з непінованими результатами. Великий дельта вказує на штрафи NUMA/fabric.

Рішення: Якщо пінінг суттєво покращує p99 — впровадьте політику розміщення (systemd CPUAffinity, Kubernetes topology manager або прив’язка на рівні сервісу), замість полювання на мікрооптимізації.

Завдання 13: Перевірте hugepages і індикатори тиску TLB

cr0x@server:~$ grep -E 'HugePages_Total|HugePages_Free|Hugepagesize' /proc/meminfo
HugePages_Total:    4096
HugePages_Free:     3900
Hugepagesize:       2048 kB

Що означає вивід: Hugepages доступні. У пам’яте-інтенсивних навантаженнях hugepages можуть зменшити промахи TLB, що важливіше, коли латентність пам’яті вже вища через віддалені звернення.

Рішення: Якщо профілювання показує тиск на TLB — увімкніть hugepages і валідуйте вплив. Не застосовуйте механіку наосліп — вимірюйте.

Завдання 14: Виявлення тротлінгу і причин лімітів потужності (приклад Intel через RAPL)

cr0x@server:~$ dmesg | egrep -i 'thrott|powercap|rapl' | tail -n 5
[ 8123.221901] intel_rapl: power limit changed to 210W
[ 8123.222110] CPU0: Package power limit exceeded, capping frequency

Що означає вивід: Система має power-capping. Ваш бенчмарк міг виконатись до втручання ліміту; продакшн виконується вже під цим лімітом.

Рішення: Узгодьте BIOS/прошивку і налаштування потужності з інтенцією навантаження. Якщо ви обмежуєтеся задля бюджету енергії датацентру — відкоригуйте SLO і налаштуйте конкурентність.

Три корпоративні міні-історії з ери чиплетів

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

Середня SaaS-компанія мігрувала latency-чутливий API-тир на нові сервери. Така сама кількість ядер як раніше, вищі рекламовані boost-частоти і великий показник L3-кешу, який виглядав як безкоштовні гроші. Роллаут був консервативним: 5% canary, метрики спочатку виглядали нормально, потім 25%, потім 50%.

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

Неправильне припущення: вони поводилися з CPU як із однорідним ресурсом і думали, що якщо середній CPU% нормальний — CPU не є вузьким місцем. Насправді навантаження розподілялось по NUMA-вузлах і часто аллоцювало пам’ять віддалено через поведінку рантайму та свободу планувальника контейнерів. Віддалені звернення не були катастрофічними; вони були варіабельними, що руйнувало хвостову латентність.

Вони довели це, зафіксувавши сервіс в одному NUMA-вузлі і примусивши локальне виділення пам’яті в тесті. p99 стабілізувався миттєво, і пилкоподібний малюнок зник. Виправлення було не гламурним: топологічно-усвідомлене планування, CPU pinning для найгарячіших подів і свідома політика пам’яті. Вони також перестали перепаковувати latency-чутливі й пакетні поди на одному сокеті. «Більша завантаженість» не була ціллю; ціль була — передбачувана латентність.

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

Фінтех-команда запускала ризиковий движок, який багаторазово сканував великий in-memory набір. Вони купили SKU зі стекованим кешем, бо бенчмарк вендора показав великий приріст. Ранні тести були багатообіцяючими. Пропускна здатність зросла. Усі святкували. Потім вони зробили те, що роблять компанії: «оптимізували».

Команда агресивно підняла паралелізм, думаючи, що додатковий кеш дозволить масштабуватись. Вони також включили агресивніший turbo-профіль у BIOS, щоб ганяти короткочасні швидкісні підйоми. У стейджингу робота закінчувалась швидше — більшість часу.

У продакшні оптимізація відплатилася двома способами. По-перше, додаткові потоки збільшили трафік між чиплетами, бо робоча структура була спільною і не була коректно розділена. Міжз’єднання почало перевантажуватись. По-друге, turbo-політика швидко підвищила температуру, викликавши термальне тротлінгування посеред виконання. Система не просто сповільнилась; вона стала непередбачуваною. Деякі запуски закінчувалися швидко; деякі потрапляли на тротлінг і тягнулися.

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

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

Велика корпоративна платформа стандартизувала «чекліст при підключенні апаратури» для нових поколінь CPU. У нього входили базові налаштування BIOS/прошивки, версії мікрокоду, перевірка NUMA-топології і набір perf/latency smoke-тестів, зафіксованих на конкретних вузлах.

Коли прийшла партія нових серверів, smoke-тести показали тонку регресію: пропускна здатність пам’яті була нижчою, ніж очікувалась на одному NUMA-вузлі, і p99 латентність при синтетичному змішаному навантаженні була гіршою. Нічого явно не падало. Більшість команд оголосили б це «в межах варіації» і пішли далі.

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

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

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

1) Симптом: спайки p99 після масштабування на більше ядер

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

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

2) Симптом: завантаження CPU помірне, але пропускна здатність низька

Корінна причина: Стави пам’яті (LLC misses, латентність DRAM), задирки fabric або часті міграції приховані за «не завантажений» CPU.

Виправлення: Використовуйте perf stat і інструменти пропускної здатності пам’яті; перевірте numastat; піньте й локалізуйте; зменшуйте аллокаторний шум і копіювання.

3) Симптом: нові сервери швидші в бенчмарках, але гірші в продакшні

Корінна причина: Бенчмарки ловлять boost-частоти і гарячі кеш-стани; продакшн працює в стійких лімітах потужності і змішаних навантаженнях.

Виправлення: Тестуйте стійкі прогони, включайте p99-метрики і валідуйте під реалістичною конкурентністю та тепловими умовами.

4) Симптом: один хост у пулі постійно дивний

Корінна причина: Downtrained PCIe-лінк, деградований канал пам’яті, шторм скоректованих помилок або дрейф BIOS, що впливає на енергію/топологію.

Виправлення: Перевірте lspci -vv, підсумки RAS, версії мікрокоду/BIOS; ізолюйте та виправте замість того, щоб налаштовувати під це ПО.

5) Симптом: джиттер латентності після увімкнення «енергозберігаючих» функцій

Корінна причина: Агресивні C-state, відсікання годин fabric, частотне масштабування або пакетні ліміти потужності викликають варіабельну поведінку пробудження/буста.

Виправлення: Використовуйте performance governor для латентнісних режимів, налаштуйте BIOS power states і перевірте turbostat під реальним навантаженням.

6) Симптом: падіння pps мережі після оновлення апаратури

Корінна причина: IRQ і потоки на різних NUMA-вузлах; IO-кристал і локальність NIC мають значення, і крос-вузловий трафік додає латентності.

Виправлення: Вирівняйте афінітет IRQ і потоки застосунку з NUMA-вузлом NIC; підтвердіть ширину/швидкість лінку; уникайте надмірної консолідації.

7) Симптом: «Ми додали стекований кеш, але не побачили виграш»

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

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

8) Симптом: після контейнеризації продуктивність погіршилася на чиплетних CPU

Корінна причина: Планувальник контейнерів перемістив потоки по CPU/NUMA-вузлах; cgroup CPU-квоти ввели сплески; локальність сторінки кешу погіршилась.

Виправлення: Використовуйте CPU manager/topology manager, встановіть явні requests/limits відповідно і пініть пам’ять-інтенсивні поди до NUMA-вузлів.

Чеклісти / покроковий план для нових платформ

Покроковий план: введення нової платформи з чиплетами/стеками в продакшн

1. Базова топологія: зафіксуйте lscpu і numactl --hardware для SKU; збережіть разом з артефактами збірки.
2. Стандартизувати прошивку: налаштування BIOS, мікрокод і політики енергії мають бути однаковими по пулу.
3. Виберіть стандартну енергетичну стратегію по тиру: латентні кластери отримують performance policy; пакетні кластери можуть навмисно бути power-capped.
4. Запустіть зафіксовані smoke-тести: виміряйте пропускну здатність і p99 із CPU+пам’яттю, прив’язаними до вузла; потім запустіть непіновані; порівняйте дельти.
5. Перевірте запас пропускної здатності пам’яті: якщо ваше навантаження обмежене пам’яттю — планування ємності означає планування пропускної здатності.
6. Перевірте локальність IO: перевірте стан PCIe лінків і розподіл IRQ; переконайтесь, що афінітет NIC відповідає розміщенню CPU.
7. Вирішіть політику розміщення: або прийміть NUMA (прив’язка і локалізація), або явно інтерлейвуйте для пропускної здатності. Не робіть «випадкового гібрида».
8. Розгорніть з детекцією варіації: слідкуйте не лише за медіанами, а й за розкидом по хостах; алертьте на «один хост дивний» рано.
9. Документуйте режими відмов: підписи тротлінгу, пороги скоректованих помилок і як ізолювати хост.
10. Повторно тестуйте після оновлень ядра: зміни планувальника можуть допомогти або зашкодити топологічній обробці; періодично валідуйте.

Чекліст: як вирішувати між стекованим кешем і більшою пропускною здатністю пам’яті

• Якщо ваш робочий набір трохи більший за LLC і ви бачите багато LLC misses: стекований кеш може дати великий виграш.
• Якщо пропускна здатність пам’яті близька до максимуму і превалюють стаги: стекований кеш може вас не врятувати; пріоритет — пропускна здатність (HBM платформи, більше каналів) або зменшення трафіку.
• Якщо хвостова латентність важлива: віддавайте перевагу рішенням, що зменшують варіацію (локальність, стабільна політика потужності), а не чисто піковим показникам.

Чекліст: чого уникати при впровадженні чиплет-орієнтованих CPU

• Не припускайте «один сокет = однорідність». Вимірюйте NUMA-поведінку.
• Не приймайте дрейф BIOS у автоскейлінг-групі.
• Не налаштовуйте додатки, не перевіривши спочатку поведінку потужності і тротлінг.
• Не змішуйте латентні і пакетні навантаження на одному сокеті без суворої ізоляції.

FAQ

1) Чи завжди чиплети швидші за монолітні кристали?

Ні. Чиплети насамперед — економічна і продуктова стратегія, з вигодами по продуктивності тоді, коли міжз’єднання і топологія управляються добре. Погана локальність може знищити виграш.

2) Чи зробить 3D-стекінг CPU гарячішими?

Часто так, на практиці. Стеки можуть ускладнювати відвід тепла і створювати гарячі точки. Вендори проектують навколо цього, але стійкі навантаження можуть відчувати ранні тротлінг або більшу варіацію.

3) Чи обов’язкове NUMA-тюнінг тепер?

Для latency-чутливих сервісів на чиплетних CPU це майже обов’язково. Для «емоційно паралельних» пакетних задач часто можна обійтися без нього — поки раптом не можна.

4) Які навантаження найбільше виграють від стекованого кешу?

Навантаження з робочим набором, який більший за звичайний кеш, але менший за DRAM-патріотичні стрімінги: hot key-value, деякі аналітичні задачі, певні симуляції і читин-важливі in-memory структури даних.

5) Який операційний ризик більш просунутого пакування?

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

6) Чи означає чиплети, що «більше ядер» перестануть допомагати?

Більше ядер і далі допомагатимуть для паралельних задач, але масштабування стає більш чутливим до пропускної здатності пам’яті, задирки fabric і конкуренції за спільний стан. Легкі виграші закінчилися.

7) Як HBM змінює планування ємності?

HBM підштовхує до багаторівневої моделі: дуже висока пропускна здатність, але обмежена ємність. Плануйте, що має залишитись в HBM, що може пролитися в DDR і як поводиться ваш аллокатор/рантайм.

8) Чи зробить UCIe пакети CPU модульними як збірка ПК?

З часом вони стануть більш модульними, ніж сьогодні — але не чекайте plug-and-play. Цілісність сигналу, доставка живлення, терміка і валідація усе ще складні, і «стандарт» не усуне фізику.

9) Яка найпростіша «достатня» зміна, щоб зменшити хвостову латентність на чиплетних CPU?

Прив’яжіть найгарячіші потоки до NUMA-вузла і тримайте їхньої пам’ять локально. Потім перевірте за допомогою зафіксованого A/B тесту. Якщо це допомагає — інвестуйте в топологічно-усвідомлене планування.

10) Чи купувати мені SKU зі стекованим кешем для всього?

Ні. Купуйте їх для навантажень, які демонструють чутливість до кешу під час профілювання. Інакше ви платите за кремній, який переважно прикрашає ваш procurement-список.

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

3D-стекінг і чиплети — це не тренд; це форма дороги попереду. CPU стає пакетно-рівневою розподіленою системою з тепловими й топологічними обмеженнями. Ваш софт і операції мають поводитися відповідно.

Що зробити наступного тижня (не в наступному кварталі)

1. Виберіть один сервіс з SLO по латентності і запустіть pinned vs unpinned NUMA тест (numactl), щоб виміряти чутливість.
2. Додайте дві панелі на хості: частота CPU/тротлінг (на основі turbostat) і віддалені NUMA-доступи (numastat/PMU, якщо є).
3. Стандартизуйтe базові налаштування BIOS/мікрокоду для кожного пулу апаратури; алертьте на дрейф.
4. Напишіть односторінковий runbook, використовуючи Швидку діагностику вище, щоб on-call не звинувачував мережу за звичкою.
5. Визначте філософію розміщення: локальність-перш за все для латентних тирів; інтерлив/пропускна здатність для throughput-ти грів — і примусьте її виконуватися.

Якщо ви нічого іншого не зробите, зробіть це: припиніть сприймати CPU% як істину. На чиплетах і стекованих дизайнах CPU% — це настрій. Виміряйте локальність, виміряйте пропускну здатність і виміряйте тротлінг. Тоді ви зможете сперечатися впевнено — а це єдина розумна суперечка, на яку може дозволити собі операційний відділ.