Чому процесори гріються: Turbo, обмеження потужності та реальність

December 22, 2025 • February 3, 2026 • Читання: 4 хв • Views: 0

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

Ви придбали «CPU 125W», а він тягне 230W, близько 100°C, і ваш моніторинг думає, що кімната горить. Тим часом навантаження — це «лише» збірка, vacuum у базі даних або вузол Kubernetes, який мав бути нудним.

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

Процесори навмисно гріються

Сучасні процесори не «втікають». Вони роблять саме те, для чого їх спроектували: перетворювати тепловий та електричний запас у продуктивність, а потім відступати в той момент, коли з’являється обмеження. Це й є суть поведінки turbo boost у Intel та AMD, для десктопів і серверів, ноутбуків та робочих станцій.

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

Якщо ви працюєте у продакшені, перестаньте ставитися до температури CPU як до простого індикатора стану. Температура — це змінна керування для підвищення продуктивності. Процесор при 95°C може бути здоровим і швидким; процесор при 70°C може бути нездоровим і тротлити через обмеження потужності або струму. Цікаве питання не «наскільки гарячо», а «яке обмеження активне і чи відповідало воно нашим намірам»?

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

TDP перетворився з інженерної характеристики в маркетинговий ярлик. Ранній «thermal design power» був призначений для підбору охолодження за базових умов, а не як «максимальна потужність, яку чіп коли-небудь споживатиме».
Intel Turbo Boost (поширився близько 2008 року) зробив потужність CPU динамічною. Частота стала функцією запасу, а не статичною властивістю SKU.
Інструкції AVX змінили гру. Потужні векторні обчислення можуть спричиняти сплески щільності потужності й запускати інші правила турбо або зсуви в порівнянні зі скалярним кодом.
Ера Zen у AMD нормалізувала «температуру як ціль». Багато Ryzen-чипів охоче їдуть до термальної межі під час буста, бо так побудовано контур керування.
Дата-центри штовхнули вендорів до короткочасних сплесків. Пікова продуктивність продає бенчмарки; сталу продуктивність ви повинні забезпечити самі, якщо не встановите обмеження.
Норм технологічного вузла зменшився, але щільність потужності не зникла. Менші транзистори можуть означати більше тепла на квадратний міліметр, а не менше.
Раніше сервери були «про повітряний потік насамперед». Високий статичний тиск вентиляторів і повіт проводилися по повітропроводах; споживчі корпуси оптимізовані під тишу та естетику.
Мікропрограмне управління потужністю стало центральною частиною поведінки платформи. CPU не сам по собі — обмеження VRM материнської плати та BIOS за замовчуванням можуть сильно змінити, як «125W» поводиться.

Цитата, яку слід прикріпити на моніторі опсів (перефразована ідея): «Сподівання — не стратегія.» — у термінах SRE: вимірюйте або будете гадати.

Жарт №1: Процесор при 100°C не «панікує», він «максимізує цінність акціонерів». На жаль, ви — ці акціонери.

Turbo, PL1/PL2/Tau і пастка «TDP»

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

Базовий контур керування: продуктивність ганяється за обмеженнями

Сучасні процесори безперервно обирають частоту та напругу на підставі:

Обмеження по температурі (TjMax, зазвичай близько 95–105°C залежно від моделі)
Обмеження по потужності (Intel: PL1/PL2 з вікном часу Tau; AMD: PPT/TDC/EDC і правила PBO)
Обмеження по електричному струму (здатність VRM, обмеження роз’єма)
Захист надійності (моделі старіння кремнію, сенсори гарячих точок)
Класифікація навантаження (AVX, ширина векторів, завантаження ядра, короткочасні стрибки)

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

Мова Intel: PL1, PL2, Tau

На багатьох платформах Intel:

PL1: довготривале обмеження потужності. Думайте «стандартний бюджет».
PL2: короткочасне обмеження турбо. Думайте «сплеск». Часто значно вищий за PL1.
Tau: вікно часу (в секундах), протягом якого дозволено PL2 перед поверненням до PL1.

