Turbo Boost: як процесори легально обманюють свої технічні характеристики

Специфікації проти реальності: що насправді обіцяє «турбо»

Маркетинг CPU хоче, щоб ви мислили одним числом: «до 5.0 GHz». Операційна команда хоче інше число: «яку частоту я отримаю весь день під моїм реальним навантаженням, з моїм охолодженням, моїми енергетичними лімітами та шумним VM-сусідом?» Turbo Boost — це місце, де ці два числа перестають бути друзями.

Базова частота — це нудний контракт; турбо — умовний купон

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

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

Турбо — не лише частота; це ціла система управління

Сучасні процесори постійно балансують між:

• Енергією (потужність пакета, інколи по доменах)
• Температурою (jumction temperature та гарячі ділянки)
• Обмеженнями струму (електричні обмеження VRM і поставки через сокет)
• Типом навантаження (AVX/AVX2/AVX-512 можуть викликати зсуви частоти)
• Кількістю ядер (турбо для одного ядра ≠ турбо для усіх ядер)
• Часом (короткий «спринт» проти стійкої «марафонської» потужності)

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

Жарт №1: Turbo Boost схожий на «безлімітний» мобільний інтернет: технічно правдиво, поки ви не почнете ним користуватися.

Чому турбо існує: фізика і бізнес

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

Варіативність кремнію та бінування

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

Навантаження не постійні

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

Енергетичні бюджети — це реальні бюджети

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

Правила гри: енергія, терміка та невидимі таймери

Щоб керувати турбо розумно, потрібно знати три регулятори, які повторюються знову і знову (назви відрізняються у різних вендорів, але концепт стабільний):

• Ліміт стійкої потужності (аналог Intel PL1): що можна тримати довго
• Короткочасний ліміт потужності (аналог Intel PL2): що можна тримати коротко
• Часове вікно (аналог Tau): як довго триває «коротко»

PL1 / PL2 / Tau: шаблон «спринт, потім стабілізація»

Багато систем поводяться так: вони піднімаються вище стійкої потужності на якийсь інтервал, а потім опускаються, щоб відповідати довготерміновому конверту. Ось чому перші 30 секунд бенчмарку виглядають приголомшливо, а наступні 10 хвилин — так, ніби ви купили дешевший CPU.

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

Термальні обмеження важливіші за все

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

Пенальті набору інструкцій: «податок» AVX

Широкі векторні інструкції споживають більше енергії й дають більше тепловиділення. Багато CPU застосовують зсуви частоти, коли активні AVX/AVX2/AVX-512. Це не баг; це інстинкт виживання, реалізований у MSR-реєстрах.

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

Прошивка і політика платформи: питання «хто керує?»

Поведінка турбо формується стеком:

• мікрокод CPU
• налаштування BIOS/UEFI (енергетичні ліміти, увімкнення турбо, уподобання енергія/продуктивність)
• OS CPUfreq governor (Linux: performance/ondemand/schedutil)
• політики гіпервізора та планування vCPU (віртуалізоване середовище)
• рівень датацентру: обмеження живлення (BMC, PDU стійки, менеджер потужності кластеру)

Якщо ви налаштували лише один шар, інші шари можуть ввічливо вас ігнорувати.

Цитата, яку варто повісити на стіні: «Надія — не стратегія.» — генерал Гордон Р. Салліван

Що ви бачите в продакшені: типові шаблони роботи турбо

Шаблон 1: Велике одноядерне турбо, посереднє для всіх ядер

Чудово для слабопаралельних задач: парсинг запитів, UI-потоки, деякі кроки збірки JavaScript, одне гаряче шардове ядро. Розчаровує для паралельних навантажень: аналітики, хвилі компактації, відновлення, шифрування в масштабі.

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

Шаблон 2: Швидко 20–60 секунд, потім «чому воно повільніше, ніж минулого тижня?»

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

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

Шаблон 3: Осциляція частоти під тепловим стресом

Термальне троттлінг часто виглядає так:

• Температура пакета CPU підходить до максимуму
• Частота скаче (наприклад, 3.6 → 2.4 → 3.1 → 2.2 GHz)
• Сплески латентності, які корелюють із провалами

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

