Теплова стіна: як фізика поклала край улюбленій маркетинговій історії

Історія, що зламалась: GHz як бізнес-план

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

Проблема в тому, що Закон Морі (кількість транзисторів) ніколи не гарантував тактову частоту. Навіть кількість транзисторів — не те,
що люди думають. Операційна реальність обмежена подачею енергії, охолодженням і тим, як швидко ви можете перемістити дані туди, де
виконується обчислення. Ви можете запакувати багато транзисторів у маленький кристал; ви не можете запакувати нескінченний потік тепла
у радіатор. Фізика не веде переговорів. Фінанси — ведуть, але фізика перемагає.

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

Ось операційний переклад: якщо ви не можете пояснити, чому ваш сервіс швидкий, ви не зможете його утримувати швидким.
«Ми оновили тип інстанса» — це не стратегія продуктивності; це тимчасовий препарат із побічними ефектами.

Що теплова стіна насправді означає (і чого не означає)

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

Теплова стіна не означає «CPU стали гіршими». CPU стали складнішими. Вони приховують затримки кешами, out-of-order виконанням, передбаченням гілок,
спекулятивним виконанням і — коли все гаразд — турбо. Але в кінці кінців їх обмежують:

• Потужність: скільки ват пакет і платформа можуть подати без спрацьовування лімітів.
• Відвід тепла: як швидко ви можете перемістити тепло від кремнію до навколишнього повітря (або води) без перегріву.
• Енергія на корисну роботу: марна спекуляція, промахи кеша й зупинені конвеєри спалюють потужність, нічого не даючи вам.
• Переміщення даних: затримки пам’яті й I/O можуть перетворити «швидкий CPU» на дорогого офіціанта.

Стіна — це не один обрив. Це набір стель. Ваше навантаження зазнає іншої з них залежно від того, чи ви CPU-bound, memory-bound,
з великою кількістю гілок, дружні до векторів, важкі на I/O або просто розгорнуті в шасі з повітряним потоком, спроектованим кимось,
хто ненавидить вентилятори.

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

Фізика, яку не віддати на аутсорс

Основи потужності: чому напруга — злочинець

Спрощена модель динамічної потужності CPU: P ≈ C × V² × f, де C — ефективна ємність перемикання,
V — напруга, а f — частота. Деталі можна оспорювати, але імплікація незмінна:
збільшення частоти зазвичай вимагає підвищення напруги, а підвищення напруги шкодить у квадраті.

Ось чому «просто підвищити частоти» померло. Розгін з 3.5 GHz до 4.5 GHz рідко є лінійною вартістю. Це податок на потужність і тепло,
що проявляється як:

• Вищі навантаження на пакетний розгін і VRM
• Більш агресивне тротлінгування
• Менш передбачувана продуктивність при тривалому навантаженні
• Більші витрати на охолодження (і більше відмов вентиляторів, і більше скарг на шум)

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

Тепло має пройти від транзисторів через кремній, через розподільник тепла, через теплопровідний матеріал, у радіатор,
у повітря і назовні шасі. Кожен крок має опір. Ви можете його поліпшити, але не нескінченно і не дешево.

У датацентрі є також обмеження на рівні кімнати: температура на впуску, containment гарячих рядів, потужність CRAC, керування потоком повітря
і факт, що «цей один стійка в порядку» не те саме, що «цей один сервер посередині стійки в порядку».

Лікейдж: коли тепло породжує більше тепла

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

Брудний секрет: завантаженість ≠ продуктивність

Ядро при 60% завантаженості все ще може бути вузьким місцем, якщо воно витрачає час у стані очікування пам’яті або конкурує за блокування.
Тим часом стек зберігання може бути «в порядку» за пропускною здатністю й одночасно вбивати хвостову латентність. Теплова стіна підштовхнула архітектури
до опортуністичної продуктивності: короткі сплески високої частоти (турбо) і багато паралельних ядер. Це ускладнює інтерпретацію метрик,
а не спрощує.

Це не одна стіна: термальна, енергетична, пам’яті та «провід повільний»

Енергетична стіна: обмеження платформи, від яких не втечеш

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

Стіна пам’яті: ядра стали швидшими; пам’ять не встигла