На практиці багато плат материнської плати виходять з лояльними налаштуваннями: високий PL2 і довгий Tau або фактично «необмежено» в межах розумного. Ось чому ви можете бачити «125W» CPU, що сидить при 200W довго — бо виробник материнської плати вирішив, що продаж бенчмарків важливіший за стримане теплове середовище.

Мова AMD: PPT, TDC, EDC і PBO

Поведінку буста AMD часто описують через:

PPT: package power tracking (обмеження загальної потужності сокета)
TDC: стійке обмеження струму
EDC: короткочасне обмеження струму
PBO: Precision Boost Overdrive (керуючі параметри для послаблення обмежень, якщо дозволяють терміка та VRM)

AMD схильна трактувати температуру як орієнтир: вона піднімає тактові частоти, поки не наблизиться до термальної цілі (або не досягне обмежень потужності/струму). Ось чому «він завжди доходить до 95°C» не обов’язково «погано», особливо на невеликих кулерах або в компактних корпусах. Питання в тому: чи отримуєте ви стабільну передбачувану продуктивність, чи система осцилює й тротлить під тривалим навантаженням?

Пастка TDP у термінах експлуатації

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

Натомість плануйте навколо стійкої пакетної потужності під вашим реальним навантаженням, з вашими реальними BIOS-налаштуваннями, у вашому реальному шасі, при вашій реальній температурі в приміщенні й реальному рівні пилу через шість місяців. Це не романтично, але так ви уникнете дзвінків у вихідні.

Цільові температури і чому 95–100°C «нормально»

Є дві різні розмови, які люди плутають:

Чи безпечне кремнієве ядро? Зазвичай так, до заявленої максимальної температури переходу (TjMax). CPU буде знижувати частоту, щоб себе захистити.
Чи система працює передбачувано? Тут ви можете втратити гроші. Тротлінг, шум вентиляторів і стрибки частоти перетворюють передбачуваний вузол на хаотичний.

Вендори не вибрали 95–100°C заради драматизму. Вони обрали це, бо більший температурний коридор дозволяє видавати вищі буст-частоти в обмеженому енергетично/площинному інтервалі, а внутрішні сенсори й контури керування достатньо точні, щоб безпечно працювати близько до грані.

Термальний тротлінг vs тротлінг по потужності vs тротлінг по струму

«Тротлінг» — загальний термін. Потрібно розрізняти:

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

Кожен із цих випадків має різне рішення. Перепакування кулера не виправить обмеження потужності. Підняття лімітів потужності не вирішить криво встановлений кулер. А підняття лімітів, щоб «виправити продуктивність», може тихо дестабілізувати стійки, якщо ваші PDU й повітряний потік не пристосовані.

Реальність охолодження: контакт, повітряний потік і фізика корпусу

Температура CPU в панелі моніторингу — останнє ланка в ланцюгу. Ланцюг починається в кристалі, проходить через heat spreader, через термопасту, у підставу кулера, у ребра радіатора, у повітря корпусу, у повітря приміщення і нарешті в систему кондиціювання.

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

Найпоширеніші реальні винуватці

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

Жарт №2: «Поставимо більший кулер» — апаратний варіант «просто додайте повторні спроби». Працює, поки не перестає працювати.

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

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

Спочатку: підтвердьте, що симптом реальний (не артефакт сенсора/телеметрії)

Перевірте температуру CPU і частоту під відомим навантаженням.
Перехресно перевірте принаймні двома інструментами (ядрові сенсори + вендорний інструмент або MSR-інструмент).
Підтвердіть, що навантаження — те, що ви думаєте (одна гаряча нитка проти всіх ядер).

По-друге: визначте активний обмежувач

Шукайте прапорці термального тротлінгу й падіння частоти, що корелюють з температурним лімітом.
Перевірте пакетну потужність і обмеження потужності (PL1/PL2/Tau або PPT/TDC/EDC).
Перевірте обмеження струму/VRM і сенсори платформи (VRM, температура на вході).

По-третє: вирішіть, чи виправляти охолодження, політику потужності чи навантаження

Якщо термально-обмежено: покращіть контакт, повітряний потік, криву вентиляторів або зменшіть напругу/потужність.
Якщо обмежено по потужності: вирішіть, чи хочете сталу продуктивність (підняти PL1/PPT), чи передбачувану терміку (знизити PL2/Tau або задати кап на частоту).
Якщо тригерить навантаження: ідентифікуйте AVX-важкі ділянки коду, ліміти контейнера, pinning планувальника та «гучних сусідів».