Шаблон 4: «Мій CPU 100%, але він повільний» (це не лише завантаження)

Завантаженість не каже про виконану роботу на цикл і не показує частоту циклів. Ядро на 100% при 2.0 GHz — не те саме, що ядро на 100% при 3.5 GHz. Додайте зміни IPC через промахи кешу — і ви отримаєте тривимірний біль.

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

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

1. Динамічне масштабування частоти передувало брендингу «Turbo Boost»: CPU і ноутбуки використовували speed stepping і стани енергоспоживання задовго до сучасної ери турбо.
2. Ранні турбо-поведінки сильно залежали від вендора й плати: налаштування BIOS інколи дозволяли CPU працювати поза номінальними лімітами, щоб вигравати бенчмарки.
3. «До» турбо зазвичай — це пікове значення на одному ядрі, а не обіцянка для всіх ядер; багато CPU публікують окремі таблиці турбо залежно від числа активних ядер.
4. Серверні платформи часто накладають суворіші обмеження, ніж десктопи, щоб захистити бюджет живлення стійки та довгострокову надійність.
5. Векторні інструкції можуть викликати зсуви частоти, бо вони збільшують щільність потужності; саме тому дві «CPU-залежні» задачі можуть отримувати дуже різні тактові частоти.
6. Інтерфейси Intel RAPL зробили енергію видимою для ОС, дозволивши користувацьким інструментам (як turbostat) звітувати про енергію та потужність практично.
7. TDP не є «максимальною потужністю»; це ціль проектування, зв’язана зі стійкими припущеннями щодо охолодження, і турбо може її перевищувати.
8. Провайдери хмар часто віртуалізують очікування продуктивності: та сама кількість vCPU може відповідати різним реальним частотам залежно від завантаження хоста й обмежень живлення.

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

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

Середня SaaS-компанія розгорнула новий сервіс інжесту. Прототип працював на кількох потужних серверах і виглядав чудово. Команда зробила те, що роблять команди: обрала SKU CPU, дивлячись на один рядок у листі постачальника — «Max Turbo Frequency» — і масштабувала інфраструктуру.

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

Онкол команда ганяла звичні підозри: мережа, сховище, GC. Нічого з очевидного. Потім хтось порівняв цифри холодного запуску та 30-хвилинного стійкого прогону і побачив криву: швидкий старт, повільне установлення. Це не було регресією в ПЗ; це було поведінкою енергетичного вікна плюс набір інструкцій, що викликав зсуви частоти.

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

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

Внутрішня команда платформи захотіла знизити латентність для групи API-сервісів. Хтось запропонував прив’язати потоки до конкретних ядер і відключити варіативність частоти процесора, примусивши Linux governor до performance. Розумно на папері, і це покращило медіану у швидкому тесті.

За два тижні латентність погіршилася в пікові години. Сервери працювали близько до теплових меж, бо governor performance тримав високі частоти навіть коли навантаження не вимагало цього. Вентилятори підвищили оберти, температура на вході зросла, і CPU почали термально тротлити. Результат: осциляція тактів, гірша хвостова латентність і типова взаємна підозра команд.

Команда врешті довчилася важким шляхом: прив’язування плюс постійно висока частота зменшує запас по терміці. Вони відкочували масове введення governor, тонко налаштували енергетичні ліміти на хостах і додали лічильники температури та троттлінгу до своїх SLO-дашбордів. Медіана виглядала трохи гіршою, ніж «оптимізована» конфігурація, але p99 перестала поводитися як сейсмограф.

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

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

Новий стій приїхав із трохи іншою ревізією материнської плати. Той самий SKU CPU, та сама RAM, ті самі диски. Числа бенчмарків у першу хвилину були чудові. Але впродовж години стійка стійка all-core частота виявилась нижчою за затверджену базу. Команда зафіксувала це й призупинила розгортання.

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

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

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

Це подано у Linux-кольорі, бо саме там живе більшість інструментів спостереження. Виконуйте на bare metal, якщо можете. У віртуалках ви можете отримати часткову правду — і це окрема наука.

