Чи повернеться гонка тактових частот? Не так, як ви думаєте

November 6, 2025 • February 3, 2026 • Читання: 5 хв • Views: 0

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

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

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

Що означає «гонка тактових частот» у 2026 році

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

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

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

Буст-частота трактуються як бюджет, який можна витратити на короткий проміжок, а не як постійний стан.
Поведінка по ядрах важить більше, ніж «базовий такт». Ваш сервіс працює на тих ядрах, які йому дісталися.
Uncore-частоти (контролер пам’яті, міжз’єднання, LLC-слайси, fabric) можуть домінувати, якщо навантаження «пам’яттєво-орієнтоване».
Частоти прискорювачів (GPU/TPU/NPU) і їхні правила бусту/тротлінгу створюють власну «GHz-гру».
Системні частоти — це переговори: теплові ліміти, обмеження потужності, прошивка і планувальники всі торгуються щодо частоти.

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

Вісім фактів і історичний контекст, що реально допомагають

Це не факти для вікторини. Вони змінюють підхід до діагностики та закупівель.

Масштабування частоти вдарило в стіну частково тому, що закінчився закон Деннарда. Близько середини 2000-х зменшення транзисторів перестало давати пропорційне зниження потужності, тому вищі GHz стали тепловою проблемою.
«Міф про GHz» помер, але продуктивність в одній нитці нікуди не зникла. Закон Амдала продовжує діяти: навіть крихітні серіальні ділянки встановлюють верхню межу для прискорення.
Turbo/boost — це компроміс. Замість постійно вищих частот CPU почали опортуністично підвищувати частоту деяких ядер при наявності теплового/енергетичного запасу — саме та поведінка «залежить від умов», яку SRE так люблять і ненавидять одночасно.
Спекулятивне виконання стало важливою важільною точкою. Глибокі конвеєри і агресивна спекуляція підвищили пропускну здатність, але пізніші заходи щодо безпеки нагадали, що мікроархітектура — це також політика.
«Uncore» став фактором першого рангу. Для навантажень, залежних від пам’яті, підвищення GHz ядра може майже нічого не дати, якщо підсистема пам’яті та fabric не встигають.
NUMA перестав бути «нішею HPC» і став «кожним сервером». Багатосокетні та чіплетні дизайни зробили локальність критичною; ваша найгарячіша нитка може уповільнитися через віддалену пам’ять навіть при високій частоті.
Покоління PCIe змінили карту вузьких місць. Швидші канали допомогли, але також виявили нові межі: накладні витрати IOMMU, пом’якшення переривань і драйверні шляхи можуть домінувати для дрібного I/O.
Хмара зробила «тактову частоту» мультиорендною. Час викрадення CPU, управління потужністю і галасливі сусіди означають, що ваша спостережувана продуктивність може змінюватися без змін у коді.

Нова «GHz-гонка»: бусти, fabric і довгий хвіст

Буст-частоти — це не обіцянка; це переговори

Сучасні CPU охоче рекламують вражаючі буст-частоти. Це число не бреше, але й не є контрактом.
Бусти залежать від:

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

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

Ефективна частота важливіша за рекламну

Єдина частота, яка має значення — та, яку відчуває ваша нитка, поки виконує корисну роботу.
«Корисна» робота — це коли виконується важке завдання. «Не корисна» — коли нитка крутиться в пустоту на lock, чекає на пропуски кешу або чекає I/O.

Саме тому інженери продуктивності говорять про IPC (instructions per cycle) і cycles per instruction та розподіли причин простоїв.
Коли ядро витрачає цикли в очікуванні пам’яті, підвищення GHz лише збільшує швидкість, з якою воно очікує. Це не дуже надихаючий шлях апгрейда.

Uncore і пам’ять: тихі лімітери

У продакшені багато «проблем з CPU» насправді — це проблеми затримки пам’яті. Не пропускної спроможності — затримки.
Бази даних, кеші та сервіси часто виконують pointer chasing і пошук малих об’єктів.
Такі навантаження дуже чутливі до високої затримки доступу до пам’яті і віддалених NUMA-хопів.

Ваш CPU може буститись на героїчних частотах, поки критичний шлях стоїть на DRAM.
Ви побачите високе використання CPU, високий iowait (якщо залучено своп або paging) і посередню пропускну здатність.
Виправлення рідко полягає в «підвищенні частоти». Виправлення — локальність, менше промахів кеша, кращий макет даних і іноді більше каналів пам’яті або інший тип інстансу.

