PL1, PL2 і Tau пояснено: три числа, що вирішують усе

Ментальна модель: потужність, час і «чому ж воно сповільнилося?»

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

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

У продукційних системах ці числа проявляються як:

• Запити починаються швидко, потім хвостова латентність росте після кількох секунд тривалого навантаження.
• Пакетні задачі показують «пилкоподібну» криву пропускної здатності: буст, обмеження, відновлення, повтор.
• Два «ідентичні» сервери працюють по-різному, бо один виробник плати вирішив творчо трактувати «за замовчуванням».
• Покращення охолодження не допомагає так, як очікувалося, бо система обмежена потужністю, а не теплом.

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

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

PL1, PL2, Tau: визначення, які можна використовувати в кризовій кімнаті

PL1: довготривале обмеження потужності (стандартний режим)

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

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

PL2: короткочасне обмеження потужності (спурт)

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

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

Tau: часове вікно (скільки триває PL2)

Tau — це часовий коефіцієнт/вікно, яке контролює, як довго процесор може перевищувати PL1 до PL2, перш ніж має приборкати себе.
На практиці багато платформ реалізують це як ковзне середнє споживаної потужності за часове вікно.
Якщо середня потужність за цей інтервал перевищує PL1, процесор знижує частоту, щоб повернути середнє назад.

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

Ще одне визначення, яке ви зустрінете: «без обмежень»

Деякі BIOS і інструменти постачальників ноутбуків пропонують «без обмежень» для PL2 або дуже великий Tau. Це зазвичай означає «доки щось інше не зреагує»,
а не «назавжди». Щось інше — це, зазвичай, температура, ліміти струму VRM, ліміти температури корпуса або платформи.
«Без обмежень» чудово під бенчмарки і жахливо для передбачуваних систем.

Як CPU застосовують обмеження (і чому це здається персональним)

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

Ієрархія застосування відрізняється за поколінням та вендором, але зазвичай ви побачите:

• Обмеження за потужністю: пакувальна потужність перевищує PL1/PL2 (часто звітується як «PL1/PL2» або «Power Limit»).
• Термальне тротлінг: температура наближається до TJmax; процесор знижує частоту, щоб залишатися під тепловою межею.
• PROCHOT: сигнал «processor hot» — може бути ініційований процесором або платформою; сильно тротлить.
• Ліміти струму/VRM: VRM материнської плати не може безпечно подати потрібний струм; подача живлення стає обмеженням.
• Платформні ліміти: EC ноутбука контролює бюджети батареї/адаптера; сервери контролюють ліміти стійки.

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

Одна цитата, бо це все ще найкраща порада в операціях. Джин Кранц, директор польотів НАСА, сказав:
«Твердо й компетентно.»
У світі обмежень потужності «твердо» означає не панікувати і не бездумно міняти налаштування; «компетентно» — вимірювати перед тим, як крутити ручки.

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

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

Підвищення PL1 збільшує тривалу продуктивність, якщо (і тільки якщо) раніше CPU був обмежений по потужності під вашим стійким навантаженням.
Це також збільшує постійне теплове навантаження. Якщо ваш кулер і повітряний потік шасі не можуть відвести це тепло, ви просто обміняєте
обмеження за потужністю на термальне тротлінг. Це не апгрейд; це інший тип мук.

Підвищення PL2: швидші спалахи, потенційно гірша стабільність при імпульсних навантаженнях

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

Зміна Tau: контролює час «обриву»

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

Зниження лімітів: недооцінений крок

У продакшні зниження PL2 і/або PL1 може підвищити передбачуваність, зменшити шум вентиляторів (так, це важливо в офісах і лабораторіях),
і тримати системи в межах бюджетів потужності стійки. Це особливо корисно в щільних розгортаннях, де один вузол на повному турбо
може підштовхнути гілку PDU до небезпечних меж.

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

Де їх встановлювати важливо: BIOS проти ОС проти інструментів вендора

Ви можете встановлювати обмеження в BIOS/UEFI, через інтерфейси ОС (RAPL на Intel, профілі платформи, powercap) або через демонів вендора.
BIOS зазвичай найстабільніший і найменш здивовує. Керування з ОС потужне, але легше відхилитися через оновлення або конфігурацію.
Інструменти вендора часто непрозорі і інколи «допомагають», як дитина, що допомагає вам готувати.

