Intel Tick‑Tock: стратегія, яка працювала — поки не перестала

Tick‑tock в одному абзаці

Intel tick‑tock був ритмом розробки продукту: «tick» означав зменшення техпроцесу (та сама базова архітектура, менші транзистори), а «tock» — нову мікроархітектуру (новий дизайн) на перевіреному процесі. Приблизно щороку отримували або зменшення вузла, або переробку архітектури. Для клієнтів це створювало ілюзію метронома: передбачувані прирости продуктивності на ват, передбачувані цикли оновлення, графіки амортизації, планування персоналу — все стало передбачуваним. Така передбачуваність була реальною — доки раптом не сталася помилка.

Чому командам операцій було зручно з tick‑tock (і чому це було небезпечно)

З позиції SRE tick‑tock був більше, ніж маркетинг. Це була первинна одиниця планування. Можна було будувати квартальні моделі потужностей з припущенням «CPU покоління N+1 дає X% більше пропускної здатності при Y% меншому енергоспоживанні», потім переводити це в кількість стійок і енергетичні контури. Міграції, прогін обладнання й оновлення флоту можна було планувати, як на фабриці.

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

Tick‑tock також підштовхував до однієї шкідливої звички: відкладати важку роботу. «Ми виправимо це наступним оновленням» — операційний наркоз. Це здається відповідальним — навіщо оптимізувати чи переробляти зараз, якщо наступні CPU вирішать проблему? Потім наступний рік не настає вчасно, і ви лишаєтеся з робочим навантаженням, яке ніколи не навчилося поводитися.

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

Жарт №1: Епоха tick‑tock була як метроном для вашого бюджету. Потім фізика зайшла і вимкнула його.

Цікаві факти та історичний контекст (те, що люди забувають)

• Tick‑tock почався як інструмент дисципліни. Це був не лише слоган; це був спосіб чергувати ризики: ризик виробництва в одному циклі, ризик дизайну в наступному.
• Пізніше модель розширили. Intel зрештою перейшов до моделі «process–architecture–optimization», визнавши, що проста альтернація не працює бездоганно.
• «14nm» стало більше, ніж одне покоління. Кілька сімейств CPU і оновлень жили на 14nm довше, ніж очікували, розтягуючи значення «нове покоління» для операційників.
• Затримки 10nm — це були не просто переносні строки. Вони відображали проблеми виходу придатних кристалів і складність масштабування, мульти‑паттернінгу та одночасного досягнення цілей (щільність, частота, витік).
• IPC‑прирости ніколи не були гарантовані. Зміни мікроархітектури можуть обмінювати продуктивність одиночного потоку на енергоефективність, посилення безпеки або більше ядер — корисно, але не завжди відповідає вимогам вашого навантаження.
• Потужність стала стелею раніше, ніж обчислювальна здатність. Для багатьох дата-центрів обмеження по амперажу та охолодженню обмежували реальну пропускну здатність більше, ніж «специфікації CPU». Tick‑tock не відміняв термодинаміку.
• Мітки безпеки змінили базову продуктивність. Після 2018 року міграції та оновлення мікрокоду ускладнили порівняння поколінь; деякі робочі навантаження отримали реальні накладні витрати.
• Конкуренти покращилися, поки Intel спотикався. Повернення AMD означало, що графік Intel більше не був графіком всієї індустрії.
• Паралелізм у ПЗ став множником. Коли прирости на ядро сповільнилися, загальна пропускна здатність дедалі більше залежала від кількості ядер і вміння ПЗ масштабуватися — часто найскладніша частина.

Де саме це зламалося: процес, фізика та виконання

Неприємна правда: «зменшення вузла» перестало бути легкою половиною

У ранні роки tick‑tock звуження процесу давало досить надійний пакет: менше енергії при схожій продуктивності або більше продуктивності при схожому енергоспоживанні. Це не магія; це геометрія, зменшення витоків, кращі матеріали та розмітка. Але коли вузли ставали меншими, все одночасно ускладнилося: патернінг, варіабельність, опір міжз’єднань і економічна ціна пошуку дрібних дефектів на великих пластинах.

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

Зрив ритму змінює стимули всіх стрічок униз за течією

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

• Купити поточне покоління знову, хоча планували його пропустити?
• Продовжити життя старого обладнання, збільшивши відмови й операційну рутину?
• Перемкнутися на іншого постачальника або платформу, взявши на себе роботу з кваліфікації і ризики?
• Реархітектурувати навантаження так, щоб воно потребувало менше CPU?