Пропускна здатність обчислень CPU зростала швидше, ніж зменшувалась затримка DRAM. Ви можете додати канали і ширину, але затримка не падає
так, як очікують люди. Якщо ваше навантаження часто промахується в кеші, більше GHz мало допоможе — CPU чекає на пам’ять.

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

Стіна міжз’єднання/затримки провідників: відстань важлива і на кристалі

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

Стіна вводу/виводу: зберігання й мережа можуть бути прихованим джерелом тепла

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

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

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

• Тактові частоти здебільшого вийшли на плато у середині 2000-х для масових CPU; виробники переключились на масштабування багатоядерності замість безперервного підвищення GHz.
• «Dennard scaling» сповільнився: старе припущення, що зменшення транзисторів зменшує потужність на площу, зламалося, зробивши щільність потужності головним обмеженням.
• Ера Intel NetBurst наголошувала на високих частотах і глибоких конвеєрах; індустрія пізніше віддала перевагу дизайнам з кращою продуктивністю на ват.
• Turbo boost став мейнстримом: CPU опортуністично перевищують базову частоту, коли є термально/енергетичний запас, роблячи стійку продуктивність менш детермінованою.
• Великі кеші останнього рівня вибухнули в розмірах, бо промахи кеша стали надто дорогими відносно пропускної здатності ядра.
• Розширення SIMD/векторних інструкцій (SSE, AVX тощо) поширились як спосіб отримати більше роботи за цикл — ціною стрибків потужності і зниження частоти при важкому векторному навантаженні.
• Датацентри почали дбати про PUE як бізнес-метрику, що відображає: відведення тепла — реальна операційна витрата, а не побічний ефект.
• Спеціалізовані акселератори зросли (GPU, DPU, ASIC), бо загальноцільові ядра не можуть ефективно робити все в масштабі в межах бюджетів потужності.

Як теплова стіна проявляється в продакшені

У продакшені рідко бачиш великий банер «ТЕПЛОВА СТІНА». Бачиш непрямі симптоми:

• Латентність погіршується при тривалому навантаженні, навіть якщо завантаженість CPU не стрибає.
• Продуктивність відрізняється між ідентичними хостами через повітряний потік, пил, криві вентиляторів або прошивку.
• Нічні завдання працюють нормально взимку і «таємниче» повільніше влітку.
• Бенчмарки виглядають чудово 30 секунд; реальні навантаження працюють годинами і досягають теплового насичення.
• Додавання CPU ядер підвищує пропускну здатність, але погіршує хвостову латентність через контенцію пам’яті й планування.
• Одна стійка в порядку; один сервер — ні. Гарячі точки локалізовані й безжальні.

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

Жарт №1: Маркетинг любить «до» числа, бо «до» не вміщається на слайді. На жаль, ваш пейджер читає дрібний шрифт.

Швидкий playbook діагностики

Найшвидший спосіб витратити день — сперечатися «CPU чи сховище» без доказів. Зробіть ось що. Мета — ідентифікувати домінантне обмеження за 10–20 хвилин
і вибрати наступне вимірювання, а не виводити ідеальну теорію.

Спочатку: підтвердьте, чи вас тротлять або обмежують

• Перевірте поточні й максимум частоти, стан турбо і лічильники тротлінгу.
• Перевірте пакетні обмеження потужності і чи ви їх досягаєте (поведінка PL1/PL2).
• Перевірте температури і поведінку вентиляторів; шукайте нагрівання до насичення.

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

• Подивіться на тиск черги виконання та переключення контексту.
• Перевірте індикатори Stall пам’яті (промахи кеша, цикли в стані stall) за допомогою інструментів семплінгу.
• Перевірте конкуренцію за блокування і час ядра проти часу користувача.

Третє: перевіряйте черги I/O і латентність, а не лише пропускну здатність

• Сховище: per-device await, завантаженість та глибина черги.
• Мережа: повторні передачі, втрати та навантаження softirq.
• Файлова система: тиск на dirty pages, writeback і активність swap.

Четверте: перевірте топологію та політику

• NUMA-розміщення, IRQ афініті, governor CPU і обмеження cgroup.
• Віртуалізація або хмарні обмеження енергоменеджменту.
• Відмінності прошивки (мікрокод, BIOS power-настройки).

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

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

Завдання 1: Подивитися, чи CPU тротлиться через температуру

