Як читати CPU-бенчмарки, щоб вас не обвели

Що насправді вимірюють бенчмарки CPU (і чого вони не показують)

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

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

Три рівні: кремній, система й навантаження

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

• Можливості кремнію: IPC, частота, ієрархія кешів, векторні блоки, передбачення переходів, кількість ядер.
• Доставка системи: налаштування BIOS/UEFI, ліміти потужності, охолодження, швидкість і канали пам’яті, топологія NUMA, ядро і мікрокод, накладні витрати віртуалізації.
• Поведінка навантаження: мікс інструкцій, рівень розгалуженості, слід кеша, конкуренція за локи, системні виклики, очікування IO, паузи GC, серіалізація, блокування одного потоку.

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

Питання до бенчмарка, які слід задати першими

• Що є вузьким місцем у бенчмарку? Обчислення, пропускна спроможність пам’яті, латентність пам’яті, кеш, передбачення переходів чи щось інше?
• Чи обмежується він одним потоком чи паралельний? Чи масштабується він з ядрами або впирається в серіальний бар’єр?
• Які набори інструкцій використовуються? AVX2, AVX-512, AMX, NEON — вони можуть драматично і нерівномірно змінювати результати на різних CPU.
• Яке середовище виконання? Версія ОС, ядро, мікрокод, компілятор, енергетична політика, поведінка turbo, налаштування BIOS.
• Яка метрика? Пропускна спроможність, час виконання, операцій за секунду, запитів за секунду чи власне «оцінка»?

Якщо діаграма цього не відповідає — це не бенчмарк-діаграма. Це атмосфера.

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

Бенчмарки — місце, куди надія приходить одягнутись у математику. Не дозволяйте їй.

Факти й історичний контекст, що змінюють читання діаграм

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

1. Швидкість годинника перестала бути чистим показником у середині 2000-х. «Гонка GHz» натрапила на щільність потужності й теплові обмеження; IPC, кеші й паралелізм стали вирішальними факторами.
2. Бенчмарки SPEC довго визначали закупівлі. Набори SPEC CPU були створені для стандартизації порівнянь, але вони все ще чутливі до компіляторів, прапорів і налаштувань.
3. Turbo/boost перетворив «частоту CPU» з константи на переговори. Сучасні CPU нагло підвищують частоту в залежності від температури, потужності й струму; два ідентичні CPU можуть дати різні результати за різного охолодження й лімітів потужності.
4. Векторні набори інструкцій створили «прірви продуктивності». Навантаження AVX2/AVX-512 можуть спричиняти зниження частоти на деяких CPU; «найшвидший» CPU в скалярному коді може спіткнутися під сильними векторами, або навпаки.
5. Hyper-threading/SMT змістили поняття «кількість ядер». Логічні CPU не є справжніми ядрами. SMT може допомогти пропускній спроможності, погіршити хвостову затримку або водночас робити й те, й інше.
6. NUMA став нормою в серверах. Багатосокетні та chiplet-дизайни вводять нерівномірний доступ до пам’яті; «більше ядер» може означати «більше міжчіпових затримок», якщо планування погане.
7. Міри безпеки зробили старі бенчмарки застарілими. Міри в ядрі і мікрокоді проти бокових каналів змінили навантаження з великою кількістю системних викликів і перемикань контексту.
8. Хмарні CPU перетворили бенчмарки у «поведінку інстансу». Шумні сусіди, планування vCPU, обмеження turbo і кредити CPU означають, що одна й та сама тип інстансу може бенчмаркитись по-різному в різний час.

Це не дрібниці. Саме через це ваші улюблені «рейтинги CPU» регулярно не прогнозують продуктивність у продакшні.

Класичні способи, як вас обводять маркетингові бенчмарки

1) Бенчмарк використовує набори інструкцій, якими ваше навантаження не користується

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

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

2) Бенчмарк поміщається в кеш; ваше навантаження — ні

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

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