Цей порядок важливий. Люди люблять починати з BIOS, бо так відчувають контроль. Починайте з спостереження, потім з політики. Апаратне забезпечення не переймається вашими почуттями.

Практичні задачі (команди, виводи, що це означає, що вирішуєте)

Ці кроки призначені для Linux-серверів і робочих станцій. Деякі вимагають пакетів (як lm-sensors, linux-tools), але команди реалістичні й звичні у робочих рукописах.

Задача 1: Побачити поточну поведінку частоти CPU (чи буститься, чи зафіксовано?)

cr0x@server:~$ lscpu | egrep 'Model name|CPU\\(s\\)|Thread|Core|Socket|MHz'
Model name:                           Intel(R) Xeon(R) CPU
CPU(s):                               32
Thread(s) per core:                   2
Core(s) per socket:                   16
Socket(s):                            1
CPU MHz:                              1198.523

Що це означає: Рядок «CPU MHz» — знімок і може вводити в оману на сучасних системах. Якщо він ніколи не піднімається під навантаженням, можливо, ви закриті низьким governor або енергетичним капом.

Рішення: Якщо частота здається низькою, переходьте до моніторингу по ядрах (Задача 2) і перевірте governor (Задача 3).

Задача 2: Дивитися частоту по ядрам, температуру й прапорці тротлінгу (Intel)

cr0x@server:~$ sudo turbostat --Summary --quiet --interval 2
     CPU     Avg_MHz   Busy%   Bzy_MHz   TSC_MHz  PkgTmp  PkgWatt
       -        4123   92.15      4473      2500      98   212.34
     IRQ        1020

Що це означає: Високий Busy% і висока PkgTmp поруч із межею з високою PkgWatt вказують, що CPU використовує потужність турбо. Якщо PkgTmp досягає 100 і Bzy_MHz падає, ймовірно, ви маєте термальний тротлінг.

Рішення: Якщо PkgTmp близько до максимуму, перевірте індикатори термального тротлінгу (Задача 4) і шлях охолодження. Якщо PkgWatt високий, підтвердьте PL1/PL2 (Задача 5).

Задача 3: Підтвердити scaling governor CPU (випадково у «powersave»?)

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

Що це означає: performance просить вищі частоти. powersave або політика платформи може вас капати.

Рішення: Якщо не performance (або не ваша очікувана політика), змініть через інструменти дистро або tuned-профілі. Якщо правильно, дивіться на обмеження потужності/терміки.

Задача 4: Перевірити лічильники термального тротлінгу ядра (Intel MSR в sysfs на деяких платформах)