cr0x@server:~$ sudo dmesg -T | egrep -i 'thrott|thermal|PROCHOT' | tail -n 5
[Mon Jan  8 02:11:41 2026] CPU0: Core temperature above threshold, cpu clock throttled (total events = 17)
[Mon Jan  8 02:11:41 2026] CPU2: Core temperature above threshold, cpu clock throttled (total events = 17)
[Mon Jan  8 02:11:42 2026] CPU0: Package temperature above threshold, cpu clock throttled (total events = 9)

Значення: Ядро повідомляє, що CPU досяг термальних порогів і знизило частоту.
Рішення: Припиніть сперечатися про софт як перше. Перевірте охолодження, повітряний потік, криві вентиляторів і налаштування стійкої потужності;
потім повторіть стрес-тести після виправлення термальних проблем.

Завдання 2: Читати живі частоти і лічильники тротлінгу (Intel)

cr0x@server:~$ sudo turbostat --Summary --quiet --interval 5 --num_iterations 2
  Avg_MHz  Busy%  Bzy_MHz  TSC_MHz  CoreTmp  PkgTmp  PkgWatt  CorWatt  GFXWatt
    2870   62.14    4618     2600     92.0    95.0    188.4    142.7     0.0
    2555   63.02    4050     2600     96.0    99.0    205.1    153.2     0.0

Значення: Високий Busy% із падінням Avg_MHz і зростанням температур свідчить про стійкий термальний тиск; потужність висока й зростає.
Рішення: Якщо цей хост у гарячій стійці — виправте повітряний потік насамперед. Якщо це по всій флотилії — розгляньте обмеження потужності,
профілі вентиляторів або переформування навантаження (зменшити інтенсивність векторів, батчувати I/O).

Завдання 3: Перевірити політику частот CPU і governor

cr0x@server:~$ sudo cpupower frequency-info
analyzing CPU 0:
  driver: intel_pstate
  CPUs which run at the same hardware frequency: 0
  available cpufreq governors: performance powersave
  current policy: frequency should be within 800 MHz and 5200 MHz.
                  The governor "powersave" may decide which speed to use
  current CPU frequency: 1200 MHz (asserted by call to hardware)

Значення: Ви на powersave; під деякими навантаженнями він може не підніматися швидко або бути обмеженим політикою платформи.
Рішення: Для латентністих сервісів встановіть performance (або налаштуйте EPP) і виміряйте потужність/терміку після цього.
Не робіть цього сліпо на термально обмеженому шасі.

Завдання 4: Виявити CPU-капи cgroup, що маскуються під «термальні проблеми»

cr0x@server:~$ systemctl show --property=CPUQuota --property=CPUAccounting myservice.service
CPUAccounting=yes
CPUQuota=200%

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

Завдання 5: Перевірити тиск черги виконання і навантаження відносно ядер

cr0x@server:~$ uptime
 02:14:10 up 41 days,  6:22,  2 users,  load average: 48.12, 44.90, 38.77

Значення: Середнє навантаження близьке або вище кількості потоків CPU свідчить про зростаючий backlog runnable або внесок I/O wait.
Рішення: Далі запустіть vmstat і pidstat, щоб відокремити runnable від blocked і знайти винуватців процесів.

Завдання 6: Швидко відокремити насичення CPU від I/O wait

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
18  2      0 128432  64220 912340    0    0   120   980 8210 9920 42 14 33 11  0
22  5      0 121100  64180 905220    0    0    80  2100 9020 11020 38 12 29 21  0

Значення: Нетривіальний wa (I/O wait) з заблокованими процесами (b) вказує на затримки збереження або файлової системи.
Рішення: Перейдіть до iostat і перевірки латентності по дисках; не ривкуйте код, поки ядро чекає на чергу пристрою.

Завдання 7: Виміряти латентність і насичення по пристрою

cr0x@server:~$ iostat -x 1 3
Device            r/s     w/s   r_await w_await aqu-sz  %util
nvme0n1         120.0   980.0     1.20   18.40   7.90   96.5
nvme1n1         110.0   910.0     1.10   17.90   7.40   94.8

Значення: Високий w_await, велике aqu-sz і ~95% %util вказують, що пристрої насичені і записі чергуються.
Рішення: Зменште write amplification (батчування, стиснення, налаштування fs/zfs), додайте пристрої або перемістіть «гарячі» записи в інше місце.
Якщо це «лише логи», ставтеся до логів як до продакшен-трафіку.