3) Turbo робить «продуктивність одного ядра» рухомою метою

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

Що робити: Шукайте стійку частоту під навантаженням і ліміти потужності (PL1/PL2), а не лише пік.

4) Різниці в конфігурації пам’яті приховані

Бенчмарки можуть бути «порівняннями CPU», де в одної системи заповнено менше каналів пам’яті, повільніші DIMM, інші ранги або інша інтерлівація пам’яті в BIOS. Якщо бенчмарк торкається пам’яті, це не дрібниця — це результат.

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

5) SMT/HT увімкнено для одного запуску і вимкнено для іншого

Деякі навантаження обожнюють SMT; інші отримують гіршу хвостову затримку, бо два логічні CPU борються за ресурси ядра. Порівнювати показники без парності SMT — принаймні неохайно.

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

6) «Оцінка» приховує розподіл

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

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

7) «Той самий CPU» — не той самий CPU

Оновлення мікрокоду, ревізії stepping, різні значення потужності за замовчуванням і оновлення BIOS від постачальника можуть суттєво вплинути на поведінку. Навіть у рамках одного SKU.

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

Як зіставити результати бенчмарків із вашим навантаженням: практичний переклад

Правильне читання CPU-бенчмарків — це не поклоніння «кращому балу», а зіставлення бенчмарка з вашим вузьким місцем. Ви можете це зробити без ступеня PhD. Потрібно лише ставити правильні питання і відмовлятися сприймати одне число як ідентичність.

Крок 1: Класифікуйте ваше навантаження за обмеженнями

• Обмежене одним потоком: багато серіальної роботи, локів, основний цикл подій, один потік обробки запитів, зупинки GC.
• Легко паралельне: рендеринг, кодування, пакетні ETL-трансформації, незалежна робота на запит.
• Обмежене пропускною спроможністю пам’яті: аналітичні сканування, in-memory колонкова обробка, великі hash join.
• Чутливе до латентності пам’яті: перехресні посилання, графові навантаження, пошук ключ-значення, OLTP з промахами кеша.
• IO-зав’язане з CPU-спайками: сервіси, що важко працюють зі сховищем, компактація, контрольні суми, шифрування, стиснення.
• Ядро/мережа інтенсивні: обробка пакетів, термінація TLS, великий рівень системних викликів.

Крок 2: Визначте вашу метрику: пропускна спроможність, затримка чи вартість

У корпоративних дискусіях зазвичай говорять про пропускну спроможність («більше запитів/сек»). Операційна команда часто дбає про хвостову затримку під навантаженням. Фінанси дивляться на $/запит. Це різні пріоритети й вони не обирають той самий CPU.

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

Крок 3: Пов’язуйте категорії бенчмарків з реальними рішеннями

Ось переклад, який допоможе закупівлі та плануванню ємності:

• Бенчмарк одного ядра: проксі для вузьких місць одного потоку, серіалізації запитів, пауз GC і «одного гарячого локу». Якщо це низько — додаткові ядра не допоможуть.
• Бенчмарк багатоядерної пропускної спроможності: проксі для пакетних задач, паралельних сервісів і агрегованої продуктивності. Слідкуйте за ефективністю масштабування: чи подвоєння ядер дає 1.9× або 1.2×?
• Бенчмарки пам’яті: проксі для аналітики, шарів кешування і будь-чого з великими робочими множинами. Оцінки CPU вам не допоможуть, якщо бракує пропускної спроможності пам’яті.
• Змішані набори додатків: кращі за мікробенчмарки, але все ще не ваше застосування. Вони корисні для рішення «цей CPU у правильному районі».

Крок 4: Відмовляйтесь від несправедливих порівнянь

Чесне порівняння CPU тримає постійним:

• Заповнення каналів пам’яті рівнозначне; однакова швидкість DIMM і ранги
• Те саме сховище і версія ядра
• Ті самі налаштування живлення BIOS і політика turbo
• Той самий сімейний тип компілятора і прапори (якщо релевантно)
• Те саме охолодження і повітряний потік шасі
• Той самий режим віртуалізації (bare metal проти VM)

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