Завдання 1: Визначити модель CPU і заявлені базову/максимальну частоти

cr0x@server:~$ lscpu | egrep 'Model name|CPU\(s\)|Thread|Core|Socket|MHz'
Model name:                           Intel(R) Xeon(R) Gold 6230 CPU @ 2.10GHz
CPU(s):                               80
Thread(s) per core:                   2
Core(s) per socket:                   20
Socket(s):                            2
CPU MHz:                              2100.000

Що це означає: Рядок моделі містить базову частоту (тут 2.10 GHz). Рядок current MHz — це не турбо; це знімок стану і часто вводить в оману.

Рішення: Запишіть SKU і топологію ядер. Припиніть цитувати «до» турбо як вашу базу; розглядайте його як умовну межу.

Завдання 2: Перевірити політику CPUfreq у поточній ОС

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

Що це означає: ОС має право масштабувати частоту відповідно до евристики планувальника. Якщо ви бачите powersave, очікуйте консервативних тактів; якщо performance — вищих стійких тактів (і більше тепла).

Рішення: Для сервісів, чутливих до латентності, віддавайте перевагу передбачуваній поведінці: або performance за наявності термального запасу, або schedutil з верифікованим p99. Не міняйте це масово без аналізу.

Завдання 3: Подивитися мін/макс частоти, доступні ОС

cr0x@server:~$ cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_min_freq
800000
cr0x@server:~$ cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq
3900000

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

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

Завдання 4: Спостерігати реальне турбо та троттлінг за допомогою turbostat (Intel)

cr0x@server:~$ sudo turbostat --Summary --interval 5 --quiet
CPU     Avg_MHz   Busy%   Bzy_MHz  IPC  PkgWatt  CorWatt  PkgTmp
-       2875      62.10   4628     1.45  178.32   142.10   83

Що це означає: Bzy_MHz — ефективні МГц при завантаженні (ближче до того, що вам важливо). PkgWatt і PkgTmp показують, чи ви обмежені потужністю або температурою.

Рішення: Якщо PkgTmp поряд із максимумом і МГц падає — виправляйте охолодження. Якщо потужність обмежена й частота низька — розбирайтесь з енергетичними лімітами.

Завдання 5: Спостерігати частоту під стійким навантаженням (швидко і грубо)

cr0x@server:~$ grep -n "cpu MHz" /proc/cpuinfo | head
1:cpu MHz         : 3799.812
29:cpu MHz        : 3810.224
57:cpu MHz        : 2201.104

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

Рішення: Використовуйте це як швидку перевірку, а не як остаточний висновок. Якщо виглядає дивно — підтвердіть через turbostat.

Завдання 6: Перевірити прапори увімкнення/вимкнення турбо (intel_pstate)

cr0x@server:~$ cat /sys/devices/system/cpu/intel_pstate/no_turbo
0

Що це означає: 0 — турбо дозволено; 1 — турбо вимкнено.

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

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

cr0x@server:~$ sudo powercap-info --intel-rapl
Zone: package-0
  power limit 1: 165.00 W (enabled)  time window: 28.00 s
  power limit 2: 210.00 W (enabled)  time window: 0.00 s
Zone: package-1
  power limit 1: 165.00 W (enabled)  time window: 28.00 s
  power limit 2: 210.00 W (enabled)  time window: 0.00 s

Що це означає: Це практична картина PL1/PL2: стійкі та короткочасні ліміти. Якщо PL1 низький, ваші стійкі такти будуть низькі.

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

Завдання 8: Виявити термальне троттлінг у логах ядра

cr0x@server:~$ sudo dmesg | egrep -i 'thrott|thermal|power limit' | tail -n 5
[12345.678901] CPU0: Package temperature above threshold, cpu clock throttled
[12345.678950] CPU0: Core temperature above threshold, cpu clock throttled

Що це означає: Ядро каже вам, що CPU досяг термальних меж.

Рішення: Не налаштовуйте ПЗ першим. Перевірте охолодження: радіатори, циркуляцію повітря, криві вентиляторів, температуру на вході та панелі стійки.

Завдання 9: Зчитати датчики температури CPU (lm-sensors)