Завдання 8: Перевірити тиск на writeback файлової системи (dirty throttling)

cr0x@server:~$ grep -E 'Dirty:|Writeback:' /proc/meminfo
Dirty:            184532 kB
Writeback:         81244 kB

Значення: Підвищені значення dirty/writeback пам’яті свідчать, що ядро штовхає записи і може тротлити писачів.
Рішення: Якщо ваш додаток чутливий до латентності, розгляньте ізоляцію write-heavy навантажень, налаштування dirty ratios або використання асинхронних/буферних конвеєрів з механізмом зворотного тиску.

Завдання 9: Виявити активність swap (часто в маскараді «стіна пам’яті»)

cr0x@server:~$ sar -W 1 3
Linux 6.5.0 (server) 	01/08/2026 	_x86_64_	(64 CPU)

02:15:01 AM  pswpin/s pswpout/s
02:15:02 AM      0.00     18.00
02:15:03 AM      0.00     22.00

Значення: Активність swap-out означає, що ви вичерпуєте сторінки; латентність може вибухнути, навіть якщо CPU виглядає «в порядку».
Рішення: Виправляйте тиск пам’яті першочергово: зменшіть робочий набір, налаштуйте кеші (додаток, JVM, ARC) або додайте RAM. Не «оптимізуйте CPU», поки відбувається пейджинг.

Завдання 10: Перевірити NUMA-розміщення і віддалені хіти пам’яті

cr0x@server:~$ numastat -p 12345
Per-node process memory usage (in MBs) for PID 12345 (myservice)
                           Node 0          Node 1           Total
                  --------------- --------------- ---------------
Private                  18240.32         1024.11        19264.43
Heap                      6144.00          512.00         6656.00
Stack                        64.00           64.00          128.00
Huge                         0.00            0.00            0.00

Значення: Більшість пам’яті на Node 0; якщо потоки працюють на Node 1 — ви платите віддалену затримку. Це «стіна пам’яті» в щоденному житті.
Рішення: Прикріпіть CPU і пам’ять через numactl, виправте афініті або переналаштуйте планувальник. NUMA-баги — це баги продуктивності в маскараді «випадковості».

Завдання 11: Знайти топ-споживачів CPU і чи вони витрачають sys time

cr0x@server:~$ pidstat -u -p ALL 1 2 | head -n 12
02:16:10 AM   UID       PID    %usr %system  %CPU  Command
02:16:11 AM     0       842     1.00    12.00 13.00  ksoftirqd/12
02:16:11 AM  1001    12345    48.00     6.00 54.00  myservice
02:16:11 AM     0      2101     0.00     7.00  7.00  nvme_poll_wq

Значення: Важливий %system і ksoftirqd можуть вказувати на тиск переривань (мережа/сховище) більше, ніж чисте застосункове обчислення.
Рішення: Перевірте розподіл IRQ, налаштування NIC/RSS, polling сховища та шляхи з інтенсивними syscall. Іноді «проблема CPU» — це велика кількість роботи ядра.

Завдання 12: Інспектувати IRQ афініті і дисбаланс (гарячі CPU ядра)

cr0x@server:~$ cat /proc/interrupts | head -n 8
           CPU0       CPU1       CPU2       CPU3
  24:   9182736        120        110         98   PCI-MSI 524288-edge      eth0-TxRx-0
  25:       220   8122331        140        115   PCI-MSI 524289-edge      eth0-TxRx-1
  26:       210        160   7341120        130   PCI-MSI 524290-edge      eth0-TxRx-2

Значення: Переривання розподілені по CPU, але якщо бачите, що один CPU отримує майже все — отримаєте гарячі ядра і тротлінг без високої середньої завантаженості.
Рішення: Виправте афініті (irqbalance або вручну), перевірте RSS черги та уникайте прив’язування всіх IRQ до того самого NUMA-нуда, що й ваші найгарячіші потоки, якщо це не навмисно.

Завдання 13: Виявити насичення пропускної здатності пам’яті і біль від промахів кеша (швидкий семпл)

cr0x@server:~$ sudo perf stat -e cycles,instructions,cache-misses,LLC-load-misses -p 12345 -- sleep 10
 Performance counter stats for process id '12345':

     18,220,114,992      cycles
     10,002,332,110      instructions              #    0.55  insn per cycle
        82,110,442      cache-misses
        40,220,119      LLC-load-misses

      10.001201545 seconds time elapsed