Швидкий план діагностики: знайдіть вузьке місце, перш ніж сперечатися про CPU

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

Перше: CPU зайнятий чи просто запланований?

• Перевірте загальну завантаженість CPU і довжину черги виконання.
• Перевірте iowait і steal time (VM).
• Перевірте «гарячі» ядра (одне ядро завантажене на 100%).

Друге: Чи тротлить CPU?

• Шукайте падіння частоти під навантаженням.
• Шукайте події термального або потужнісного обмеження.
• Перевірте політику governor.

Третє: Чи є пам’ять справжнім обмежувачем?

• Перевірте великі сторінкові помилки, підкачку і зупинки через тиск пам’яті.
• Перевірте NUMA-дисбаланс і доступ до віддаленої пам’яті.
• Перевірте симптоми насичення пропускної спроможності пам’яті.

Четверте: Чи серіалізовано навантаження?

• Шукайте конкуренцію за локи, насичення одного потоку або один гарячий процес/потік.
• Перевірте метрики додатка: глибина черги, насичення пулу потоків, GC.

П’яте: Підтвердіть контрольованим мікротестом

• Запустіть відтворюваний CPU-тест на тій самій машині зі стабільними налаштуваннями.
• Порівняйте частоту, perf-лічильники (якщо доступні) і поведінку масштабування.

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

Практичні завдання: 12+ команд для перевірки продуктивності CPU на реальному сервері

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

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

cr0x@server:~$ lscpu
Architecture:                         x86_64
CPU(s):                               64
On-line CPU(s) list:                  0-63
Thread(s) per core:                   2
Core(s) per socket:                   16
Socket(s):                            2
NUMA node(s):                         2
Model name:                           Intel(R) Xeon(R) Gold 6338 CPU @ 2.00GHz
CPU max MHz:                          3500.0000
CPU min MHz:                          800.0000

Що це означає: Тепер ви знаєте топологію. Thread(s) per core показує SMT/HT. Socket(s) + NUMA node(s) показують, що локальність пам’яті має значення.

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

Завдання 2: Перевірте поточну частоту CPU та governor (чи в машині «powersave»?)

cr0x@server:~$ cpupower frequency-info
analyzing CPU 0:
  driver: intel_pstate
  CPUs which run at the same hardware frequency: 0
  available cpufreq governors: performance powersave
  current policy: frequency should be within 800 MHz and 3500 MHz.
                  The governor "powersave" may decide which speed to use
  current CPU frequency: 1200 MHz

Що це означає: Якщо governor — powersave і CPU сидить на 1.2 GHz під навантаженням, ваш «бенчмарк» випадково стає демо енергозбереження.

Рішення: Для тестування продуктивності встановіть governor performance (з контролем змін і увагою до потужності/теплових умов).

Завдання 3: Переключити на performance governor (тимчасово, для тестування)

cr0x@server:~$ sudo cpupower frequency-set -g performance
Setting cpu: 0
Setting cpu: 1
Setting cpu: 2
Setting cpu: 3

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

Рішення: Якщо в продакшні політика — powersave, тестуйте і в цьому режимі. Не купуйте CPU, покладаючись на режим, у якому ви не будете працювати.

Завдання 4: Помітити steal time віртуалізації (в хмарі «vCPU зайнятий десь інде»)

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

12:00:01 PM  CPU   %usr  %nice  %sys %iowait  %irq  %soft  %steal  %idle
12:00:02 PM  all   45.20   0.00  7.10    0.40  0.00   0.30   8.50  38.50
12:00:03 PM  all   46.10   0.00  7.40    0.30  0.00   0.40   8.20  37.60

Що це означає: %steal — це час, коли ваша VM хотіла CPU, але гіпервізор її не запланував.

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

Завдання 5: Перевірити load average проти фактичного насичення CPU