cr0x@server:~$ sensors | egrep 'Package id 0|Package id 1'
Package id 0:  +84.0°C  (high = +90.0°C, crit = +100.0°C)
Package id 1:  +82.0°C  (high = +90.0°C, crit = +100.0°C)

Що це означає: Ви близькі до порогу «high»; турбо-запас скорочується.

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

Завдання 10: Перевірити, чи маєте ви AVX-пов’язані зміни частоти (непрямі ознаки)

cr0x@server:~$ sudo perf stat -a -e cycles,instructions,msr/aperf/,msr/mperf/ -- sleep 10
 Performance counter stats for 'system wide':

     32,114,221,998      cycles
     41,520,220,110      instructions
      9,821,110,002      msr/aperf/
     12,480,003,000      msr/mperf/

       10.002018749 seconds time elapsed

Що це означає: Відношення aperf/mperf показує фактичну частоту відносно номіналу. Низьке відношення під певними навантаженнями може сигналізувати про енергетичні/термальні обмеження або зсуви при векторних інструкціях.

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

Завдання 11: Підтвердити C-стани та поведінку в режимі простою (компроміс латентності)

cr0x@server:~$ sudo cpupower idle-info | head -n 12
CPUidle driver: intel_idle
CPUidle governor: menu
analyzing CPU 0:
  Number of idle states: 4
  C1: type:C1 latency:2 us
  C3: type:C3 latency:80 us
  C6: type:C6 latency:104 us
  C7: type:C7 latency:109 us

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

Рішення: Для ультра-низької латентності розгляньте обмеження глибоких C-станів — але тільки після вимірювань. Ви торгуєте енергією/термікою за хвостову латентність.

Завдання 12: Перевірити, який драйвер масштабування частоти використовує ОС

cr0x@server:~$ cpupower frequency-info | egrep 'driver|policy|current CPU frequency'
driver: intel_pstate
current policy: frequency should be within 800 MHz and 3900 MHz.
current CPU frequency: 2.30 GHz (asserted by call to hardware)

Що це означає: Драйвер масштабування визначає, як агресивно ОС проситиме зміну частоти й як інтерпретує стан обладнання.

Рішення: Якщо ви женетеся за передбачуваністю — стандартизуйте поєднання драйвера/governor по флоту і документуйте rationale.

Завдання 13: Помітити маскування віртуалізацією (чи ви взагалі бачите реальні такти?)

cr0x@server:~$ systemd-detect-virt
kvm

Що це означає: У VM телеметрія частоти може бути синтетичною або залежати від хоста. Турбо вирішується на хості, а не в гостьовій ОС.

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

Завдання 14: Підтвердити експозицію троттлінгу через /proc (швидкі лічильники)

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

Що це означає: Нечислові показники троттлінгу вказують на реальні події, а не почуття.

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

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

Коли продуктивність «таємниче» погана, у вас немає часу ставати істориком мікроархітектури. Потрібна послідовність, яка сходиться швидко.

Спочатку: вирішіть, чи ви обмежені енергією, термікою або ні тим

1. Перевірте лічильники/логи троттлінгу (dmesg, лічильники thermal_throttle). Якщо є події — ймовірно, ви термально обмежені.
2. Перевірте температуру пакета і поведінку вентиляторів (sensors, телеметрія BMC). Якщо температура висока — зупиніться і виправляйте охолодження/циркуляцію повітря.
3. Перевірте потужність пакета відносно лімітів (turbostat PkgWatt та RAPL-ліміти). Якщо ватажка доходить до жорсткої межі й частота низька — ви обмежені енергією.

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

1. Запустіть turbostat --Summary під стійким навантаженням і зафіксуйте Bzy_MHz і PkgTmp.
2. Порівняйте з очікуваними стійкими all-core числами для цього SKU (з ваших лабораторних тестів, а не з маркетингової сторінки).
3. Якщо ви у VM — підтвердьте, чи хост не перевантажений або не обмежений енергією; гостьові лічильники можуть брехати через упущення.

По-третє: перевірте набір інструкцій і контенцію