Значення: Низький IPC (інструкцій за цикл) плюс багато LLC промахів свідчить, що CPU стоїть у очікуванні пам’яті. Це операційна «стіна пам’яті».
Рішення: Поліпшіть локальність (розмітка даних, стратегія кешування), зменшіть pointer-chasing, батчуйте запити або перемістіть гарячі дані на швидші рівні.
Купівля швидших ядер навряд допоможе.

Завдання 14: Перевірити тиск ZFS ARC, якщо ви використовуєте ZFS (сховище зустрічає стіну пам’яті)

cr0x@server:~$ sudo arc_summary | egrep -i 'ARC Size|ARC Target|Cache Hit Ratio' | head -n 6
ARC Size:                               32.0 GiB
ARC Target Size (Adaptive):             48.0 GiB
Cache Hit Ratio:                        71.2 %

Значення: ARC розмір нижче цілі і посередній процент попадань може означати, що вам бракує пам’яті; запити частіше звертаються до диска, що підвищує латентність і навантаження на CPU.
Рішення: Виділіть більше RAM, налаштуйте ліміти ARC або переробіть робочий набір. Не позбавляйте ARC пам’яті, щоб «зберегти RAM», а потім дивуйтеся, чому диски зайняті.

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

cr0x@server:~$ sudo ipmitool sdr type Temperature | head -n 6
Inlet Temp       | 26 degrees C      | ok
CPU1 Temp        | 92 degrees C      | ok
CPU2 Temp        | 94 degrees C      | ok
Exhaust Temp     | 48 degrees C      | ok

Значення: Впуск нормальний, CPU гарячі, витоку висока. Це вказує на контакт радіатора, криву вентиляторів, забиті фільтри або недостатній повітряний потік через шасі.
Рішення: Інспектуйте фізичний шлях: пил, відмови вентиляторів, перешкоди кабелів. Якщо це патерн по флотилії — перегляньте розташування стійок і температуру впуску.

Завдання 16: Підтвердити обмеження потужності і звітування пакетної потужності

cr0x@server:~$ sudo rdmsr -a 0x610 | head -n 2
00000000d0a8d0a8
00000000d0a8d0a8

Значення: Цей MSR кодує пакетні ліміти потужності (PL1/PL2) на багатьох Intel-системах; raw hex потребує декодування, але узгодженість між CPU вказує на платформене обмеження.
Рішення: Якщо продуктивність обмежена, перевірте BIOS/прошивку і інструменти вендора. У хмарі прийміть це як факт і налаштовуйтеся на perf/watt замість гонитви за уявними GHz.

Жарт №2: Я одного разу пробував розігнати сервер. Працювало доти, поки закони термодинаміки не подали заявку.

Три корпоративні міні-історії від стіни

Міні-історія 1: Інцидент через неправильне припущення (бенчмарки-сплески ≠ стійка реальність)

Середня SaaS-компанія мігрувала latency-sensitive API на нові compute-optimized інстанси. Бенчмарк вендора виглядав чудово.
Їхній внутрішній лоад-тест теж — бо тривав п’ять хвилин і оголосив перемогу.

У продакшені API витримав полуденний сплеск і потім повільно деградував протягом наступної години. p99 повз. Ретраї підсилювали трафік.
Автоскейлер додав ноди, але нові ноди деградували так само, просто з більшими загальними витратами.

Неправильне припущення: «Якщо CPU на 50–60%, ми не CPU-bound». Насправді стійка пакетна потужність штовхнула CPU в стан стабільного тротлінгу; їхній сервіс був
«напівзавантажений», бо проводив час у стані очікування пам’яті і ядра I/O, тоді як турбо-поведінка змінювалася з хвилини в хвилину. Метрика завантаженості була чесною;
ментальна модель — ні.

Виправлення було нудним: вони розширили лоад-тести до принаймні години, відобразили частоту в часі і додали термальні та енергетичні лічильники до дашбордів продуктивності.
Також вони відрегулювали батчування запитів і зменшили виділення пам’яті на запит, знизивши тиск кеша. У результаті кращий p99 і менше енергоспоживання — результат,
який ніхто не ставить на слайд, але який усі хочуть о 02:13.