Прискорювачі — новий театр тактових частот

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

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

Де продуктивність справді упирається в продакшені

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

1) Одне гаряче ядро (і міф «у нас 64 ядра»)

У вашого сервісу може бути багато ниток, але один пункт серіалізації: глобальний lock, однонитковий event loop, фазa GC stop-the-world,
споживач черги, вузьке місце в TLS handshake, експортер метрик з мьютексом або клієнт бази даних, що робить синхронний DNS (так, таке ще трапляється).

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

2) Затримка пам’яті та локальність NUMA

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

3) Затримка зберігання: збирач податків p99

Зберігання — це місце, куди йдуть розповіді про «тактову частоту», щоб померти. Не тому, що зберігання повільне (сучасні NVMe швидкі),
а тому що варіабельність затримки — ваш ворог. Медіана 200µs і p99 8ms зіпсують вам день.

Складність: стрибки затримки зберігання можуть спричиняти прошивки garbage collection, проблеми з глибиною черги, журнальні операції файлової системи,
конкуренція CPU в блоці драйвера або просто один галасливий пристрій в RAID/ZFS vdev.

4) Мережеві мікросплески та черги

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

5) Накладні витрати ядра та віртуалізації

Інстанси в хмарі можуть мати CPU steal time, throttling або галасливих сусідів.
Контейнери можуть бути обмежені CPU. Ядро може витрачати час на softirq, облік cgroups або filesystem locks.
Буст-частота не вирішить хост, який просто не планує вашу роботу.

6) Обмеження потужності та теплові ліміти: продуктивність як функція ОВК

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

Одна цитата, щоб повісити над монітором, перефразована ідея від John Gall: «Складні системи, що працюють, зазвичай еволюціонують із простих систем, що працювали».

План швидкої діагностики: перше, друге, третє

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

Перше: класифікуйте проблему (затримка проти пропускної здатності, CPU проти очікування)

Це p99 затримка чи загальна пропускна здатність? Хвостова затримка часто вказує на черги, конкурентність, GC або варіабельність I/O.
Чи справді CPU зайнятий? Високий user time відрізняється від високого system time, що відрізняється від iowait або steal.
Щось змінилося? Деплой, оновлення ядра, прошивка, тип інстансу, клас зберігання, power cap, поведінка автоскейлера.

Друге: знайдіть чергу

Майже кожна проблема продуктивності — це якась черга:
run queue, disk queue, NIC queue, lock queue, connection pool queue, GC queue (так), черга бази даних.
Визначте домінуючу чергу — і ви визначили клас вузького місця.

Третє: підтвердіть одним «мікроскопом»

CPU: perf, flamegraphs, статистика планувальника.
Пам’ять/NUMA: numastat, perf stat (cache misses), page faults.
Диск: iostat -x, nvme smart-log, гістограми затримок файлової системи, якщо доступні.
Мережа: ss, ethtool -S, tc, показники дропів інтерфейсу, повторних передач.

Дванадцять+ практичних завдань: команди, виводи, рішення

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

Task 1: Check load and run queue pressure

cr0x@server:~$ uptime
 14:22:19 up 37 days,  3:11,  2 users,  load average: 18.42, 17.90, 16.05

Значення: load average значно вище за кількість ядер (або за звичний показник) вказує на чергу runnable-завдань, заблокований I/O або обидва.
Load включає задачі в непреривному I/O сні; не припускайте автоматично, що це «CPU load».

Рішення: Якщо load високий, негайно перевірте vmstat (run queue проти blocked) і iostat (черги диска).

Task 2: Separate runnable vs blocked tasks

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
12  3      0 821224  92124 3928120   0    0   128   512 6200 8900 42 10 33 13  2
15  4      0 810112  92124 3929008   0    0   256   768 6400 9200 44 11 28 15  2

Значення: r — runnable процеси; b — заблоковані (зазвичай I/O).
wa вказує час очікування на I/O; st вказує час steal (контенція у віртуалізації).

Рішення: Високий r з низьким wa вказує на конкуренцію за CPU.
Високий b/wa вказує на зберігання.
Високий st вказує на контенцію хоста/хмари — не звинувачуйте код, поки не перевірили це.

Task 3: Identify CPU frequency behavior (governor and current MHz)