Tick‑tock приховував ці компроміси. Його занепад їх відкрив.

Мікроархітектурний підйом залежить від навантаження, і так було завжди

Ще одна причина, чому наратив tick‑tock згодом тріснув: ідея «наступне покоління на 20% швидше» — щонайкраще медіана по синтетичних або підібраних бенчмарках. У продакшені ваша продуктивність може бути прив’язана до одного каналу пам’яті, гарячої точки блокування, вибору планувальника ядра, глибини черги сховища або налаштувань інтеррупту NIC. Поліпшення мікроархітектури не виправляють погану конкурентність. Вони лише дозволяють їй провалитися швидше.

«Оптимізація» стала лінійкою продуктів, бо час на ринок має значення

Коли зриви ритму стали нормою, Intel — як і будь-яка велика інженерна організація — мусив щось випускати. Це часто означає ітеративну оптимізацію на стабільному процесі замість чистої alternation tick‑tock. Операційно це змінює підходи до кваліфікації нових серверів. «Оновлення» може бути скромним підйомом, а не великим стрибком. Ваш план тестування повинен бути чутливим до малих, але значущих регресій: джиттер, хвостова затримка, поведінка turbo під обмеженнями cgroup або аномалії perf під час міграцій безпеки.

Парафразована ідея (приписано James Hamilton): «Надійність походить від проєктування систем, які витримують відмови, а не від припущення, що компоненти або графіки не зламаються.»

Як спад tick‑tock змінив SRE і планування потужностей

Планування потужностей перейшло від «передбачуваного приросту» до «планування на випадок невизначеності»

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

Що робити: відмовтеся від однолінійного «N+1 швидший» планування на користь сценарного планування: найкращий випадок, очікуваний, гірший. Пов’язуйте кожен сценарій з планом пом’якшення (оптимізувати, масштабуватися горизонтально, змінити тип інстансу або вендора).

Закупівлі перестали бути «купити наступне» і стали функцією надійності

Команди закупівель раніше питали у інженерів: «Скільки серверів на наступний рік?» Тепер правильна відповідь часто виглядає як дерево: «Якщо ми отримаємо CPU покоління X до Q2 — план А; якщо ні — план Б з іншим SKU; якщо обмеження пов’язані з енергопостачанням — план В з іншою щільністю.»

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

Інженерія продуктивності стала чеснішою

Tick‑tock дозволяв багато лінивих підходів до продуктивності. Спад змусив команди зіткнутися з реальними вузькими місцями: алгоритмічною складністю, блокуванням, локальністю пам’яті, підсиленням I/O і тим, що деякі навантаження просто дорогі.

Це болісно. Але й звільняє. Коли припиняєш чекати магічного покоління CPU, починаєш вирішувати реальну проблему.

Безпека та оновлення мікрокоду стали частиною базової продуктивності

Ще один операційний зсув: продуктивність тепер — це не лише «апаратне + програмне», а «апаратне + програмне + мікрокод + міри пом’якшення». Ваш набір бенчмарків повинен включати реальні версії ядер, реальний мікрокод і вашу продукційну конфігурацію. Інакше ви купите дороге несподіване.

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

Міні‑історія №1: Інцидент через хибне припущення («наступне покоління нас врятує»)

Компанія: середній SaaS‑провайдер з піковими навантаженнями та стабільним зростанням. Платформа працювала на Java‑шарі, кешувальному шарі на кшталт Redis і шарі метаданих зі збереженням на сховище. Їхній план потужностей передбачав суттєве підвищення CPU у Q3. Воно було потрібно не для середнього навантаження — а для 99‑го процентиля пікових витрат під час пакетних завдань клієнтів.

Хибне припущення було тонким: вони вважали, що переживуть піки на наявному запасі до моменту оновлення. Вони відклали дві роботи: усунення глобального блокування в сервісі метаданих і зменшення CPU‑витрат на серіалізацію JSON.

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

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

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

Міні‑історія №2: Оптимізація, яка відкотилася («більше ядер вирішить це»)

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