Міні-історія 2: Оптимізація, що відбилася назад (векторизація зустрічає ліміти потужності)

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

У продакшені ефект на fleet був іншим. При стійкому векторному навантаженні CPU знижували частоту, щоб залишитися в межах потужності і терміки.
«Швидший» код збільшив миттєве споживання потужності, що викликало зниження частоти, що зменшило продуктивність інших потоків, включно з компресією і обробкою мережі.

Симптом був дивним: end-to-end пропуск іноді підвищувався, іноді погіршувався, а хвостова латентність для несуміжних сервісів на загальних нодах страждала.
Платформна команда побачила більше термальних подій і зростання швидкостей вентиляторів. Команда даних отримала шумні KPI і звинуватила мережу.
Усі були напівправі і повністю роздратовані.

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

Міні-історія 3: Нудна, але вірна практика, що врятувала (планування ємності з потужністю і терміками)

Фінансова фірма експлуатувала приватний кластер зі строгими latency SLO. Вони також мали суворий процес змін, який ніхто не любив:
прошивкові базеліни, консистентні BIOS power-настройки і квартальні термальні аудити з відкриванням шасі і чищенням фільтрів.

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

Різниця не була героїчною. Вона полягала в тому, що їхня модель ємності включала запаси по потужності і охолодженню, а не лише ядра CPU і RAM.
Вони трактували «ват на стійку» як ресурс першого класу і тримали термальний запас, щоб турбо-поведінка не перетворилась на лотерею.

Постмортем читався як чек-лист, а не трилер. Ось у чому сенс. Найнадійніші системи рідко захоплюють увагу; вони просто неухильно, майже нав’язливо, добре доглянуті.

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

1) Симптом: латентність піднімається протягом 30–90 хвилин навантаження

Корінь: Нагрів до насичення призводить до стійкого тротлінгу; турбо хороший на початку, поганий пізніше.

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

2) Симптом: «CPU лише 50%», але черги вибухають

Корінь: Потоки застрягають на пам’яті (низький IPC) або блокуються на I/O; завантаженість ≠ пропускна здатність.

Виправлення: Використовуйте perf stat для індикаторів stall, iostat для await пристроїв і усуньте блокування (батчування, локальність, зменшення алокацій).

3) Симптом: два ідентичні хости мають різну продуктивність

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

Виправлення: Нав’язуйте BIOS/мікрокодні базеліни; аудіть IPMI сенсори; фізично інспектуйте і чистіть; валідуйте потік повітря в стійці.

4) Симптом: після «оптимізації» потужність зростає, а пропуск падає

Корінь: Вища активність переключення (векторизація, busy polling, додаткові потоки) тригерить ліміти потужності або терміку, знижуючи частоту.

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

5) Симптом: збереження виглядає «швидким» по пропускній здатності, але p99 жахливий

Корінь: Чергування і write amplification; пристрій насичений (%util високий) і латентність роздувається.

Виправлення: Сфокусуйтеся на await/aqu-sz, зменшіть дрібні випадкові записи, додайте пристрої або змініть шлях запису (батч, log-structured, async).

6) Симптом: випадкові мікросплески латентності без явного стрибка CPU

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

Виправлення: Перевірте /proc/interrupts, налаштуйте афініті IRQ/RSS, розгляньте isolcpus для галасливих пристроїв і валідуйте поведінку ksoftirqd.

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

Корінь: Спільна пропускна здатність пам’яті і контенція LLC; більше потоків збільшує інтерференцію.

Виправлення: Обмеження потоків, NUMA-усвідомлене розміщення, зменшення спільних «гарячих» даних і використання лімітів конкурентності замість необмеженої паралельності.

8) Симптом: хмарні інстанси одного типу поводяться непослідовно

Корінь: Управління потужністю на рівні хоста, різне базове кремнієве устаткування/степінги або потужні сусіди.

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

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

Коли продуктивність падає після апаратного оновлення

1. Базуйте стійку поведінку: запустіть 60–120-хвилинний лоад-тест; фіксуйте частоту, температуру і пакетну потужність у часі.
2. Підтвердіть політику: governor CPU/EPP, налаштування турбо, профіль BIOS power і квоти cgroup.
3. Перевірте терміки фізично: температура впуску/витоку, RPM вентиляторів, пил, перешкоди кабелів, прилягання радіатора.
4. Перевірте поведінку пам’яті: IPC, LLC промахи, активність swap, локальність NUMA.
5. Перевірте черги I/O: per-device await і завантаженість, writeback файлової системи, повторні передачі мережі.
6. Повторний тест: змінюйте лише одну велику змінну одночасно; інакше ви «виправите» випадково.