Цікаві факти та коротка історія

• Обмеження потужності стали масовими, коли турбо стало масовим. Turbo boost створив потребу в явних, виконуваних бюджетах понад «TDP».
• RAPL з’явився, бо не можна керувати тим, що не вимірюєш. Інтерфейси Running Average Power Limit від Intel привнесли потужність у програмні контури керування.
• Значення Tau часто підганяють під «гарні» вікна бенчмарків. Багато дефолтних Tau лежать у діапазоні десятків секунд, що… зручно.
• Виробники материнських плат трактують «за замовчуванням Intel» як рекомендацію. Деякі плати постачаються з підвищеним PL2/Tau, щоб виграти огляди, а рахунок за це оплачує ваш датацентр.
• PL1 не завжди дорівнює TDP. OEM можуть встановлювати PL1 вище або нижче номінального TDP залежно від охолодження та цілей продукту.
• Керування живленням — це проблема платформи, а не лише CPU. Дизайн VRM, ліміти PSU, потік повітря в шасі та вбудовані контролери можуть перевизначати ваші налаштування.
• Телеметрія неідеальна. Потужність пакета часто оцінюється, а не вимірюється безпосередньо, і точність варіюється залежно від платформи та калібрування.
• «Тепловий дизайн» включає час. Теплова ємність означає, що система може тимчасово поглинати тепло — саме це використовує Tau.
• Датацентри вже обмежують потужність — CPU просто вбудував це всередину. Бюджети по стійкам і PDU змусили очікувати передбачуване споживання; обмеження на рівні CPU — це деталізація контролю.

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

Коли продуктивність падає під навантаженням, потрібно швидко визначити обмежувач. Не починайте з зміни налаштувань BIOS.
Почніть з доведення, чи ви обмежені по потужності, по теплу або ж щось інше (планувальник, I/O, пропускна здатність пам’яті).

Перш за все: підтвердіть шаблон симптомів

• Пропускна здатність падає після сталого часового вікна (10–60 секунд)? Думайте про Tau/PL1.
• Падає відразу, коли температура наближається до TJmax? Думайте про термальне тротлінг / охолодження.
• Осцилює у циклах кількох секунд? Думайте про ліміти VRM/струму, агресивний PL2 або затримки в керуванні вентиляторами.

По-друге: зніміть пакети даних — потужність + частота + прапорці тротлінгу

• Використовуйте turbostat (Intel) або відповідні інструменти вендора, щоб зняти: потужність пакету, МГц, температуру і причини тротлінгу.
• Корелюйте з dmesg для термальних/PROCHOT повідомлень та з journalctl для демонів платформи, які змінюють політики.

По-третє: перевірте, які ліміти налаштовані і хто їх встановив

• Прочитайте значення powercap RAPL з sysfs; порівняйте з очікуваннями BIOS.
• Перевірте, чи демон постачальника або профіль живлення не переписує ліміти в часі виконання.
• У віртуалізованих хостів перевірте, чи політики гіпервізора не обмежують потужність непрямо (профілі потужності, cgroups, cpufreq).

По-четверте: оберіть клас виправлення

• Якщо обмеження по потужності, але терміни в нормі: помірно підвищіть PL1 або прийміть обмеження і плануйте ємність відповідно.
• Якщо термальне обмеження: спочатку виправте охолодження; підвищення PL1 лише погіршить тротлінг.
• Якщо ліміти струму/VRM: зменшіть PL2 або покращіть конструкцію материнської плати/PSU; слабку подачу живлення не «відналаштуєш» у силу.
• Якщо не обмеження CPU: припиніть чіпати налаштування потужності і шукайте справжнє вузьке місце.

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

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

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

cr0x@server:~$ lscpu | egrep 'Model name|Socket|Thread|Core|CPU\(s\)|MHz'
Model name:                           Intel(R) Xeon(R) CPU E-2288G @ 3.70GHz
CPU(s):                               16
Thread(s) per core:                   2
Core(s) per socket:                   8
Socket(s):                            1
CPU MHz:                              3700.000