1. Корелюйте падіння частоти з конкретними задачами або бінарями (крипто, стиснення, ML). Якщо так — підозрівайте AVX-зсуви або стрибки потужності.
2. Перевірте чергу виконання і CPU steal (у VM) щоб відокремити «CPU повільний» від «CPU вам не належить».
3. Підтвердіть пам’ятєвий тиск і промахи кешу, якщо частота нормальна, а пропускна здатність низька (колапс IPC — інша проблема).

Жарт №2: Якщо ваш сервер «підтримує турбо», це не означає, що він «любить турбо» у стійці при 35°C.

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

1) «Ми купили CPU 3.5 GHz, чому під навантаженням бачимо 2.2 GHz?»

Симптоми: Пропускна здатність нижча за очікувану; p95/p99 зростає під стійким навантаженням; такти падають після початкового сплеску.

Корінна причина: Плутанина базової та турбо; PL1 низький; навантаження викликає AVX-зсуви; вікно стійкої потужності спливло.

Виправлення: Виміряйте стійкий Bzy_MHz під реальним навантаженням; налаштуйте політику BIOS, якщо дозволено; плануйте ємність за стійким станом, а не за першою хвилиною.

2) Латентність стрибає кожні кілька хвилин, як по годиннику

Симптоми: Періодичні p99-сплески; графіки температури CPU мають пилкоподібний вигляд; вентилятори підвищують/знижують оберти; немає очевидного GC-патерну.

Корінна причина: Осциляція термального троттлінгу через граничне охолодження або надто агресивні налаштування турбо/енергії.

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

3) «Ми примусили performance governor і стало гірше»

Симптоми: Краще медіана, гірша хвостова латентність; вища температура на вході/CPU; лічильники троттлінгу ростуть.

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

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

4) Бенчмарки показують великі прирости, у продакшені — жодних

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

Корінна причина: Тривалість бенчмарку підпадає під часове вікно турбо; продакшн — стійкий. Або бенчмарк використовує менше ядер, ніж продакшн.

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

5) «CPU у порядку», бо завантаження низьке

Симптоми: Низький CPU% але висока латентність; час запиту домінує «обробкою», а не I/O; частота низька при переході з простою в активність.

Корінна причина: Глибокі C-стани і консервативне масштабування викликають затримки пробудження і розгін. Середні значення завантаження ховають імпульси.

Виправлення: Виміряйте вплив затримки пробудження; для строгих SLO обмежте глибокі C-стани і узгодьте політику governor з навантаженням. Після змін перевірте терміку.

6) Продуктивність VM сильно варіюється на ідентичних типах інстансів

Симптоми: Та сама програма, та сама кількість «vCPU», різна пропускна здатність; підозра на шумного сусіда; такти виглядають «застиглими».

Корінна причина: Хостові енергетичні ліміти, оверкоміт або масштабування частоти; гість не керує турбо; steal time і контенція планувальника.

Виправлення: Виміряйте CPU steal; при потребі прив’язуйте критичні навантаження до виділених хостів/інстансів; розглядайте «vCPU» як одиницю планування, а не як гарантію GHz.

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

Контрольний список A: Встановити реалістичну «системну» базову стійку частоту для SKU CPU

1. Виберіть репрезентативне навантаження (або реплей), що відповідає продакшн-міксу інструкцій і конкуренції.
2. Запустіть його довше, ніж триває турбо-вікно (думайте 20–60 хвилин, а не 60 секунд).
3. Збирайте: підсумок turbostat, температури, потужність, лічильники троттлінгу і пропускну здатність/латентність.
4. Запишіть стійкий Bzy_MHz у steady-state і пов’язані ватти/температури.
5. Збережіть результати як внутрішню базу для планування ємності та порівнянь при закупівлях.

Контрольний список B: Готовність продакшну для сервісів, чутливих до турбо

1. Вирішіть, що ви оптимізуєте: пропускну здатність, медіану латентності або хвостову латентність. Оберіть одну як основний SLO-драйвер.
2. Уніфікуйте політику енергії BIOS по флоту (або по кластеру) і задокументуйте її.
3. Уніфікуйте налаштування governor/драйвера і перевіряйте після оновлень ядра.
4. Додайте дашборди: частота (проксі Bzy_MHz), температура пакету, потужність пакету, лічильники троттлінгу і латентність запитів.
5. Сповіщайте про «зростання лічильників троттлінгу + зростання латентності», а не лише про температуру.