Пропускна здатність покращилась на папері для частини навантажень. Потім інший клас задач почав пропускати дедлайни. Розслідування показало збільшення хвостової затримки і зниження ефективної продуктивності на ядро. CPU з більшою кількістю ядер працювали на нижчих all‑core turbo частотах під тривалим навантаженням, і підсистема пам’яті стала вузьким місцем. Більше ядер — більше конкуренції за пропускну здатність пам’яті і кеш, і деякі задачі стали повільнішими, бо чутливі до швидкості на потік.

Гірше: підвищення лімітів CPU в контейнерах збільшило ефекти «галасливих сусідів». Декілька агресивних задач захоплювали спільний LLC і пам’ять, позбавляючи інших ресурсів. Планувальник робив, що міг, але фізика була незворушною. Люди спочатку звинувачували нові CPU, потім Kubernetes, потім один одного. Класика.

Їм вдалося стабілізуватися, класифікувавши навантаження: задачі, чутливі до швидкості на потік, виділили в інший пул вузлів з іншим SKU і суворішими CPU‑лімітами; задачі, що вимагали пропускної здатності пам’яті, отримали налаштування числа потоків; додали моніторинг пропускної здатності пам’яті в механізм прийому ресурсів. «Оновлення» все ж допомогло в цілому, але тільки після відмови від простого припущення «ядра = швидкість».

Урок: кількість ядер — не універсальна валюта. Ваше навантаження платить у затримці, пропускній здатності пам’яті, локальності кешу і накладних витратах планувальника. Плануйте відповідно.

Міні‑історія №3: Нудна, але правильна практика, що врятувала день («тримайте кваліфікаційний конвеєр»)

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

Коли ритм постачальників почав хитатися, вони не панікували. У них вже був процес прийому: нові версії BIOS, новий мікрокод, нове ядро і нові SKU CPU запускалися в тому кластері з повторюваними тестами — гістограми затримки, лічильники perf, затримка сховища та поведінка потужності/тепла.

В одному циклі вони виявили, що оновлення BIOS змінило енергетичні ліміти і поведінку turbo, викликаючи помітне збільшення хвостової затримки під сплесками. Нічого «не було зламано», але їхній SLO‑запас зменшився. Оскільки вони виявили це рано, узгодили іншу конфігурацію BIOS і підкоригували правила розгортання до загального доступу.

Коли графік оновлення зірвався, вони просто продовжили купувати відоме‑хороше SKU і залишалися в межах енергопостачання/охолодження. Нудний конвеєр означав, що вони не ставили продукцію на надію — вони ставили її на дані.

Жарт №2: їхній кваліфікаційний кластер був таким нудним, що ніхто не хотів демонструвати його — поки він не запобіг Sev‑1, після чого став улюбленим «камінцем» усіх.

Швидкий план діагностики: що перевіряти першим/другим/третім

Це версія для on‑call. Ви не пишете дисертацію; ви намагаєтеся зупинити кровотечу і визначити обмежувальний ресурс за хвилини.

Перше: це насичення CPU чи блокування CPU?

• Перевірте використання CPU та чергу виконання: високе CPU зі значною чергою виконання вказує на справжнє насичення; низький CPU з високою затримкою вказує на блокування (I/O, блокування, тротлінг).
• Перевірте тротлінг: квоти cgroup, термічне тротлінг або енергетичні ліміти можуть імітувати «повільні CPU».

Друге: вузьке місце — пам’ять, I/O чи контенція?

• Тиск пам’яті: шукайте reclaim, активність swap, великі помилки сторінок. CPU може «працювати» на управлінні сторінками.
• I/O wait і затримки сховища: черги на дисках або мережевому сховищі проявляються як runnable‑потоки в очікуванні.
• Блокування: висока системна витрата часу, багато контекстних переключень або гарячі місця мьютексів на рівні застосунку можуть домінувати.

Третє: підтвердіть лічильниками та flame graphs

• Perf top / perf record: знайдіть гарячі функції і підтвердіть, чи ви compute‑bound чи затримані по пам’яті.
• Частота CPU і енергетичні ліміти: перевірте реальну поведінку частоти під навантаженням.

Четверте: порівняйте з відомою‑хорошою базою

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

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

Це «що робити прямо зараз?» завдання. Вони написані для Linux‑серверів у типовому середовищі дата‑центру. За потреби виконуйте від root.

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

cr0x@server:~$ lscpu | egrep 'Model name|Socket|Thread|Core|CPU\(s\)'
CPU(s):                          64
Thread(s) per core:              2
Core(s) per socket:              16
Socket(s):                       2
Model name:                      Intel(R) Xeon(R) Gold 6130 CPU @ 2.10GHz