cr0x@server:~$ uptime
 12:01:10 up 32 days,  4:12,  2 users,  load average: 48.20, 44.10, 39.77

Що це означає: Load average рахує runnable-задачі й певні заблоковані стани; це не «відсоток CPU». На 64-vCPU хості load ~48 може бути нормою або ознакою конкуренції залежно від вимог до затримки.

Рішення: Поєднайте це з аналізом черги виконання та по-потоковим аналізом. Не купуйте CPU, дивлячись лише на скріншоти load average.

Завдання 6: Спостерігати run queue і затримки CPU (сучасно, корисно)

cr0x@server:~$ cat /proc/pressure/cpu
some avg10=12.45 avg60=10.22 avg300=8.01 total=1234567890
full avg10=3.10 avg60=2.05 avg300=1.20 total=234567890

Що це означає: PSI показує час, коли задачі чекали CPU. full означає, що система була повністю насичена для цих задач.

Рішення: Високий PSI при нормальному трафіку вказує на реальну конкуренцію за CPU. Тоді апгрейд CPU або оптимізація навантаження — виправдані дії.

Завдання 7: Визначити, чи проблема CPU насправді IO wait

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

avg-cpu:  %user %nice %system %iowait  %steal   %idle
          12.10  0.00    3.20   28.50    0.00   56.20

Device            r/s     w/s   r_await  w_await  aqu-sz  %util
nvme0n1         120.0   200.0     8.20    15.40   12.30   98.00

Що це означає: %iowait високий; %util диска ~98%. Ваші CPU нудьгують, чекаючи сховище.

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

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

cr0x@server:~$ sudo dmesg | grep -i -E "thrott|thermal|powercap" | tail -n 5
[123456.789012] CPU0: Package temperature above threshold, cpu clock throttled
[123456.789123] CPU0: Core temperature/speed normal

Що це означає: Система тротлила частоти CPU через температуру.

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

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

cr0x@server:~$ sudo turbostat --quiet --Summary --interval 5 --num_iterations 3
Avg_MHz  Busy%  Bzy_MHz  PkgTmp  PkgWatt
2850     72.10  3950     83      205.30
2710     74.40  3640     86      205.00
2550     76.80  3320     89      205.10

Що це означає: Зі зростанням температури ефективна частота знижується. CPU обмежено по потужності (~205W) і термічно навантажено.

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

Завдання 10: Перевірити NUMA-топологію і локальність пам’яті

cr0x@server:~$ numactl --hardware
available: 2 nodes (0-1)
node 0 cpus: 0-31
node 0 size: 257696 MB
node 0 free: 201234 MB
node 1 cpus: 32-63
node 1 size: 257696 MB
node 1 free: 198765 MB
node distances:
node   0   1
  0:  10  21
  1:  21  10

Що це означає: Доступ до віддаленої пам’яті дорожчий (distance 21 vs 10). Деякі бенчмарки ховають це, оптимально роблячи pin; ваш планувальник може цього не робити.

Рішення: Для чутливих до затримки сервісів прив’язуйте процеси/потоки й пам’ять до NUMA-вузла або забезпечте, щоб додаток був NUMA-усвідомлений.

Завдання 11: Спостерігати тиск пам’яті і підкачку (CPU виглядає повільним, коли пам’ять у вогні)

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  524288  10240  1200  45000  200  180   900  1200 9000 15000 35 10  5 50  0

Що це означає: Підкачка (si/so) і високий IO wait означають, що CPU чекає на сторінки та IO, а не виконує обчислення.

Рішення: Додайте RAM, виправте витоки пам’яті, налаштуйте кеші або зменшіть робочу множину. Не купуйте швидший CPU, щоб вирішити проблему повільної підкачки.

Завдання 12: Перевірити, які потоки реально споживають CPU (знайти гарячий потік)