Контрольний список C: Коли варто відключити турбо (так, іноді)

1. Якщо ви виконуєте строго детерміновані задачі, де варіативність шкодить більше, ніж швидкість (деякі торгові системи, деякі контрольні петлі).
2. Якщо охолодження маргінальне і ви не можете швидко це виправити — відключити турбо може зменшити осциляцію і стабілізувати p99.
3. Якщо у вас енергетичне обмеження на рівні стійки і турбо викликає синхронізовані сплески, що тригерять політики.

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

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

1) Чи є Turbo Boost просто розгін?

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

2) Чому мій CPU ніколи не досягає рекламованої максимальної турбо-частоти?

Тому що ця максімальна частота здебільшого — найкращий можливий пік на невеликій кількості ядер за специфічних умов. Навантаження all-core, важкі AVX інструкції, енергетичні обмеження і температура її зменшать.

3) У чому різниця між базовою частотою й турбо для планування ємності?

Базова — ближча до стійкої гарантії в межах проєктного енергетичного конверту. Турбо — змінна. Для планування вимірюйте стійку поведінку вашого навантаження і розглядайте турбо як опортуністичний запас.

4) Чи може оновлення BIOS змінити поведінку турбо?

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

5) Чому шифрування/стиснення роблять CPU «повільнішим»?

Такі навантаження можуть використовувати векторні інструкції і підвищувати щільність потужності. CPU може знизити частоту, щоб залишатися в межах енергетичних/термальних обмежень. Роботи за цикл може стати ефективніше, але кількість циклів за секунду падає.

6) Чи треба ставити Linux governor у performance на серверах?

Іноді. Це може зменшити затримку розгону частоти і покращити хвостову латентність — поки це не штовхне вас у термальне тротлінг. Якщо ви не можете довести наявність термального запасу під пік-трафіком — не вмикайте масово.

7) У VM я можу контролювати турбо?

Не напряму. Турбо вирішується на хості. Гості можуть запитувати поведінку через віртуалізовані інтерфейси, але політика хоста перемагає. Для передбачуваної продуктивності вам потрібні гарантії на хості.

8) Які метрики треба ставити в алерти для інцидентів, пов’язаних з турбо?

Лічильники троттлінгу у зростанні, температура пакета близько до ліміту, потужність пакета застрягла на капі, та падіння ефективної busy-частоти, що корелює зі зниженням продуктивності/латентності.

9) Чи відключення турбо покращує надійність або тривалість життя заліза?

Воно може зменшити тепло й пікову потужність, що загалом корисно для систем. Але надійність переважно про перебування в межах проєктних лімітів. Якщо ваше охолодження в порядку і немає стрибків потужності, саме турбо не є безрозсудним.

10) Чому «ідентичні» сервери показують різну турбо-поведінку?

Різниці в дефолтних прошивках, охолодженні (куриві вентиляторів, пил, циркуляція повітря), роботі VRM, температурі навколишнього повітря і навіть невеликій кремнієвій варіативності можуть змістити стійкі такти. Вимірюйте, не припускайте.

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

1. Припиніть використовувати «max turbo» у слайдах для планування ємності. Замініть його на виміряну стійку частоту під вашим навантаженням і конкуренцією.
2. Додайте телеметрію, що враховує турбо. Розмістіть температуру пакета, лічильники троттлінгу та ефективні busy MHz поруч із графіками латентності. Кореляція краще за віру.
3. Виберіть політику платформи цілеспрямовано. Вирішіть, чи ви оптимізуєте під пропускну здатність або хвостову латентність, і вирівняйте BIOS-ліміти, governor-и та охолодження під це рішення.
4. Характеризуйте новий хардворе так, ніби він може зрадити вас. Бо може — чемно, у межах специфікацій і саме тоді, коли вам менш всього потрібні сюрпризи.

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