cr0x@server:~$ grep . /sys/devices/system/cpu/cpu*/thermal_throttle/* 2>/dev/null | head
/sys/devices/system/cpu/cpu0/thermal_throttle/core_throttle_count:3
/sys/devices/system/cpu/cpu0/thermal_throttle/package_throttle_count:8

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

Рішення: Якщо лічильники тротлінгу зростають, розглядайте це як проблему охолодження/політики потужності, а не як «CPU стає повільним» таємницю. Покращуйте охолодження або зменшуйте потужність (Задачі 11–12).

Задача 5: Прочитати Intel RAPL обмеження потужності (PL1/PL2) якщо доступні

cr0x@server:~$ sudo cat /sys/class/powercap/intel-rapl:0/constraint_0_power_limit_uw
125000000
cr0x@server:~$ sudo cat /sys/class/powercap/intel-rapl:0/constraint_1_power_limit_uw
225000000

Що це означає: Constraint 0 зазвичай — стійкий ліміт (аналог PL1), а constraint 1 — короткочасний ліміт (аналог PL2). Тут: 125W стійко, 225W турбо.

Рішення: Якщо PL2 величезний і терміка проблема, зменшіть PL2 або скоротіть Tau (BIOS або інструменти платформи). Якщо продуктивність занадто низька, можливо, потрібно підняти PL1 — але лише якщо ваше охолодження та живлення можуть це витримати.

Задача 6: Перевірити сенсори температури CPU (загальні)

cr0x@server:~$ sensors
coretemp-isa-0000
Adapter: ISA adapter
Package id 0:  +97.0°C  (high = +90.0°C, crit = +100.0°C)
Core 0:        +95.0°C  (high = +90.0°C, crit = +100.0°C)
Core 1:        +96.0°C  (high = +90.0°C, crit = +100.0°C)

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

Рішення: Корелюйте температури з частотою та потужністю (Задачі 2 і 5). Якщо температури високі при помірній потужності, підозрівайте монтаж/повітряний потік.

Задача 7: Підтвердити навантаження — однопоточне чи багатопоточне

cr0x@server:~$ top -b -n1 | head -15
top - 12:20:18 up 41 days,  3:10,  1 user,  load average: 23.41, 18.92, 12.10
Tasks: 412 total,   2 running, 410 sleeping,   0 stopped,   0 zombie
%Cpu(s): 92.7 us,  2.1 sy,  0.0 ni,  4.8 id,  0.2 wa,  0.0 hi,  0.2 si,  0.0 st
PID USER      PR  NI    VIRT    RES    SHR S  %CPU  %MEM     TIME+ COMMAND
8421 build     20   0 2451280 512404  23344 R  3200  3.1  18:01.22 clang

Що це означає: Один процес, що споживає ~3200% CPU на системі з 32 потоками, вказує на широку паралельність. Це змінює поведінку буста: турбо для всіх ядер нижчий, ніж для 1–2 ядер, і пакетна потужність швидко зростає.

Рішення: Якщо це «нормально», встановіть реалістичні цілі стійкої потужності/охолодження. Якщо несподівано, знайдіть, чому працює це завдання (помилка CI, runaway thread pool, перехресні cron-запуски).

Задача 8: Перевірити, чи ви I/O-заблоковані (звинувачують CPU, але вузьке місце в іншому)

cr0x@server:~$ iostat -xz 2 3
avg-cpu:  %user   %nice %system %iowait  %steal   %idle
          35.20    0.00    4.10   42.30    0.00   18.40

Device            r/s     w/s   rkB/s   wkB/s  avgrq-sz avgqu-sz   await  svctm  %util
nvme0n1         220.0   180.0  50240   38912     390.4      8.12   18.21   1.05  42.00

Що це означає: Високий iowait означає, що CPU-цикли не є обмежувальним фактором; система чекає на сховище. Гарячі CPU все ще можуть бути (фонові стрибки турбо), але часто «CPU гарячий — отже CPU винен» — помилкове твердження.

Рішення: Якщо iowait високий, спочатку вирішуйте латентність/черги дискової підсистеми. Інакше ви налаштуєте обмеження CPU, щоб приховати проблему I/O і все одно пропустите SLO.

Задача 9: Перевірити ліміти CPU у контейнерах або тротлінг Kubernetes (виглядає як термальний тротлінг, але це cgroups)

cr0x@server:~$ cat /sys/fs/cgroup/cpu.max 2>/dev/null || cat /sys/fs/cgroup/cpu/cpu.cfs_quota_us
200000 100000

Що це означає: Цей приклад — квота 200ms CPU на 100ms період, фактично 2 CPU. Якщо ваше навантаження очікує 8 ядер, воно буде «тротлитися», незалежно від температури.

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

Задача 10: Помітити AVX-важку поведінку побічно через сплески потужності й падіння частоти

cr0x@server:~$ sudo perf stat -a --timeout 5000 2>&1 | head -12
 Performance counter stats for 'system wide':

       120,345,882,112      cycles
        65,112,004,331      instructions              #    0.54  insn per cycle
             2,114,220      context-switches
                12,804      cpu-migrations

Що це означає: Низький IPC під важкими обчисленнями може корелювати з векторним кодом, затримками пам’яті або тротлінгом. perf тут не скаже «AVX», але в парі з turbostat, що показує великі ватти й нижчі тактові, AVX — типовий підозрюваний.

Рішення: Якщо це корелює з передбачуваними навантаженнями (сжаття, крипто, ML inference), розгляньте політики частот для AVX, капи потужності або перенос цього навантаження на вузли, підготовлені для нього.

Задача 11: Перевірити RPM вентиляторів і стан повітряного потоку (сервери з IPMI)

cr0x@server:~$ sudo ipmitool sdr type Fan
FAN1             | 8600 RPM        | ok
FAN2             |  900 RPM        | cr
FAN3             | 8700 RPM        | ok

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

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

Задача 12: Підтвердити температуру на вході/навколишню температуру (ваше «охолодження» може бути проблемою кімнати)

cr0x@server:~$ sudo ipmitool sensor | egrep -i 'Inlet|Ambient|Temp' | head
Inlet Temp       | 29 degrees C     | ok
Ambient Temp     | 30 degrees C     | ok
CPU1 Temp        | 96 degrees C     | ok

Що це означає: Inlet 29–30°C не катастрофа, але зменшує ваш тепловий запас. Якщо раніше CPUs сиділи при 80°C, а тепер при тому ж навантаженні досягають 96°C, перевірте кімнату та containment повітря.

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

Задача 13: Виявити причини тротлінгу на вузлах з NVIDIA GPU (бо скарги на тепло CPU часто на змішаних вузлах)

cr0x@server:~$ nvidia-smi -q | egrep -i 'Power Limit|Clocks Throttle Reasons' -A5
    Power Limit                      : 300.00 W
    Clocks Throttle Reasons
        Idle                         : Not Active
        Applications Clocks Setting   : Not Active
        SW Power Cap                 : Active
        HW Thermal Slowdown          : Not Active

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

Рішення: Координуйте бюджети потужності CPU/GPU. Уникайте «вирішення CPU» ізольовано, коли політика ліміту потужності на рівні вузла — справжня причина.

Задача 14: Виявити невірні налаштування BIOS через dmesg (термальні зони, доступність RAPL, підказки мікрокоду)

cr0x@server:~$ dmesg | egrep -i 'microcode|rapl|thermal|throttl' | tail -10
microcode: updated early to revision 0x2f, date = 2023-08-10
intel_rapl_common: Found RAPL domain package
thermal thermal_zone0: failed to read out thermal zone (-61)

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

Рішення: Виправте видимість спочатку (оновлення прошивки, параметри ядра, правильні драйвери). Не налаштовуйте те, чого не бачите.

Три міні-історії з корпоративного життя

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

Компанія розгорнула партію «високопродуктивних раннерів збірки» для CI. У специфікації закупівлі було вказано, що CPU — 125W. Команда інфраструктури розрахувала енергопотребу і охолодження під це. Всі почувалися відповідальними. Всі помилилися в одному напрямку, так і народжуються відмови.

Перші дні пройшли чудово. Збірки були швидшими, розробники раділи, раннери здавалися стабільними. Потім вийшов реліз і обсяг CI подвоївся. Флот раннерів перейшов від «сплесків» до «стійкого all-core». Пакетна потужність зросла значно вище за 125W на більшості вузлів, вентилятори завили, і кластер почав поводитися так, ніби у нього проблеми з мережею.

Мережа не була проблемою. CPU сильно термально тротлили, і вузли осцилювали: буст → нагрів → тротлінг → охолодження → буст. Латенції зросли в усіх невідповідних місцях: завантаження артефактів, вилучення кешу, навіть SSH-сесії для діагностики. Люди інтерпретували симптоми як «мережа перевантажена», бо саме так виглядає повільне.

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

Неправильне припущення було не в тому, що «CPU гріється». Вони вважали, що «TDP — це максимум». Коли це припущення прибрали, система стала передбачуваною — як і має бути з самого початку.

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

Інша команда розгорнула latency-sensitive сервіси на загальних вузлах. Вони хотіли стабільної продуктивності й вирішили «прибити всі в performance mode» по флоту: governor у performance, дозволити максимум турбо і агресивні P-state. На папері виглядало правильно. Менше переходів частоти, менше сплесків хвостової латенції. Просте рішення.

Тиждень метрики покращилися. Потім прийшло літо і температура входу в дата-центр піднялася на пару градусів. Нічого драматичного. Все ще «в межах специфікації». Але вузли тепер мали менше теплового запасу. Постійно увімкнена висока частота тримала середню пакетну потужність вищою навіть при помірному навантаженні. Криві вентиляторів реагували запізніло. Температури CPU весь день їхали ближче до ліміту.

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

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

Оптимізація, що ігнорує варіацію середовища — не оптимізація. Це інцидент із добрими намірами.

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

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

Під час рутинного оновлення апаратури нова партія вузлів показувала трохи кращі бенчмарки в burn-in від постачальника. Усі очікували перемоги. Чекліст команди зафіксував інше: під 30-хвилинним стрес-раном пакетна потужність залишалася підвищеною значно довше, ніж очікувалося, а температури висіли біля термальної межі.

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

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

Нудна, повторювана валідація краще за героїчне налаштування. Кожного разу.

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

Ось шаблони, що з’являються в реальних каналах інцидентів: впевнені твердження, неправильна діагностика, повільне вирішення.

1) Симптом: CPU миттєво досягає 100°C під навантаженням

Корінь: Проблема контакту кулера (тиск кріплення, відсутній стовпчик, захисна плівка на місці, висохла паста).

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

2) Симптом: Температура нормальна (70–80°C), але продуктивність низька і частоти обмежені

Корінь: Тротлінг по потужності (низький PL1/PPT) або квота cgroup.

Виправлення: Перевірте RAPL/BIOS-ліміти і квоти cgroup. Піднімайте стійкі ліміти тільки якщо охолодження й бюджет живлення вузла це витримають.

3) Симптом: Продуктивність осцилює кожні 10–60 секунд

Корінь: Поведінка вікна Tau або гістерезис кривої вентиляторів, що викликає цикли boost/throttle; також можливе термальне циклювання VRM.

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

4) Симптом: Один вузол гарячіший за ідентичні вузли

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

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

5) Симптом: Після оновлення мікрокоду/BIOS CPU стали гарячішими

Корінь: Прошивка змінила політику буста або за замовчуванням ліміти потужності. Іноді «патчі безпеки» косвенно змінюють продуктивність/енергоспоживання.

Виправлення: Пере-перевірте PL1/PL2/PPT після оновлень прошивки. Зберігайте базовий знімок turbostat/sensors під фіксованим навантаженням для порівняння.

6) Симптом: Перегріваються тільки певні навантаження (сжаття, крипто, ML), інші ні

Корінь: Векторні/AVX-важкі ділянки коду підвищують щільність потужності; також можливе використання всіх ядер при високій завантаженості.

Виправлення: Розгляньте розміщення навантаження (виділені вузли), налаштуйте капи потужності або прийміть нижчий all-core turbo. Не підбирайте охолодження за «середнім» поведінкою застосунку.

7) Симптом: Ряд дата-центру «в межах специфікації», але тротлінг зростає по жарких післяобідах

Корінь: Зменшився тепловий запас через підвищення Inlet; проблеми containment; відсутні заглушки; рециркуляція.

Виправлення: Усуньте проблему управління повітряним потоком і порядок у стійці. Використовуйте сенсори Inlet як першу чергу телеметрії і ставте оповіщення на дрейф, а не лише на абсолютні пороги.

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

Покроково: зробіть терміку CPU передбачуваною (не обов’язково холоднішою)

Визначте мету. Цей вузол налаштовано на пропускну здатність, латентність чи акустику? Виберіть одну основну ціль; інші — обмеження.
Зніміть базу під фіксованим тривалим навантаженням. Зафіксуйте пакетну потужність, температуру, частоту й лічильники тротлінгу.
Перевірте видимість і коректність сенсорів. Якщо сенсори відсутні або пошкоджені, зупиніться й виправте це спочатку.
Визначте тип тротлінгу. Термальний vs потужність vs cgroups. Діагностуйте перед тим, як крутити ручки.
Встановіть політику стійкої потужності. Виберіть PL1/PPT, яке ваше охолодження справді може витримати при найгіршій Inlet.
Встановіть політику сплеску свідомо. PL2/Tau повинні відображати «сплесковість» ваших навантажень. CI і компакції — це не «сплески».
Перевірте здоров’я повітряного потоку. RPM вентиляторів, фільтри, повітропровід, заглушки і укладання кабелів.
Знову прогоніть те саме навантаження. Шукайте стабільність: жодної пилкоподібної частоти, жодного поступового зростання температур.
Розгорніть з запобіжними заходами. Сповіщайте про лічильники тротлінгу, а не лише про температуру. Температура сама по собі дає неповну картину.
Повторно валідуйте після змін. Оновлення BIOS, ядра та переміщення шасі змінюють поведінку.

Операційний чекліст: на що ставити оповіщення

Збільшення лічильників термального тротлінгу (по ядру та по пакету) під нормальними вікнами навантаження.
Стійка частота нижча за очікувану all-core при високій завантаженості.
Дрейф Inlet температури відносно бази для конкретного стелажа/ряду.
Аномалії вентиляторів: один вентилятор низький RPM, вентилятор в стані «cr» або PWM вентилятор зафіксований постійно.
Аномалії пакетної потужності: вузли споживають значно більше енергії, ніж одноподібні вузли при подібному навантаженні.

FAQ

1) Чи безпечно 95–100°C для мого CPU?

Зазвичай так, якщо це в межах заявленого TjMax і CPU поводиться нормально (немає крашів, WHEA-штормів, вимкнень). Безпечно не означає оптимально. Якщо ви тротлите, ви платите за продуктивність, якої не отримуєте.

2) Чому мій «125W» CPU тягне 200W?

Бо TDP — не «максимальне споживання», і тому що прошивка може дозволяти тривалий турбо (PL2 і Tau або політики PBO). Багато материнських плат виходять з агресивними дефолтами.

3) Чи варто відключити турбо, щоб виправити нагрів?

Як крайню міру або тимчасове пом’якшення — так. Але відключення турбо — грубий інструмент. Краще задати розумні стійкі ліміти (PL1/PPT) та розумний сплеск (PL2/Tau). Часто ви отримаєте кращу загальну пропускну здатність, запобігши осциляціям.

4) Чому оновлення BIOS змінило мої температури?

Оновлення BIOS можуть змінити мікрокод, таблиці буста, дефолтні ліміти потужності, логіку керування вентиляторами та калібрування сенсорів. Трактуйте оновлення прошивки як зміну продуктивності: зробіть базу до та валідуйте після.

5) Мій CPU холодний, але продуктивність все ще погана. В чому причина?

Типові причини: тротлінг по потужності, квота cgroup, конкуренція за пропускну здатність пам’яті або I/O waits. Температура — не універсальний індикатор вузького місця. Перед тим як перемазати пастою, перевірте ліміти потужності й iowait.

6) Чи має значення краща термопаста на серверах?

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

7) Чи AIO рідинні кулери — це відповідь?

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

8) Чому температура CPU миттєво стрибає, а потім стабілізується?

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

9) Який найкращий одиночний метрик для оповіщення?

Якщо можна вибрати лише один, оповіщайте про події термального тротлінгу (зростання лічильників) під звичайним навантаженням. Це ближче до «вам відмовлено в продуктивності», ніж сирі температурні значення.

10) Чи може undervolting допомогти?

Може зменшити потужність і тепло при тій же продуктивності, але на багатьох платформах це все складніше, і є ризик нестабільності при агресивному undervolt. В продакшені віддавайте перевагу підтримуваним вендором лімітам потужності й валідації BIOS-профілів замість індивідуальних undervolt-експериментів на вузлах.

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

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

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

Зробіть базову зйомку одного репрезентативного вузла під тривалим навантаженням з turbostat і sensors; зафіксуйте частоту, температуру і пакетну потужність разом.
Визначте вашу ціль стійкої потужності (PL1/PPT) на основі того, що ваше шасі та кімната можуть охолодити при найгіршому Inlet.
Встановіть свідомо поведінку сплесків (PL2/Tau або політика PBO), щоб уникнути пилкоподібного тротлінгу.
Оповіщайте про лічильники тротлінгу, аномалії вентиляторів і дрейф Inlet — не лише «температура CPU > 90°C».
Задокументуйте BIOS-профіль як production-політику. Ставте його як конфігурацію, бо це й є конфіг.

Вам не потрібні холодніші CPU. Вам потрібні передбачувані CPU. Передбачувані — це те, як ви спите.