cr0x@server:~$ top -H -p 24811
top - 12:05:01 up 32 days,  4:16,  2 users,  load average: 48.20, 44.10, 39.77
Threads:  96 total,   1 running,  95 sleeping,   0 stopped,   0 zombie
%Cpu(s):  98.0 us,  2.0 sy,  0.0 ni,  0.0 id,  0.0 wa,  0.0 hi,  0.0 si,  0.0 st

  PID   TID USER      PR  NI    VIRT    RES    SHR S  %CPU  %MEM     TIME+ COMMAND
24811 24837 app       20   0  5220m  1200m  32000 R  100.0   6.0  10:22.11 app-main

Що це означає: Один потік завантажений на повну. Ваш сервіс може бути обмежений одним потоком навіть на 64-vCPU машині.

Рішення: Зосередьтесь на профілюванні і зменшенні серіалізації/конкуренції за локи перед тим, як купувати додаткові ядра.

Завдання 13: Підтвердити статус SMT/HT і подумати про відключення для латентності

cr0x@server:~$ cat /sys/devices/system/cpu/smt/active
1

Що це означає: SMT активний.

Рішення: Для чутливих до затримки навантажень протестуйте з вимкненим SMT (BIOS або керування ядром), виміряйте p99. Пропускна спроможність може впасти; зате латентність може покращитися. Вирішуйте на підставі даних.

Завдання 14: Швидкий і простий тест пропускної спроможності CPU (не догма, а перевірка)

cr0x@server:~$ sysbench cpu --threads=32 --cpu-max-prime=20000 run
CPU speed:
    events per second:  1245.67

General statistics:
    total time:                          10.0003s
    total number of events:              12459

Що це означає: Це мікробенчмарк обчислень. Він чутливий до частоти і поведінки планувальника, а не до вашої схеми БД.

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

Завдання 15: Виміряти лічильники продуктивності по ядрах (коли потрібні докази, а не атмосфера)

cr0x@server:~$ sudo perf stat -a -- sleep 10
 Performance counter stats for 'system wide':

        1,234,567,890      cycles
          987,654,321      instructions              #    0.80  insn per cycle
            12,345,678      cache-misses
            98,765,432      branches
             1,234,567      branch-misses            #    1.25% of all branches

      10.001234567 seconds time elapsed

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

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

Завдання 16: Підтвердити, що ядро не змушує консервативну поведінку планувальника

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

Що це означає: Governor встановлено як очікувалось.

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

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

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

Міні-історія 1: Інцидент через неправильне припущення (одноядерний vs «більше ядер допоможе»)

Середня SaaS-компанія зазнала регресії видимої для клієнтів після релізу функції. На колі надійшли повідомлення про використання CPU близько 55–65% на API-вузлах. Керівництво почуло «CPU трохи високий» і затвердило більший тип інстансу з більшою кількістю vCPU. Подвоєні ядра. Проблема вирішиться, правда?

Перше розгортання нічого не дало. p99 залишився поганим. Потім під час піку стало гірше. Більші інстанси мали складнішу NUMA-архітектуру і трохи гіршу буст-поведінку під тривалим навантаженням. Їхній найгарячіший шлях запиту містив серіалізований крок: лок навколо спільної in-memory структури, що охороняє наповнення кеша. Під конкуренцією один потік став метрономом для всього сервісу.

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

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

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

Міні-історія 2: Оптимізація, що обернулася проти (AVX-важкий приріст, що спричинив тротлінг)

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

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

Гірше, термальна поведінка варіювалася за шасі та місцем у стійці. Ідентичні SKU поводилися по-різному залежно від потоку повітря. «Оптимізований» pipeline перетворився на лотерею продуктивності, і on-call навчився різниці між піком і тривалим виконанням болісно.

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

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

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

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

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

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

Дедлайни перестали зсуватися. Команда виглядала параноїдально в тихих тижнях і пророче в зайняті — що, по суті, опис роботи SRE.

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

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

1) Симптом: «Бенчмарк каже на 30% швидше, але в продакшні те саме»

Корінна причина: Навантаження IO-зав’язане або серіалізоване; CPU ніколи не був обмежувачем.

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