Що це означає: Потрібен точний SKU, бо дефолтні значення PL залежать від SKU, OEM і мікрокоду.
Поточний рядок MHz зазвичай недостатній для діагностики, але дає орієнтир.
Рішення: Запишіть модель CPU перед тим, як порівнювати вузли або звинувачувати «однаковий» апарат.

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

cr0x@server:~$ sudo apt-get -y install stress-ng >/dev/null
cr0x@server:~$ stress-ng --cpu 16 --cpu-method matrixprod --metrics-brief --timeout 30s
stress-ng: info:  [12421] dispatching hogs: 16 cpu
stress-ng: metrc: [12421] stressor       bogo ops real time  usr time  sys time   bogo ops/s
stress-ng: metrc: [12421] cpu             39132     30.00   456.18     0.12      1304.40

Що це означає: Це створює контрольоване стале навантаження. Метрики дозволяють порівняти «до/після» змін.
Рішення: Запустіть це разом з turbostat, щоб побачити, чи продуктивність деградує під час прогону.

Завдання 3: Зняти турбо, потужність і прапорці тротлінгу за допомогою turbostat

cr0x@server:~$ sudo turbostat --Summary --interval 1 --quiet --num_iterations 10
     time  Avg_MHz  Busy%  Bzy_MHz  PkgWatt  CorWatt  PkgTmp  GFXWatt
     1.00     4680  98.23     4764    124.9     88.2      86     0.0
     2.00     4681  98.10     4766    125.1     88.0      89     0.0
     3.00     4502  98.05     4589    108.0     76.1      92     0.0
     4.00     4100  98.00     4189     95.2     67.5      92     0.0
     5.00     4098  98.02     4188     95.0     67.3      91     0.0

Що це означає: Ви буквально бачите крокове падіння: потужність пакету падає, і МГц падає після кількох секунд.
Це сумісно з тим, що Tau спливає і система осідає біля PL1.
Рішення: Якщо PkgTmp стабільний нижче TJmax, але МГц падає разом з PkgWatt — ймовірно ви обмежені по потужності (PL1), а не по теплу.

Завдання 4: Перевірити журнали ядра на предмет термальних і PROCHOT подій

cr0x@server:~$ sudo dmesg -T | egrep -i 'thermal|thrott|prochot|temperature' | tail -n 8
[Mon Jan 10 09:12:31 2026] thermal thermal_zone0: critical temperature reached (100 C), shutting down
[Mon Jan 10 09:15:02 2026] CPU0: Core temperature above threshold, cpu clock throttled (total events = 42)
[Mon Jan 10 09:15:02 2026] CPU2: Package temperature above threshold, cpu clock throttled (total events = 42)

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

Завдання 5: Прочитати значення обмежень RAPL з sysfs

cr0x@server:~$ ls -1 /sys/class/powercap/intel-rapl
intel-rapl:0
intel-rapl:0:0
intel-rapl:0:1

cr0x@server:~$ cd /sys/class/powercap/intel-rapl/intel-rapl:0
cr0x@server:~$ cat name
package-0
cr0x@server:~$ cat constraint_0_name
long_term
cr0x@server:~$ cat constraint_0_power_limit_uw
95000000
cr0x@server:~$ cat constraint_0_time_window_us
28000000
cr0x@server:~$ cat constraint_1_name
short_term
cr0x@server:~$ cat constraint_1_power_limit_uw
125000000

Що це означає: Довготривалий ліміт — 95W (PL1), часове вікно — 28 секунд (Tau), короткочасний ліміт — 125W (PL2).
Одиниці — мікровати і мікросекунди.
Рішення: Якщо ці значення не відповідають очікуванням BIOS, хтось (прошивка, ОС, демон) їх переписує.

Завдання 6: Спостерігати поточну енергію пакета і обчислити середню потужність

cr0x@server:~$ cat /sys/class/powercap/intel-rapl/intel-rapl:0/energy_uj
124987654321

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

Завдання 7: Перевірити, хто керує політикою частоти CPU (governor)

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

Що це означає: Governor впливає на вибір частоти, але не перевизначає жорсткі обмеження потужності.
Якщо ви в powersave, ви можете самі себе тротлити до того, як ліміти PL взагалі стануть важливими.
Рішення: Для контрольованих тестів використовуйте performance. Для флоту — обирайте навмисно.