Коли підозрюєте термальний тротлінг у флотилії

1. Виберіть три хости: кращий, середній, найгірший.
2. Зберіть: turbostat (або еквівалент), температури ipmitool, теплові події dmesg.
3. Порівняйте: стійкі Avg_MHz під однаковим навантаженням; шукайте різниці температур і енергетичні капи.
4. Дійте: якщо локалізовано — виправте повітряний потік і апаратне обслуговування; якщо системно — перегляньте ліміти потужності і розміщення навантажень.

Коли вам потрібна передбачувана латентність (не лише піковий швидкість)

1. Надавайте перевагу стабільності перед піком: тонкуйте для послідовної частоти, а не для сплесків турбо.
2. Встановіть ліміти конкурентності: не дозволяйте необмеженій паралельності створювати контенцію пам’яті й I/O.
3. Мінімізуйте промахи кешу: зменшуйте алокації, покращуйте локальність, уникайте pointer-heavy hot paths.
4. Робіть I/O банальним: батчуйте записи, використовуйте backpressure і тримайте черги пристроїв короткими.
5. Інструментуйте терміки: трактуйте температуру і події тротлінгу як продакшен-сигнали.

FAQ

1) Чи є теплова стіна причиною того, що одноядерна швидкість перестала зростати?

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

2) Чому бенчмарки показують чудову швидкість, а в продакшені повільніше?

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

3) Якщо мій CPU не на 100%, чи може він усе одно бути вузьким місцем?

Абсолютно. Ви можете бути обмежені затримкою пам’яті, блокуваннями або I/O, в той час як CPU виглядає помірно завантаженим. Дивіться IPC, промахи кеша,
чергу виконання і await пристроїв.

4) Чи завжди допомагає «більше ядер»?

Ні. Більше ядер може збільшити контенцію за пропускну здатність пам’яті і LLC, а також підвищити потужність/тепло, викликаючи тротлінг. Масштабуйте ядра з урахуванням локальності і пропускної здатності.

5) У чому різниця між термальним тротлінгом і обмеженням потужності?

Термальний тротлінг реагує на температурні пороги; обмеження потужності застосовує обмеження ватності пакета/платформи (часто PL1/PL2). Обидва знижують частоту;
виправлення залежить від того, яке з них ви вдарили.

6) Як турбо-режими змінюють оперування?

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

7) Чи можуть проблеми зі сховищем спричинити нагрів і тротлінг CPU?

Так. Високі I/O-рати можуть викликати переривання, роботу ядра, шифрування/контрольні суми і копіювання пам’яті. Це спалює потужність, поки ваш додаток «чекає»,
і може дестабілізувати поведінку турбо.

8) Що потрібно моніторити, щоб раніше помітити теплову стіну?

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

9) Чи є рідинне охолодження вирішенням?

Це інструмент, а не лікування. Рідинне охолодження може збільшити запас і щільність, але ваше навантаження все одно може вдаритися в ліміти потужності,
стіни пам’яті або контенцію I/O. Все ще потрібна ефективність.

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

Зменшіть марну роботу: покращте локальність, скоротіть алокації, батчуйте I/O, обмежте конкурентність і усуньте блокування. Продуктивність на ват —
новий «GHz».

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

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

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

• Додайте стійку частоту, температуру і події тротлінгу у стандартні хост-дашборди.
• Розширте тести продуктивності, щоб включати теплове насичення. Якщо тест менше 30 хвилин — це демонстрація, а не тест.
• Виробіть звичку: коли латентність росте — перевіряйте тротлінг і черги перш ніж змінювати код.
• Для задач пропускної здатності оптимізуйте під продуктивність на ват: локальність, батчування, менше stall-ів, менше викликів ядра.
• Зробіть базеліни флотилії нудними: консистентні BIOS-настройки, мікрокод, криві вентиляторів і фізичне обслуговування.

Ви не переможете фізику. Ви бюджетуєте її, інструментуєте її і проектуєте навколо неї. Це не песимізм. Це продакшен.