2) Симптом: «Новий CPU швидкий у коротких тестах, повільний у довгих»

Корінна причина: Теплове/потужнісне тротлінгування; turbo добре виглядає 30 секунд, а потім приходить реальність.

Виправлення: Використайте turbostat для спостереження стійкого MHz і пакету потужності. Покращіть охолодження, налаштуйте ліміти потужності або виберіть SKU з тривалою продуктивністю, що відповідає шасі.

3) Симптом: «Мульти-ядерний бал відмінний, але затримка погіршилась»

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

Виправлення: Бенчмаркуйте p99, а не лише пропускну спроможність. Тестуйте з SMT вимкненим. Застосуйте механізми зворотного тиску та балансування ємності залежних компонентів.

4) Симптом: «Та сама модель CPU, різна продуктивність на серверах»

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

Виправлення: Стандартизувати профілі BIOS; перевірити заповнення каналів пам’яті; відслідковувати мікрокод; базувати частоту під навантаженням; налаштувати аларми на тротлінг.

5) Симптом: «Бенчмарки інстансів в хмарі сильно варіюють день у день»

Корінна причина: Шумні сусіди, steal time, гетерогенність хостів, кредитна модель або обмеження turbo.

Виправлення: Виміряйте %steal, використайте виділену оренду або bare metal для стабільної продуктивності, а також запускайте довші тести, що схоплять поведінку щодо тротлінгу/кредитів.

6) Симптом: «Використання CPU низьке, але запити повільні»

Корінна причина: Потоки блокуються на IO, локах, сторінкових помилках або затримках планувальника; проста низька завантаженість CPU не означає, що сервіс здоровий.