Завдання 8: Виявити, чи intel_pstate у активному режимі і які є caps

cr0x@server:~$ cat /sys/devices/system/cpu/intel_pstate/status
active
cr0x@server:~$ cat /sys/devices/system/cpu/intel_pstate/max_perf_pct
100
cr0x@server:~$ cat /sys/devices/system/cpu/intel_pstate/min_perf_pct
20

Що це означає: Ви використовуєте intel_pstate з повним дозволом на максимальну продуктивність.
Якщо max_perf_pct низький, хтось вас обмежив і ви будете невірно звинувачувати PL1.
Рішення: Тримайте ці значення консистентними між вузлами перед порівнянням продуктивності.

Завдання 9: Перевірити, чи демони управління живленням змінюють політику

cr0x@server:~$ systemctl list-units --type=service | egrep 'tlp|power-profiles-daemon|thermald'
power-profiles-daemon.service loaded active running Power Profiles daemon
thermald.service              loaded active running Thermal Daemon Service

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

Завдання 10: Перевірити, чи платформа показує причини тротлінгу (прапорці turbostat)

cr0x@server:~$ sudo turbostat --interval 1 --num_iterations 5 | egrep 'PkgWatt|Bzy_MHz|PkgTmp|IRQ|^CPU|PL1|PL2|THERMAL'
CPU     Avg_MHz   Busy%   Bzy_MHz   PkgTmp   PkgWatt
-       4650      97.8    4730      88       124.0
-       4635      97.9    4720      90       124.8
-       4105      98.0    4186      91        95.1

Що це означає: Деякі збірки turbostat показують явні стовпці тротлінгу; інші — ні, залежно від ядра і підтримки CPU.
Навіть без прапорців зв’язка МГц і PkgWatt — сильний натяк.
Рішення: Якщо ви не бачите прапорців, компенсуйте через sysfs RAPL обмеження та журнали ядра.

Завдання 11: Обережно змінити PL1/PL2/Tau через powercap sysfs

cr0x@server:~$ cd /sys/class/powercap/intel-rapl/intel-rapl:0
cr0x@server:~$ sudo sh -c 'echo 105000000 > constraint_0_power_limit_uw'
cr0x@server:~$ sudo sh -c 'echo 140000000 > constraint_1_power_limit_uw'
cr0x@server:~$ sudo sh -c 'echo 35000000 > constraint_0_time_window_us'
cr0x@server:~$ cat constraint_0_power_limit_uw
105000000
cr0x@server:~$ cat constraint_0_time_window_us
35000000
cr0x@server:~$ cat constraint_1_power_limit_uw
140000000

Що це означає: Ви підвищили PL1 до 105В, PL2 до 140В, Tau до 35 с. Це може не зберегтися після перезавантаження.
Рішення: Робіть це лише на тестовому вузлі спочатку. Потім повторно запустіть те саме навантаження + turbostat і порівняйте.

Завдання 12: Перевірити реальний ефект зміни за допомогою відтворюваного бенчмарка

cr0x@server:~$ stress-ng --cpu 16 --cpu-method matrixprod --metrics-brief --timeout 60s
stress-ng: info:  [13200] dispatching hogs: 16 cpu
stress-ng: metrc: [13200] stressor       bogo ops real time  usr time  sys time   bogo ops/s
stress-ng: metrc: [13200] cpu             85510     60.00   909.90     0.12      1425.17

Що це означає: Якщо bogo ops/s зростає і залишається стабільним протягом прогону, ваш новий стійкий режим кращий.
Якщо він покращується на початку, але потім відкатується — ви, ймовірно, вивелися в межі термальних або струмових обмежень.
Рішення: Залишайте зміну лише якщо вона покращує тривалу пропускну здатність без підвищення кількості подій тротлінгу чи журналів помилок.

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

cr0x@server:~$ sudo apt-get -y install lm-sensors >/dev/null
cr0x@server:~$ sudo sensors
coretemp-isa-0000
Adapter: ISA adapter
Package id 0:  +92.0°C  (high = +95.0°C, crit = +100.0°C)
Core 0:        +90.0°C  (high = +95.0°C, crit = +100.0°C)
Core 1:        +91.0°C  (high = +95.0°C, crit = +100.0°C)