cr0x@server:~$ dmesg | grep -i microcode | tail -n 3
[    0.412345] microcode: microcode updated early to revision 0x2000065, date = 2023-07-11
[    0.412678] microcode: CPU0: patch_level=0x2000065
[    0.413012] microcode: CPU1: patch_level=0x2000065

Значення: Ви точно знаєте, який силікон і мікрокод ви бенчмаркуєте. Мікрокод впливає на міри пом’якшення та іноді на продуктивність.

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

Завдання 2: Перевірити поточну поведінку частоти CPU (turbo, сигнали тротлінгу)

cr0x@server:~$ cat /proc/cpuinfo | awk -F: '/cpu MHz/{sum+=$2; n++} END{printf "avg MHz: %.0f\n", sum/n}'
avg MHz: 1895

Значення: Середня MHz нижча за очікувану базову/turbo під навантаженням або через політики енергозбереження.

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

Завдання 3: Перевірити cpufreq governor (за потреби)

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

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

Рішення: Для латентнісно‑критичних шарів розгляньте встановлення performance (після перевірки запасів по енергії/теплу).

Завдання 4: Перевірити середнє навантаження, чергу виконання та steal

cr0x@server:~$ uptime
 10:41:12 up 47 days,  3:18,  2 users,  load average: 62.21, 58.03, 41.77

cr0x@server:~$ mpstat -P ALL 1 3
Linux 6.1.0 (server) 	01/10/2026 	_x86_64_	(64 CPU)

10:41:19 AM  CPU   %usr %nice  %sys %iowait  %irq %soft  %steal %idle
10:41:20 AM  all   71.2  0.0   8.7   0.3     0.0  0.8    0.0    19.0
10:41:21 AM  all   72.1  0.0   9.1   0.2     0.0  0.7    0.0    17.9
10:41:22 AM  all   70.4  0.0   8.9   0.2     0.0  0.8    0.0    19.7

Значення: Високе навантаження з високим %usr вказує на насичення CPU; низький %iowait — не сховищевий вузький простір. Відсутність steal свідчить про те, що немає проблем з гіпервізором і шумними сусідами.

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

Завдання 5: Визначити топ‑споживачів CPU (швидка триажа)

cr0x@server:~$ ps -eo pid,comm,%cpu,%mem --sort=-%cpu | head
  PID COMMAND         %CPU %MEM
23104 java            612.3 18.1
18422 envoy           155.7  1.2
 9921 node             88.4  3.8
 4137 postgres         62.1  6.4

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

Рішення: Сфокусуйте профілювання на головному порушнику; не налаштовуйте випадкові параметри ядра «на всякий випадок».

Завдання 6: Виявити тротлінг cgroup (контейнери)

cr0x@server:~$ cat /sys/fs/cgroup/cpu.stat
usage_usec 178122938412
user_usec 162331112009
system_usec 15791826403
nr_periods 1831221
nr_throttled 421112
throttled_usec 11231398122

Значення: nr_throttled і throttled_usec великі: навантаження тротлиться CPU‑квотами.

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

Завдання 7: Перевірити тиск пам’яті та активність reclaim

cr0x@server:~$ vmstat 1 5
procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st
28  1      0  84212  90124 812344    0    0    12    45 9021 22133 71 10 18  1  0
31  0      0  79044  90124 810102    0    0    14    22 9104 23110 72  9 19  0  0
34  2      0  61012  90124 804991    0    0    11    31 9442 24998 69 12 17  2  0
35  3      0  33200  90124 799812    0    0    19    55 9901 27120 65 14 18  3  0
38  5      0  12044  90124 795103    0    0    21    61 10312 30002 61 16 18  5  0

Значення: Черга виконання (r) висока; вільна пам’ять падає; є певне блокування (b) і зростання переключень контексту. Ви наближаєтесь до тиску пам’яті, який може перетворити CPU на механізм пагінгу.

Рішення: Якщо зростають великі помилки/reclaim, зменшуйте використання пам’яті або додайте RAM; не припускайте, що «швидші CPU» виправлять тиск пам’яті.

Завдання 8: Перевірити swap і великі помилки сторінок явно

cr0x@server:~$ sar -B 1 3
Linux 6.1.0 (server) 	01/10/2026 	_x86_64_	(64 CPU)