Виправлення: Використайте PSI (/proc/pressure/*), vmstat і по-потокову інспекцію. Виявте заблокований ресурс і виправте його.

7) Симптом: «Після оптимізації пропускна здатність зросла, але дедлайн завдання пропущено»

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

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

8) Симптом: «Бенчмарк A каже CPU X кращий; бенчмарк B каже CPU Y кращий»

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

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

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

Чекліст A: Читати діаграму бенчмарка як доросла людина

1. Знайдіть умови запуску: модель CPU, BIOS, конфігурація пам’яті, ОС/ядро, компілятор, енергетичний профіль. Якщо відсутні — довіра падає.
2. Визначте вузьке місце: обчислення vs пам’ять vs кеш vs IO. Якщо невідомо — вважайте оцінку непереносимою.
3. Перевірте поведінку масштабування: чи лінійно масштабується багатоядерна продуктивність? Якщо ні — чому?
4. Шукайте стійку поведінку: довгі запуски, стійка частота, примітки щодо потужності/тепла.
5. Попросіть про варіативність: кілька запусків, інтервали довіри або хоча б min/median/max. Якщо нічого — припускайте вибірковість.
6. Зіставте з вашим навантаженням: одноядерний, паралельний, пам’ять-обмежений, чутливий до затримки, інтенсивний для віртуалізації.
7. Переведіть у рішення: обирайте CPU для вашого вузького місця, а не для таблиці лідерів.

Чекліст B: План оцінки CPU до покупки (практично, не театрально)

1. Запишіть ваші топ-3 обмеження: p99 затримка, пропускна спроможність, вартість за запит, час завершення задачі або бюджет потужності.
2. Оберіть 2–3 репрезентативні тести: один мікро (саніті), один проксі-додаток, один end-to-end навантаження (або відтворення у стейджингу).
3. Визначте стабільні умови тесту: governor, політика turbo, зафіксований профіль BIOS, узгоджена конфігурація пам’яті, ізольований хост коли можливо.
4. Запускайте досить довго, щоб досягти стійкого стану: щонайменше 10–30 хвилин для теплових/потужнісних ефектів; довше, якщо є кредити/шумні сусіди.
5. Фіксуйте: частоту в часі, логи тротлінгу, PSI, чергу виконання, хвостову затримку та помилки.
6. Порівнюйте за ефективністю: продуктивність на ват і на долар, а не лише абсолютний показник.
7. Робіть рішення з урахуванням вашого вузького місця: якщо обмежує одноядерний, пріоритет — стійка одноядерна продуктивність; якщо пакетні задачі — пріоритет масштабу та пропускної спроможності пам’яті.

Чекліст C: Після розгортання валідація (бо закупівля — це не кінець)

1. Базуйте новий флот: зафіксуйте lscpu, governor, частоту під навантаженням і невеликий стандартизований CPU-тест.
2. Перевірте розміщення NUMA: переконайтеся, що сервіс випадково не тротлить віддалену пам’ять.
3. Налаштуйте аларми на тротлінг: термальні/потужнісні події, стійке падіння частоти і несподівані зміни governor.
4. Спостерігайте p99 насамперед: покращення пропускної спроможності, що погіршує хвостову затримку, — прихована регресія.

ЧАСТІ ПИТАННЯ

1) Чи завжди вищий бенчмарк одного ядра краще для затримки?

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

2) Чи потрібен мені AVX-512 (або інші широкі вектори) для серверних навантажень?

Лише якщо ваше навантаження використовує його значущо: стиснення, криптографія, деяка аналітика, ML inference, мультимедіа. Інакше це переважно трофей у специфікації. Також врахуйте поведінку щодо потужності/тротлінгу під важким використанням векторів.

3) Чому рейтинги ігрових CPU не прогнозують серверну продуктивність?

Ігри часто чутливі до швидкості одного потоку і поведінки кеша у дуже специфічних випадках, і GPU часто домінує. Сервери дбають про стійку пропускну спроможність, хвостову затримку, NUMA, IO та накладні витрати віртуалізації. Різні обмеження — різні переможці.

4) Скільки ядер потрібно купувати для бази даних?

Достатньо, щоб обробляти конкуренцію, не перетворюючи систему на експеримент із конкуренції локів. Для OLTP важливі латентність пам’яті і поведінка кеша; для аналітики — пропускна спроможність пам’яті і кількість ядер. Валідируйте репрезентативним бенчмарком, а не загальними діаграмами.

5) Який найбільший червоний прапор у порівнянні бенчмарків?

Відсутні умови тестування. Якщо ви не знаєте конфігурацію пам’яті, ліміти потужності, ОС/ядро і чи досягався стійкий стан — у вас немає порівняння, є просто два числа.

6) Чи варто вимикати SMT/Hyper-Threading?

Іноді. SMT зазвичай підвищує пропускну спроможність, але може погіршити хвостову затримку для навантажень з високою конкуренцією. Тестуйте обидва режими під реалістичним навантаженням і вирішуйте на підставі p99/p999 і бізнесових SLO.

7) Чому мій хмарний CPU «відчувається повільнішим», ніж та сама модель на он-прем?

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

8) Чи синтетичні бенчмарки марні?

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

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

Запустіть те саме репрезентативне навантаження на обох за однакових умов, досить довго, щоб досягти стійкого стану, і порівняйте хвостову затримку та пропускну спроможність на ват. Якщо не можете цього зробити, принаймні перевірте поведінку частоти, NUMA і паритет конфігурації пам’яті.

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

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

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

1. Оберіть один продакшн-сервіс і класифікуйте його: одноядерний, паралельний, пам’ять-обмежений, IO-обмежений або змішаний.
2. Запустіть Завдання 1, 2, 6, 7, 9 і 10 на одному репрезентативному хості і збережіть виводи як базову лінію.
3. Визначте метрику успіху (p99 затримка, час виконання, пропускна спроможність на долар) і припиніть дозволяти «загальному балу» вирішувати за вас.
4. При оцінці покупки CPU, вимагайте порівняння під стійким навантаженням з ідентичною пам’яттю і політикою потужності, або не прикидайтеся, що ви робите інженерію.

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