Що це означає: Ви близькі до high/crit. Навіть якщо зараз ви «лише» обмежені по потужності, у вас немає теплового запасу.
Рішення: Не підвищуйте PL на машині, що зазвичай живе при 92°C під звичним навантаженням. Виправте потік повітря, криву вентиляторів, пил або монтаж радіатора.

Завдання 14: Перевірити, чи cgroups обмежують CPU (поширено в контейнерах)

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

Що це означає: Це означає, що cgroup може використовувати 80% CPU за період 100ms (cgroup v2). Це штучне обмеження.
Рішення: Якщо ви бачите це, ваше «тротлінг» може бути через планування cgroup, а не через PL1/PL2. Виправте обмеження оркестрації перед налаштуванням потужності.

Завдання 15: Виявити розбіжність BIOS/прошивки між вузлами

cr0x@server:~$ sudo dmidecode -t bios | egrep 'Vendor|Version|Release Date'
Vendor: American Megatrends International, LLC.
Version: 2.1.7
Release Date: 08/14/2024

Що це означає: Різні версії BIOS часто означають різну поведінку за замовчуванням для PL/Tau.
Рішення: У флоті стандартизуйте версії BIOS (та налаштування) перед тим, як починати форензик продуктивності.

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

1) Інцидент через хибне припущення: «TDP = продуктивність»

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

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

SRE нарешті побудував графіки пропускної здатності по хосту під синтетичним навантаженням і помітив повторюване падіння через ~30 секунд.
Це був ключ. Старі сервери мали консервативну конфігурацію турбо: помірний PL2, розумний Tau, стабільний стійкий режим.
Нові сервери поставлялися з OEM-профілем «performance»: вищий PL2 і Tau достатній для прогріву шасі,
а PL1 виявився нижчим, ніж очікувалося, коли вбудований контролер почав захищати теплові ресурси платформи.

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

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

2) Оптимізація, що обернулася проти: «Підвищимо PL2 для швидших деплоїв»

Велике підприємство мало CI-флот, де часи збірок зростали. Хтось запропонував просте рішення:
«Ці CPU підтримують вищу турбо-потужність. Піднімемо PL2 і Tau, щоб збірки закінчувалися швидше.»
У вузькому сенсі це спрацювало. Медіанний час збірки покращився. Графіки для зустрічі стали симпатичними.

Через два тижні у флоті почалися випадкові відмови: випадкові перезавантаження воркерів, рідкісні kernel machine checks,
і той тип нестабільності, коли команди жартують про «космічні промені» і змінюють тему.
Діагностика апаратури не показала очевидних проблем. Температури навіть не були тривожними — лише імпульсні.

Справжня проблема була в транзієнтах. Підвищення PL2 і Tau спричинило повторювані стрибки струму під час паралельних збірок.
VRM і поєднання PSU на тім шасі могли витримувати середнє навантаження, але не любили повторювані імпульсні підвищення потужності.
Система залишалася «в межах термальних лімітів», але все одно навантажувала електроживлення компонентів.
Відмови концентрувалися в періоди високої паралельності збірок і коли патерни спалахів співпадали.

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

Мораль: підвищення PL2 не безкоштовне. Воно зміщує стрес з «тепло в часі» на «струм зараз». Саме струм зараз виявляє слабкі ланки.

3) Нудна, але правильна практика, що врятувала день: «Явні ліміти і виявлення дрейфу»

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

Вони зробили нудну річ. Створили документ апаратного профілю для кожної платформи, де явно перерахували PL1/PL2/Tau,
налаштування BIOS, профілі вентиляторів і налаштування governor в ОС. Застосували це через конфігураційний менеджмент, який перевіряв значення RAPL при завантаженні,
і налаштували оповіщення при дрейфі — якщо вузол повідомляв інші constraint-значення, ніж очікувалося.

Через місяці пройшло термінове оновлення мікрокоду/BIOS через безпеку. Після оновлення частина вузлів тихо змінила поведінку Tau і PL2 за замовчуванням.
Без виявлення дрейфу команда помітила б це лише коли хвостова латентність почала розширюватися.
Натомість оповіщення спрацювали за годину після першого канаркового перезавантаження.

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

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