cr0x@server:~$ grep -E 'model name|cpu MHz' /proc/cpuinfo | head -n 8
model name	: Intel(R) Xeon(R) CPU
cpu MHz		: 1799.998
model name	: Intel(R) Xeon(R) CPU
cpu MHz		: 3600.123
model name	: Intel(R) Xeon(R) CPU
cpu MHz		: 3599.876
model name	: Intel(R) Xeon(R) CPU
cpu MHz		: 1800.045

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

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

Task 4: Confirm CPU governor (and set expectations)

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

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

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

Task 5: Detect thermal throttling in logs

cr0x@server:~$ dmesg | grep -iE 'thrott|thermal|powercap' | tail -n 5
[123456.789] CPU0: Core temperature above threshold, cpu clock throttled
[123456.790] CPU0: Package temperature/speed normal

Значення: ядро повідомляє, що CPU не дозволено працювати на запитуваній частоті.

Рішення: Якщо тротлінг з’являється під час інцидентів, вирішіть проблему з охолодженням, кривими вентиляторів, рециркуляцією тепла або power cap.
Не «оптимізуйте код» навколо проблеми апаратного середовища.

Task 6: Find top CPU consumers and check per-thread behavior

cr0x@server:~$ top -H -b -n 1 | head -n 20
top - 14:23:02 up 37 days,  3:12,  2 users,  load average: 18.31, 17.88, 16.12
Threads: 842 total,  19 running, 823 sleeping,   0 stopped,   0 zombie
%Cpu(s): 44.1 us, 10.7 sy,  0.0 ni, 31.8 id, 12.0 wa,  0.0 hi,  0.4 si,  1.0 st
  PID USER      PR  NI    VIRT    RES    SHR S %CPU %MEM     TIME+ COMMAND
18231 app       20   0 4125588 512132  18932 R 198.7  3.2  12:40.11 api-worker
18244 app       20   0 4125588 512132  18932 R 197.9  3.2  12:39.66 api-worker

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

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

Task 7: Identify scheduler contention and context switching

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

14:23:21      UID       PID   cswch/s nvcswch/s  Command
14:23:22     1001     18231   1200.00    900.00  api-worker
14:23:22     1001     18244   1180.00    880.00  api-worker

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

Рішення: Якщо перемикань багато, зменшіть кількість ниток, виправте гарячі lock або дослідіть блокуючий I/O у «CPU-коді».

Task 8: Check disk latency and queue depth (the usual p99 villain)

cr0x@server:~$ iostat -x 1 3
Linux 6.5.0 (server) 	01/13/2026 	_x86_64_	(64 CPU)

Device            r/s     w/s   rkB/s   wkB/s  await  svctm  %util
nvme0n1         120.0   310.0  4096.0 12288.0   8.40   0.21  92.3
nvme1n1          15.0    20.0   512.0   768.0   0.65   0.09   3.1

Значення: await — середня затримка запиту; %util близько 100% вказує на насичення.
Високий await на одному пристрої з великою завантаженістю часто корелює з хвостовою затримкою додатку.

Рішення: Якщо один NVMe насичений, перевірте здоров’я пристрою і розміщення навантаження.
Розгляньте розподіл I/O, обережне збільшення queue depth або переміщення «гарячих» даних на менш зайнятий пристрій.

Task 9: Check filesystem and mount options for unintended sync behavior

cr0x@server:~$ mount | grep -E ' /var/lib| /data'
/dev/nvme0n1p2 on /var/lib/postgresql type ext4 (rw,relatime,data=ordered)
/dev/nvme1n1p1 on /data type xfs (rw,relatime,attr2,inode64,logbufs=8)

Значення: режим журналювання і вибір файлової системи впливають на затримки під навантаженням запису.
Деякі застосунки також випадково примушують синхронні записи (fsync на запит), перетворюючи зберігання на метроном.

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

Task 10: NVMe health and error counters

cr0x@server:~$ sudo nvme smart-log /dev/nvme0
Smart Log for NVME device:nvme0 namespace-id:ffffffff
critical_warning                    : 0x00
temperature                         : 61 C
available_spare                     : 100%
percentage_used                     : 7%
media_errors                        : 0
num_err_log_entries                 : 2

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

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

Task 11: Network retransmits and socket pressure

cr0x@server:~$ ss -s
Total: 1542
TCP:   1261 (estab 892, closed 298, orphaned 0, timewait 298)
Transport Total     IP        IPv6
RAW	  0         0         0
UDP	  23        21        2
TCP	  963       812       151
INET	  986       833       153
FRAG	  0         0         0