10:42:31 AM  pgpgin/s pgpgout/s   fault/s  majflt/s  pgfree/s pgscank/s pgscand/s pgsteal/s    %vmeff
10:42:32 AM      0.00     62.00   9212.00     12.00  24120.00      0.00      0.00      0.00      0.00
10:42:33 AM      0.00     71.00   9440.00     15.00  25201.00      0.00      0.00      0.00      0.00
10:42:34 AM      0.00     58.00   9011.00     11.00  23210.00      0.00      0.00      0.00      0.00

Значення: Великі помилки (major faults) — нетривіальні; якщо вони зростатимуть, ви побачите сплески затримки і «марну» витрату CPU.

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

Завдання 9: Підтвердити затримку сховища і черги

cr0x@server:~$ iostat -xz 1 3
Linux 6.1.0 (server) 	01/10/2026 	_x86_64_	(64 CPU)

Device            r/s     w/s   rMB/s   wMB/s  rrqm/s  wrqm/s  %util  await  r_await  w_await
nvme0n1          12.0    48.0     1.2     9.8     0.0    22.0   94.1   18.4     4.1    22.0

Значення: Диск майже насичений (%util високе) і середній час очікування підвищений; ваш «CPU‑вузький» простір може насправді бути I/O‑чергуванням.

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

Завдання 10: Перевірити помилки та дропи мережі (приховане джерело затримки)

cr0x@server:~$ ip -s link show dev eth0
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP mode DEFAULT group default qlen 1000
    RX:  bytes packets errors dropped  missed   mcast
    98341234123 81234123      0   10231       0    1123
    TX:  bytes packets errors dropped carrier collsns
    77123123123 70123123      0    8221       0       0

Значення: Пропущені пакети можуть призводити до ретрансляцій, хвостової затримки і «таємничих» витрат CPU у мережевому стеку.

Рішення: Якщо під час інцидентів зростають дропи, перевірте черги NIC, налаштування драйвера і upstream‑конгестію. Оновлення CPU не вирішить втрату пакетів.

Завдання 11: Перевірити тиск планувальника і контекст‑switch

cr0x@server:~$ pidstat -w 1 3
Linux 6.1.0 (server) 	01/10/2026 	_x86_64_	(64 CPU)

10:43:22 AM   UID       PID   cswch/s nvcswch/s  Command
10:43:23 AM     0     23104   12010.0   22100.0  java
10:43:23 AM     0     18422    3100.0    9020.0  envoy
10:43:23 AM     0      4137     820.0    1100.0  postgres

Значення: Високі ненавмисні переключення контексту вказують, що потоки змушені передаватися — часто через CPU‑конкуренцію або блокування.

Рішення: Якщо nvcswch/s величезні, дослідіть кількість потоків, блокування і квоти cgroup перед тим, як додавати вузли.

Завдання 12: Знайти гарячі місця застосунку за допомогою perf (швидко)

cr0x@server:~$ sudo perf top -p 23104
Samples: 1K of event 'cycles', 4000 Hz, Event count (approx.): 250000000
  18.22%  java    libjvm.so           [.] SpinPause
  12.10%  java    libpthread-2.36.so  [.] pthread_mutex_lock
   9.44%  java    libjvm.so           [.] Unsafe_Park
   7.51%  java    libc-2.36.so        [.] memcpy

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

Рішення: Виправляйте конкурентність (sharding блокувань, зменшення критичних секцій), налаштуйте пул потоків або зменшіть спільний стан. Нові CPU не вирішать вечірку мьютексів.

Завдання 13: Перевірити розклад NUMA і чи немає крос‑сокетного thrashing

cr0x@server:~$ numactl --hardware
available: 2 nodes (0-1)
node 0 cpus: 0-15 32-47
node 0 size: 192000 MB
node 0 free: 41000 MB
node 1 cpus: 16-31 48-63
node 1 size: 192000 MB
node 1 free: 12000 MB

Значення: Пам’ять незбалансована; node 1 щільна. Може зростати віддалений доступ до пам’яті, що погіршить затримку.

Рішення: Якщо хвостова затримка корелює з NUMA‑дисбалансом, прив’язуйте процеси/алокатори або ребалансуйте навантаження між сокетами.

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

cr0x@server:~$ dmesg | egrep -i 'thrott|powercap|therm' | tail -n 5
[183112.991201] powercap_intel_rapl: package-0 domain package locked by BIOS
[183114.102233] CPU0: Core temperature above threshold, cpu clock throttled
[183114.102241] CPU0: Package temperature/speed normal