1) «Воно буститься до 5 GHz, а потім падає до 3.8 GHz»

Симптоми: Повторюване падіння після фіксованого часового вікна; температури не на TJmax.

Корінна причина: Tau спливає і CPU осідає в стійкому режимі PL1.

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

2) «Температури в нормі, але продуктивність низька»

Симптоми: Низькі МГц під навантаженням, низька потужність пакету, немає термальних логів.

Корінна причина: ОС-політика (intel_pstate max_perf_pct, cpufreq governor), cgroup-ліміти CPU або політика хоста гіпервізора.

Виправлення: Перевірте governor, обмеження intel_pstate і квоти cgroup перед тим, як чіпати PL-ліміти.

3) «Ми підвищили PL1 і стало гірше»

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

Корінна причина: Ви перейшли від обмеження по потужності до термального обмеження стійкого стану (TJmax/PROCHOT).

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

4) «Випадкові перезавантаження після налаштування турбо»

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

Корінна причина: Стрес транзієнтів струму VRM/PSU від агресивного PL2/Tau; обмеження подачі живлення платформи.

Виправлення: Зменшіть PL2 і/або Tau; згладьте паралельність навантаження; переконайтеся, що PSU/VRM і BIOS підтверджені для цієї конфігурації потужності.

5) «Два однакові сервери мають різну продуктивність»

Симптоми: Той самий SKU CPU, різні стійкі МГц і потужність; непослідовні результати бенчмарків.

Корінна причина: Різні версії BIOS, профілі за замовчуванням вендора або різне охолодження/VRM у шасі.

Виправлення: Стандартизуйте конфігурацію BIOS; зчитайте RAPL-обмеження; не вважайте «той самий SKU» достатнім.

6) «Ми встановили ліміти в ОС, але вони повертаються»

Симптоми: Значення sysfs змінюються після перезавантаження або після запуску демона.

Корінна причина: BIOS відновлює обмеження при завантаженні, або демон управління живленням переписує їх під час роботи.

Виправлення: Віддавайте перевагу BIOS для стабільних флотних дефолтів; якщо керуєте з ОС, застосовуйте при завантаженні через systemd unit і відключайте конфліктні сервіси.

7) «Продуктивність ноутбука падає на батареї»

Симптоми: Різко нижчі PL1/PL2 на батареї; різке тротлінг під тривалим навантаженням.

Корінна причина: Вбудований контролер застосовує бюджет батареї/адаптера та обмеження температури поверхні корпуса.

Виправлення: Використовуйте відповідний профіль живлення; не бенчмаркніть на батареї; прийміть, що платформа, а не CPU, керує цим.

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

Покроково: встановіть надійну базу

1. Запишіть ідентичність платформи: модель CPU (lscpu), версія BIOS (dmidecode), версія ядра, версія мікрокоду.
2. Запишіть політику: governor (scaling_governor), статус intel_pstate, запущені демони управління потужністю.
3. Запишіть налаштовані ліміти: зчитайте RAPL-обмеження (PL1/PL2/Tau) з sysfs.
4. Запустіть контрольоване навантаження: наприклад, stress-ng на 60s.
5. Зніміть телеметрію: turbostat з інтервалом 1s і вивід sensors при стійкому режимі.
6. Позначте час до «обриву»: коли частота/потужність падають; порівняйте з Tau.

Покроково: вирішіть, чи змінювати ліміти

1. Якщо температура близька до TJmax: не підвищуйте PL1/PL2. Спочатку виправте охолодження.
2. Якщо PkgWatt обмежується біля PL1 і температура в нормі: розгляньте підвищення PL1 помірними кроками (5–10W) і повторно тестуйте.
3. Якщо потрібні лише короткі сплески: налаштовуйте PL2 і Tau під тривалість сплеску, а не щоб виграти синтетичні графіки.
4. Якщо стабільність важливіша за пік: знизьте PL2 і/або Tau, щоб зменшити осциляції і транзієнти струму.
5. Перевіряйте на навантаженні, схожому на продакшн: не лише синтетичному CPU burn; враховуйте пам’ять і I/O.

Контрольний список для флоту: щоб це не стало повторною таємницею