Значення: багато встановлених з’єднань може бути нормально; багато timewait може натякати на churn з’єднань.
Потрібно корелювати з повторними передачами і затримкою.

Рішення: Якщо churn з’єднань високий, використовуйте keep-alive/pooling або виправте налаштування балансувальника.
Якщо TCP має проблеми, перевірте помилки інтерфейсу і повторні передачі.

Task 12: Interface errors, drops, and driver pain

cr0x@server:~$ ip -s link show dev eth0
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9000 qdisc mq state UP mode DEFAULT group default qlen 1000
    RX:  bytes  packets  errors  dropped  missed   mcast
    9876543210  8765432       0      124       0    1234
    TX:  bytes  packets  errors  dropped  carrier collsns
    8765432109  7654321       0        9       0       0       0

Значення: дропи вказують на переповнення черг або проблеми драйвера/кільця. Навіть невеликі показники дропів можуть викликати велику хвостову затримку через повторні передачі.

Рішення: Якщо дропи зростають під час інцидентів, налаштуйте NIC ring buffers, дослідіть мікросплески або скоригуйте формування черг/shape трафіку.

Task 13: Check CPU steal time in cloud environments

cr0x@server:~$ mpstat 1 3
Linux 6.5.0 (server) 	01/13/2026 	_x86_64_	(64 CPU)

14:24:10 PM  CPU   %usr  %nice   %sys %iowait  %irq  %soft  %steal  %idle
14:24:11 PM  all  38.20   0.00  11.10   9.80  0.00   1.20    8.30  31.40

Значення: %steal — час, коли ваша VM хотіла CPU, але гіпервізор не запланував її. Це податок продуктивності, який ви не можете оптимізувати в аплікації.

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

Task 14: NUMA locality check

cr0x@server:~$ numactl --hardware
available: 2 nodes (0-1)
node 0 cpus: 0-31
node 1 cpus: 32-63
node 0 size: 257798 MB
node 0 free: 82122 MB
node 1 size: 257789 MB
node 1 free: 18012 MB

Значення: дисбаланс пам’яті — підказка, що алокації дрейфували і може відбуватися віддалений доступ.

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

Task 15: Page faults and reclaim behavior

cr0x@server:~$ vmstat -S M 1 3
procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st
10  1      0    802     90   3821    0    0    12    44 6100 8700 41 10 36 12  1
11  2      0    620     90   3950    0    0    16    60 6400 9100 43 11 29 16  1

Значення: скорочення вільної пам’яті і зростання I/O можуть вказувати на тиск reclaim. Навіть без swap, reclaim може псувати затримки.

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

Task 16: One quick CPU hotspot sample with perf

cr0x@server:~$ sudo perf top -p 18231
Samples: 1K of event 'cpu-clock', 4000 Hz, Event count (approx.): 251602844
  18.12%  api-worker  libc.so.6            [.] __memmove_avx_unaligned_erms
  11.07%  api-worker  libssl.so.3          [.] aes_gcm_enc_update
   7.44%  api-worker  api-worker           [.] json_parse

Значення: ви отримуєте швидкий вигляд, куди йде CPU-час. Тут домінують переміщення пам’яті, криптографія і парсинг JSON.

Рішення: Якщо час CPU витрачається в відомих бібліотеках, розгляньте конфігурацію (cipher suites), розміри payload, компресію або винесення роботи з критичного шляху.
Якщо гаряча точка — lock/спін, у вас проблема конкуренції, а не апгрейд CPU.

Три корпоративні міні-історії (анонімізовано, правдоподібно, болісно)

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

Середня SaaS-компанія перемістила чутливий до затримки API з старих інстансів на блискучі нові, рекламовані з вищими буст-частотами.
Команда очікувала зниження p99. Отримали протилежне: періодичні сплески і щотижневу «таємну регресію», що зникала й з’являлася.

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

Початкова відладка пішла звичним шляхом — зміни коду, тонке налаштування GC, правки connection pool.
Вони навіть бісекали реліз, який не мав відношення до сплесків. Справжній сигнал був у телеметрії апаратного забезпечення:
сплески корелювали з порогами температури і падінням ефективної частоти на найзавантаженіших ядрах.

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

Після виправлення середня затримка ледь змінилася. p99 покращився драматично.
Ось як працює продакшен: середній показник ввічливий; хвіст чесний.

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

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

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

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