Значення: Ви буквально обмежені по теплу. Це не «поганий CPU», це обмеження середовища.

Рішення: Виправте охолодження, налаштування BIOS, криву вентиляторів або розміщення навантаження. Інакше ви купите швидші CPU і будете їх запускати повільніше.

Завдання 15: Порівняти стан мігрувань ядра (mitigations) для чутливих до продуктивності

cr0x@server:~$ grep . /sys/devices/system/cpu/vulnerabilities/* | head
/sys/devices/system/cpu/vulnerabilities/meltdown:Mitigation: PTI
/sys/devices/system/cpu/vulnerabilities/spectre_v1:Mitigation: usercopy/swapgs barriers and __user pointer sanitization
/sys/devices/system/cpu/vulnerabilities/spectre_v2:Mitigation: Retpolines; IBPB: conditional; IBRS_FW; STIBP: conditional

Значення: Міри пом’якшення увімкнені; вони можуть змінити продуктивність навантажень з інтенсивними викликами syscall або частими переключеннями контексту.

Рішення: Не порівнюйте бенчмарки між флотами з різним станом міри пом’якшення; стандартизуйте політику і вимірюйте вплив.

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

1) «Нові CPU повільніші»

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

Корінна причина: Енергетичні ліміти/налаштування BIOS знижують стійку частоту; більше ядер знижують all‑core turbo; навантаження чутливе до швидкості на потік.

Виправлення: Перевірте реальні частоти під продукційним навантаженням; відкоригуйте профілі BIOS; розділіть навантаження на пули per‑core і throughput; налаштуйте кількість потоків.

2) «CPU 60%, але затримка жахлива»

Симптом: CPU не завантажені, але p99 сплески затримки.

Корінна причина: Тротлінг cgroup, блокування, reclaim пам’яті або I/O‑чергування викликають блокування замість чистого насичення CPU.

Виправлення: Перевірте cpu.stat на тротлінг, виявляйте гарячі точки perf, vmstat на reclaim і iostat await. Виправляйте блокований ресурс, а не розмір CPU.

3) «Ми чекали наступного покоління і пропустили SLO»

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

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

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

4) «Бенчмарк показав 25% приросту, продакшн — 3%»

Симптом: Результати лабораторії не збігаються з реальністю.

Корінна причина: Бенчмарки запускалися з іншим ядром/мікрокодом, іншими мірами пом’якшення, нереалістичним I/O або без патернів конкуренції.

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

5) «Більше ядер виправило пропускну здатність, але збільшило джиттер»

Симптом: Середня продуктивність покращилась; p99/p999 погіршилися.

Корінна причина: Конкуренція «галасливих сусідів» за кеш/пам’ять; накладні витрати планувальника; поведінка GC змінюється з кількістю ядер.

Виправлення: Ізолюйте затримко‑чутливі навантаження; застосуйте контролі CPU/пропускної здатності пам’яті де можливо; налаштуйте GC і пул потоків під нову топологію.

6) «Флот ідентичний, але половина вузлів дивно поводиться»

Симптом: Той самий SKU, різна продуктивність, періодичний тротлінг.

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

Виправлення: Розглядайте прошивку як конфігурацію; уніфікуйте золотий BIOS/прошивку; перевірте розклад DIMM; відстежуйте термальну телеметрію; карантинуйте аномалії.

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

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

1. Інвентаризуйте реальність. Зафіксуйте модель CPU, мікрокод, ядро, BIOS, конфігурацію пам’яті, сховище і прошивку NIC. Без «приблизно однаково».
2. Побудуйте таксономію навантажень. Чутливі до затримки на потік, пакетні через пропускну здатність, зав’язані на пам’ять, I/O‑bound, змішані. Призначте відповідальних.
3. Визначте метрики успіху. Не «швидше». Використовуйте p50/p95/p99 затримку, вартість на запит, ватт на запит, швидкість спалювання бюджету помилок і моделі відмов.
4. Створіть кваліфікаційний пул. Невеликий, але завжди увімкнений. Запускайте канарний трафік або відтворення навантажень постійно.
5. Стандартизувати мікрокод + міри пом’якшення для тестів. Вимірюйте з політикою продакшну; документуйте відмінності.
6. Запускайте A/B при рівних енергетичних контурах. Якщо один SKU обмежений по енергії у ваших стійках, це важливіше за пікові характеристики.
7. Вимірюйте «нудні» обмеження. Потужність стійки, охолодження, оверсабскрипція top‑of‑rack, глибина черг сховища і топологія NUMA.
8. Майте план при відкладенні. Якщо наступне покоління не надійде, що ви купуєте? Яку оптимізаційну роботу пришвидшите? Яке управління попитом впровадите?
9. Розгортайте з запобіжними заходами. Канарка, потім 5%, потім 25%, потім решта. Гейтуйте за SLO і регресіями, а не за календарними датами.
10. Пишіть постмортем, навіть якщо все пройшло добре. Зафіксуйте несподіванки; це реєстр ризиків для наступного циклу.

Контрольний список: діагностика «очікували підйом, отримали нічого»

• Підтвердьте ідентичну версію ядра і параметри завантаження.
• Підтвердьте ревізію мікрокоду і стан міри пом’якшення.
• Перевірте профіль живлення BIOS, налаштування turbo і енергетичні обмеження.
• Перевірте коректне заповнення каналів пам’яті; перевірте NUMA.
• Порівняйте стійку частоту під реальним навантаженням, а не в режимі простою.
• Виміряйте затримку I/O і мережеві дропи під час тестів навантаження.
• Профілюйте гарячі місця: блокування, syscalls, memcpy, GC, помилки сторінок.
• Перевірте квоти CPU контейнерів і лічильники тротлінгу.
• Перезапустіть із тим самим набором запитів; підтвердіть, що це не дрейф навантаження.

Контрольний список: зменшення залежності від дорожньої карти (що зробити цього кварталу)

• Визначте топ‑3 сервісів, чиї плани потужностей залежать від «наступного покоління».
• Для кожного перелічіть топ‑3 драйвери витрат CPU і одну архітектурну альтернативу.
• Реалізуйте одну «дешеву перемогу» (серіалізація, кешування, батчинг, векторизація) і виміряйте її ефект.
• Додайте один жорсткий запобіжник (ліміти запитів, backpressure, межі черг), щоб запобігти штормам ретраїв.
• Створіть альтернативу постачальника/інстансу для кожного шару, навіть якщо ніколи її не використовуватимете.
• Зробіть відповідність прошивки/мікрокоду частиною перевірок здоров’я флоту.

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

1) Чи був tick‑tock справжньою інженерною дисципліною чи просто маркетингом?

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

2) Чому tick‑tock перестав працювати?

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

3) Чи завжди звуження процесу покращує продуктивність?

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

4) Якщо графік Intel ненадійний, чи варто уникати Intel?

Не впадайте в ідеологію. Займайтесь управлінням ризиками. Кваліфікуйте принаймні один альтернативний шлях (інший вендор, інший тип інстансу або інший клас апаратури). Потім купуйте те, що відповідає вашим потребам з найменшим операційним ризиком.

5) Як міри пом’якшення безпеки пов’язані з провалом tick‑tock?

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

6) Який операційний висновок для SRE команд?

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

7) Чи безпечна ставка на «більше ядер», коли прирости на ядро сповільнюються?

Тільки для навантажень, які масштабуются і не обмежені пропускною здатністю пам’яті. Для затримко‑чутливих шарів більше ядер може означати нижчу частоту на потік і більше конкуренції. Міряйте перед прийняттям рішення.

8) Як визначити, що ми обмежені потужністю або термічно у продакшні?

Шукайте нижчі за очікувані MHz під навантаженням, записи ядра про тротлінг і покращення продуктивності при зменшенні конкуренції. Якщо ваш дата‑центр на межі потужності/охолодження, технічна специфікація CPU — лише рекомендація.

9) Що концептуально замінило tick‑tock для планувальників?

Сценарне планування плюс безперервна кваліфікація. Замість припущення фіксованого ритму, припускайте варіативність і будуйте оперативну гнучкість: мульти‑SKU пули, ізоляцію навантажень і проекти ефективності.

10) Яка найвищопотужна зміна, якщо ми застрягли на старому поколінні?

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

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

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

Зробіть наступне:

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

Tick‑tock ніколи не був законом природи. Це була стратегія виконання. Проєктуйте свої системи так, ніби будь‑яка стратегія — ваша чи вендора — зрештою зустріне дедлайн, якого не зможе дотриматися.