• Встановіть явні PL1/PL2/Tau у BIOS для кожного апаратного класу.
• Збережіть «очікувані RAPL-обмеження» і перевіряйте їх при завантаженні.
• Оповіщайте про дрейф: якщо обмеження змінюються, ставте це як конфіг-дриф.
• Тримайте версії BIOS консистентними, особливо після оновлень безпеки.
• Продуктивність плануйте за стійким режимом (PL1), а не за спуртом (PL2).
• Документуйте бізнес-правило: ви оптимізуєте для латентних сплесків чи для тривалої пропускної здатності?

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

1) Чи PL1 і TDP — це те саме?

Не завжди. Багато платформ ставлять PL1 близько до TDP, але OEM можуть встановлювати його вище або нижче залежно від охолодження та цілей продукту.
Розглядайте TDP як маркетингово-навіяну теплову орієнтир, а не як гарантію тривалої поведінки потужності.

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

Бо бенчмарки часто живуть у вікні PL2/Tau. Вони вимірюють спринт. Ваше навантаження — марафон.
Міряйте у стійкому режимі і слідкуйте за часом до обмеження.

3) Якщо температури низькі, чи можна безпечно підвищити PL1?

«Безпечно» залежить від VRM, PSU і потоків повітря шасі, а не лише від температури CPU.
Низька температура підказує тепловий запас, але все одно треба перевірити стабільність і живлення під імпульсним та сталим навантаженням.

4) Який Tau вважається розумним?

Розумно залежить від навантаження. Якщо ваш сервіс бачить сплески тривалістю декілька секунд, довгий Tau здебільшого додає тепла і ризик осциляції.
Якщо задачі завершуються за 20–40 секунд, тонке налаштування Tau може мати значення. Для довготривалих робіт Tau впливає переважно на першу хвилину, після чого править PL1.

5) Чому підвищення PL2 іноді зменшує продуктивність?

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

6) Чи можна налаштувати PL-ліміти всередині VM або контейнера?

Зазвичай ні в значущому сенсі. Ліміти PL застосовуються на рівні хоста CPU/пакету.
У контейнерах ви можете обмежувати CPU через cgroups; у VM — корегувати розклад віртуальних CPU, але зазвичай не переписати хостові обмеження RAPL.

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

Обмеження за потужністю часто проявляється як падіння частоти при температурі нижче TJmax і потужність пакету, що фіксується біля ліміту.
Термальне тротлінг показує температуру, що досягає стелі, і логи або прапорці, що вказують на термальні події; потужність може впасти як наслідок.

8) Чи завжди варто ставити профілі «maximum performance» в BIOS?

Не бездумно. «Maximum performance» часто означає вищий PL2 і довший Tau, що може порушити ваші бюджети по потужності стійки і знизити передбачуваність.
Для продакшну обирайте «послідовну продуктивність», якщо у вас немає виміряної причини гнатися за піками.

9) Чи мають AMD системи ті самі концепції PL1/PL2/Tau?

Назви інші, але ідея — бюджети потужності по часових вікнах — спільна для сучасних CPU.
На AMD ви побачите інші контролі (PPT/TDC/EDC і поведінка бусту), але діагностувати потрібно так само: корелюйте частоти, потужність, температуру і прапорці лімітів.

10) Який є найкорисніший графік для цього?

Частота, потужність пакету і температура на одній часовій шкалі під час стійкого тесту навантаження, з прапорцями тротлінгу/лімітами якщо доступні.
«Уламок» стає очевидним, і ви можете зіставити його з Tau або з тепловою межею.

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

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

Зробіть це далі:

1. Виберіть один репрезентативний вузол і зніміть 60-секундний тест під навантаженням з turbostat + sensors.
2. Зчитайте налаштовані PL1/PL2/Tau з RAPL sysfs і порівняйте з поведінкою, що спостерігається.
3. Розпишіть, що ви оптимізуєте: латентність сплесків або тривалу пропускну здатність. Запишіть це.
4. Міняйте одну змінну за раз (PL1 або PL2 або Tau), маленькими кроками, і повторно тестуйте під тим самим навантаженням.
5. Стандартизуйте налаштування BIOS по флоту і налаштуйте оповіщення про дрейф, щоб не відкривати це що квартал.

Передбачувані системи зазвичай трохи менш захопливі. Ось у чому суть.