Виправлення було нудним: вимкнути компресію для маленьких payload, обмежити рівень компресії і батчувати, де можливо.
Вони також закрепили робітників, що роблять компресію, на конкретних ядрах і переконалися, що сервіс не перепідписує нитки.
Компресія залишилася — просто не скрізь, не завжди і не на максимум «бо є».

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

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

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

Під час свят вони побачили зростання хвостової затримки і сплеск алертів «база даних повільна».
Перший рефлекс — масштабувати аплікаційні поди. Це допомогло на хвилин 15, потім стало гірше через зростання конкурентності I/O.

Архівні перевірки стали героєм. Порівняння поточних iostat та NVMe SMART логів з квартальним базлайном показало один диск з новим профілем температури
і невеликим, але зростаючим числом записів помилок. Він не ламався катастрофічно; він «ввічливо» деградував.

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

Урок негарний: тримайте базлайни і рукописи заміни. «Швидші CPU» — це план закупівлі, а не план реагування на інциденти.

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

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

1) Симптом: «CPU на 40%, значить це не CPU»

Корінь: одне ядро вичавлене або один lock серіалізує критичний шлях; загальний CPU виглядає «нормально».

Виправлення: перевірте CPU по нитках (top -H), перевірте run queue (vmstat), зробіть вибіркові зразки (perf top). Потім усуньте точку серіалізації або шардуйте.

2) Симптом: p99 сплески під час піків трафіку, але p50 стабільний

Корінь: чергування (connection pools, disk queues, NIC buffers) або паузи GC; бусти і тротлінг можуть це посилювати.

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

3) Симптом: нові «швидші» інстанси повільніші за старі

Корінь: різниця в затримці пам’яті/NUMA, нижчі стійкі частоти під power cap або інше підключення зберігання/мережі.

Виправлення: проганяйте бенчмарки, сфокусовані на SLO; перевірте ефективну частоту, steal time і локальність NUMA. Обирайте інстанси за стійковою поведінкою, а не за піковими маркетинговими числами.

4) Симптом: високий iowait, але вендор зберігання каже, що NVMe швидкий

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

Виправлення: перевірте з iostat -x, SMART-логи і затримку по пристрою. Зменшіть синхронні записи, розподіліть I/O або замініть підозрілий пристрій.

5) Симптом: інтермітентні таймаути мережі при низькій середній пропускній здатності

Корінь: мікросплески, що викликають дропи, bufferbloat або повторні передачі; іноді softirq-навантаження на CPU.

Виправлення: перевірте ip -s link, статистику NIC, повторні передачі і час softirq. Налаштуйте черги і pacing; не просто «додавайте каналів зв’язку».

6) Симптом: «Ми апгрейднули CPU і нічого не змінилося»

Корінь: навантаження залежить від пам’яті або I/O; CPU цикли не були обмежувальним фактором.

Виправлення: виміряйте причини простоїв (cache misses, page faults), disk await і мережеві дропи. Інвестуйте в те, що реально обмежує, а не в надію.

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

Корінь: governor/power cap зменшують вікна бусту; чутливі до затримки навантаження втрачають голову.

Виправлення: узгодьте політику живлення платформи з SLO; розділіть batch і критичні за затримкою робочі навантаження; моніторьте ефективну частоту і події тротлінгу.

8) Симптом: масштабування вшир збільшує затримку

Корінь: спільні бекенди насичуються (зберігання, БД, мережа) або зростає конкуренція (lock, thrash кеша).

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

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

Чекліст A: Перед тим, як купувати «швидші CPU»

Зберіть тиждень метрик p50/p95/p99 затримок і пропускної здатності для кожного endpoint.
Підтвердіть, чи ви CPU-bound, memory-bound, I/O-bound або network-bound, використовуючи vmstat, iostat, mpstat і один perf-зразок.
Визначте три топові черги і їх точки насичення (run queue, disk queue, connection pool).
Виміряйте ефективну частоту і події тротлінгу під реальним навантаженням (не в режимі idle).
Проведіть A/B канарку на кандидаті CPU/типі інстансу з тим самим класом зберігання і мережевого підключення.
Рішення приймайте на основі p99 і кількості помилок, а не середнього використання CPU.

Чекліст B: Коли p99 горить (режим інциденту)

Підтвердіть охоплення: одна AZ, один клас хостів, один endpoint, один орендар?
Запустіть vmstat 1 5 і mpstat 1 3: визначте CPU vs iowait vs steal.
Запустіть iostat -x 1 3: перевірте await і %util по пристроях.
Запустіть ip -s link і ss -s: перевірте дропи і churn з’єднань.
Перевірте логи тротлінгу/powercap (dmesg).
Зробіть один зразок perf top на гарячий PID, щоб підтвердити CPU-hotspots.
Застосуйте найменше безпечне пом’якшення: обмежте конкуренцію, скидьте навантаження, перемаршрутіть трафік, дренуйте погані вузли.
Лише тоді тюньте або відкочуйте зміни в коді.

Чекліст C: Проєктуйте під «частота — змінна»

Припускайте, що ефективна продуктивність на ядро флуктуїрує. Будуйте SLO і автоскейлінг з запасом.
Мінімізуйте глобальні lock і однониткові вузькі місця; вони підсилюють варіацію частоти.
Тримайте «гарячі» структури даних дружніми до кеша; враховуйте затримку пам’яті у бюджеті.
Використовуйте pooling і backpressure, щоб уникнути вибухового зростання черг.
Розділяйте batch і критичні за затримкою робочі навантаження на різні вузли або під суворою QoS.
Робіть квартальні базлайни продуктивності та після оновлень прошивки/ядра.

FAQ

1) Чи насправді повертається гонка тактових частот?

Не як «усі підуть з 3GHz до 6GHz назавжди». Вона повертається як динамічна частота: бусти, підвищення на рівні ядер
і настройка платформи, де частота — лише один регулятор серед багатьох.

2) Чи цікавитися базовим чи буст- кліком при купівлі серверів?

Дбайте про тривалу ефективну частоту під вашим навантаженням. Буст-частота — це найкращий випадок.
Базова частота часто консервативна. Ваш SLO мешкає в брудному середовищі посередині.

3) Яка найпоширеніша причина, чому «швидший CPU» не допомагає?

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

4) Як швидко відрізнити CPU-bound від memory-bound?

Почніть з vmstat (r проти wa) і швидкого perf top.
Якщо бачите багато часу в операціях копіювання пам’яті і високі простої через cache-miss (або додаток робить pointer-chase), підозрюйте затримку пам’яті і локальність.

5) Чи допомагає вища GHz базам даних?

Іноді. У баз даних часто є однониткові компоненти (log writer, деякі lock manager), де важлива продуктивність на ядрі.
Але багато вузьких місць бази даних — це затримка зберігання, hit rate буфер-кеша або конкуренція lock. Вимірюйте перед покупкою.

6) Чи GPU — частина нової гонки тактових частот?

Так, і вони ще чутливіші до енергетичних та теплових обмежень. Також продуктивність GPU часто обмежена пропускною здатністю пам’яті,
формою ядра і передачею хост→пристрій по PCIe чи fabric — не лише частотою.

7) Чому в хмарі продуктивність варіюється навіть на одному типі інстансу?

CPU steal time, управління потужністю хоста, галасливі сусіди і варіації в підключеннях зберігання/мережі.
Слідкуйте за %steal, дропами і затримками зберігання; вважайте «той самий тип» за «схожий контракт», а не ідентичний хардвер.

8) Якщо частоти змінні, чи варто відключити scaling?

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

9) Яка найкорисніша ментальна модель для дебагу продуктивності?

Знайдіть чергу. Коли ви знаєте, що в черзі — runnable завдання, дискові запити, мережеві пакети чи чекери lock — ви знаєте, з чим боретеся.

Висновок: що робити в понеділок вранці

Гонка тактових частот повертається, але це не пряма лінія і не шлях для скорингу закупівель.
У продакшені ефективна продуктивність узгоджується між теплом, обмеженнями потужності, планувальниками, локальністю пам’яті та варіабельністю I/O.
Ви не переможете, ганяючись за GHz. Ви переможете, виявивши чергу і зменшивши хвіст.

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

Виберіть один критичний сервіс і проганяйте «режим інциденту» в спокійний день. Збережіть базлайн.
Додайте панель в дашборд для %steal, iowait, disk await, NIC drops і подій тротлінгу.
Проведіть контрольовану канарку, порівнюючи типи інстансів під реальним трафіком, оцінюючи по p99 і кількості помилок.
Запишіть три найважливіші точки серіалізації і плануйте їх як баги, а не як «проєкти продуктивності».
Проговоріть незручну істину: якщо ваш SLO вимагає послідовної продуктивності, розглядайте потужність і охолодження як частину платформи, а не як післядумку.