Як маркетинг спотворює «покоління»: «новий» CPU, який фактично старий

Що означає «покоління» (і чому це розпливчасто)

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

Основна проблема в тому, що продуктивність CPU — це не одне число. «На 10% швидше» — це фрагмент речення, якщо ви не вкажете:
однониткова чи багатониткова, стало чи у сплеску, ліміти енергії, кількість каналів пам’яті, топологія NUMA та вузьке місце навантаження.
CPU може бути «новим» і поводитися як старий під вашими лімітами потужності та пропускної здатності пам’яті.

Якщо ви працюєте в продакшні, ставтеся до «покоління» як до ненадійної мітки і вимагайте трьох речей:
(1) походження мікроархітектури, (2) зміни платформи (пам’ять, I/O, PCIe) та (3) продуктивність у ваших обмеженнях.
Все інше — театр.

Як маркетинг спотворює поняття «поколінь»: типовий сценарій

1) Ребренд: те ж кремнієве ядро, новий лак

Найпростіше «нове покоління» — це перейменування плюс незначні зміни в бінуванні. Іноді це буквально та сама пластина, іноді —
невеликий stepping-refresh із крихітними виправленнями або енергетичними налаштуваннями. Назва продукту змінюється; мікроархітектура — ні.
Ваше навантаження не помітить нового шильдика. Ваш інвентар активів — помітить.

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

2) Твердження «до»: турбо-математика, подана як певність

Багато «нових» CPU виходять із вищими максимальними турбо-частотами, але подібними сталими всьо-ядерними частотами при реальних лімітах енергії.
«До 5.7 GHz» приємно в описі продукту; менш приємно о 2-й ночі, коли ваше всьо-ядерне навантаження фіксує пакет,
потрапляє під обмеження PL1/PL2 і живе на тих же всьо-ядерних тактах, що й «старий» чіп.

Якщо ви порівнюєте лише базову частоту або макс-турбо, ви по суті бенчмаркуєте відділ маркетингу.

3) Більше ядер — менше запасу на ядро

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

4) «Покоління» платформи проти «покоління» CPU

Постачальники люблять пов’язувати назви CPU зі змінами платформи: новий сокет, новий чіпсет, новий I/O.
Іноді платформа справді нова, а ядра — ні; іноді навпаки.
Для SRE платформа важлива, бо змінює режими відмов: зрілість прошивки, розкладка PCIe ліній, сумісність NIC,
особливості NVMe та поведінку живлення.

5) Буфет бенчмарків: оберіть той, що вам пасує

Маркетинг підбирає навантаження, що підкреслюють сильні сторони CPU: інтенсивні AVX-512 ядра, конкретні прапці компілятора, датасети в кеші
або профілі живлення, які ніхто не використовує в спільному датацентрі. Ваш реальний світ — брудніший.

CPU може бути по суті кращим і водночас не кращим для вас. Це не філософія. Це фізика плюс поведінка планувальника
плюс затримки пам’яті.

Жарт №1: «Працює „наступне покоління“ без даних про навантаження — це як дієта без калорій: рахунок усе одно здивує.»

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

• «Війни MHz» (кінець 1990-х — початок 2000-х): Вендори продавали частоти як головний метрик, поки відмінності в IPC не зробили порівняння MHz оманливим.
• NetBurst vs IPC: Pentium 4 від Intel просував високі частоти, але часто програвав менш розігнаним дизайнам із вищим IPC у реальній роботі.
• Turbo — це не обіцянка: Поведінка turbo залежить від лімітів потужності, температури та струму; стале виконання може суттєво відрізнятися від «макс turbo».
• Міграції спекуляційних вразливостей змінили реальність: Після 2018 року мікрокод і ядрові міри вплинули на продуктивність, особливо в навантаженнях із великою кількістю викликів syscall і віртуалізацією.
• «Tick-tock» закінчився: Передбачувана каденція (зменшення процесу, потім нова архітектура) змінилася на більш нерегулярні оновлення, що зробило «покоління» розмитішим.
• NUMA став помітнішим: Зі зростанням кількості ядер штрафи за віддалений доступ до пам’яті стали важливими, особливо для баз даних і in-memory кешів.
• Топологія кешу стала продуктною особливістю: Дизайни з більшим загальним LLC можуть вигравати без «нових» частот або кількості ядер.
• Покоління PCIe — не косметика: Перехід з PCIe 3.0 на 4.0 і 5.0 може змінити межі швидкості зберігання та NIC навіть якщо ядра CPU схожі.
• Канали пам’яті — це жорстке обмеження: CPU з більшою кількістю ядер, але тією ж кількістю каналів пам’яті може стати голодним за пропускною здатністю в аналітиці, зберіганні та віртуалізації.

Що насправді змінює продуктивність: частини, які ігнорувати не можна

Походження мікроархітектури: родинне дерево має значення

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

Що вважається значною зміною?

• Покращення front-end (краща передбачуваність переходів, ширший декод/диспетчер): допомагає загальному коду і зменшує паузи.
• Покращення back-end (більше виконавчих блоків, кращий планувальник): допомагає пропускній здатності і зменшує бульбашки залежностей.
• Зміни ієрархії кешу (розмір L2, слайси LLC, затримка): часто критично важливі для баз даних, систем збірки і всього, що має «гарячі» робочі набори.
• Зміни підсистеми пам’яті (канали, покоління DDR, контролери): вирішальні для аналітики, щільності віртуалізації і навантажень, що інтенсивно працюють із метаданими зберігання.
• Зміни інтерконекту (кільце vs mesh, chiplet-архітектура, fabric): впливають на міжядерну комунікацію і поведінку NUMA.

Ліміти потужності: PL1/PL2 і омана «базової частоти»

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

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

Пропускна здатність і затримка пам’яті: місця, де CPU тихо вмирають

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

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

I/O і PCIe: ваше «оновлення CPU» може бути маскуванням апгрейду I/O

Іноді CPU в порядку, а перемога виявляється на рівні платформи: більше PCIe ліній, новіше покоління PCIe, краща біфуркація і
вдосконалена робота IOMMU. Це може розблокувати пропускну здатність NVMe, зменшити дисперсію затримок і покращити продуктивність NIC.

Але не називайте це перемогою CPU. Назвіть правильно: це перемога платформи. Вона змінює планування потужностей і майбутні витрати.

Набори інструкцій і акселератори: виграші умовні

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

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

Віртуалізація і шумні сусіди: ви бенчмаркували не той всесвіт

Чим більше ваше середовище покладається на віртуалізацію або щільність контейнерів, тим більше планування, розміщення NUMA і тиск пам’яті домінують.
«Новий CPU» не вирішує переобтяження; він просто переобтяжує швидше.

Один вислів, щоб зберегти чесність: «Надія — це не стратегія.» — Генерал Гордон Р. Салліван

Швидкий план діагностики: знайти вузьке місце швидко

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

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

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

Друге: визначте, чи обмежує CPU, пам’ять або I/O

• CPU-bound: високе користувацьке навантаження CPU, низький iowait, висока стійка частота, низькі затримки пам’яті.
• Memory-bound: помірне завантаження CPU, але низький IPC, багато промахів кешу, високі цикли затримок, насичення пропускної здатності.
• I/O-bound: високий iowait, глибина черг, затримка зберігання; CPU може виглядати «ледачим», але сервіс блокується.

Третє: зіставте навантаження з ресурсом

• Однониткове вузьке місце? Перевірте поведінку підсилення на ядро, прив’язку процесів і обмеження turbo.
• Паралельне навантаження? Перевірте розміщення NUMA, пропускну здатність пам’яті і міжсокетний трафік.
• Інтенсивне зберігання? Перегляньте переривання, softirq, офлоади NIC, черги NVMe, поведінку файлової системи/ZFS.

Четверте: протестуйте мінімальним контрольованим бенчмарком

• Використовуйте мікробенчмарки, щоб ізолювати CPU vs пам’ять vs I/O.
• Потім запустіть один репрезентативний бенчмарк продакшн-сервісу з тією самою конфігурацією, що ви деплоїте.
• Записуйте ліміти потужності, версію ядра, мікрокод, налаштування BIOS і governor.

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

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

Завдання 1: Ідентифікуйте точну модель CPU, родину, stepping

cr0x@server:~$ lscpu | egrep 'Model name|CPU\(s\)|Thread|Core|Socket|Vendor ID|Model:|Stepping:|CPU family'
Model name:                           Intel(R) Xeon(R) Gold 6338N CPU @ 2.20GHz
CPU(s):                               64
Thread(s) per core:                   2
Core(s) per socket:                   32
Socket(s):                            1
Vendor ID:                            GenuineIntel
CPU family:                           6
Model:                                106
Stepping:                             6

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

Завдання 2: Перевірте версію мікрокоду (мітки та поведінка можуть відрізнятися)

cr0x@server:~$ grep -m1 microcode /proc/cpuinfo
microcode	: 0x2c0002e0

Значення: Мікрокод впливає на пом’якшення спекуляції, крайові випадки поведінки turbo і ерату.
Рішення: Якщо порівнюєте CPU, вирівняйте мікрокод і ядрові мітки, інакше ви вимірюєте відмінності патчів, а не чіпів.

Завдання 3: Підтвердіть, що ядро бачить ту топологію NUMA, яку очікуєте

cr0x@server:~$ numactl --hardware
available: 1 nodes (0)
node 0 cpus: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63
node 0 size: 257542 MB
node 0 free: 243110 MB

Значення: Один вузол простіший. Кілька вузлів означають штрафи за віддалену пам’ять і важливість розміщення.
Рішення: Для мультисокетних або систем із chiplet-архітектурою забезпечте NUMA-aware розміщення для БД і JVM, інакше ваше «оновлення» перетвориться на міжвузловий трафік.

Завдання 4: Підтвердіть швидкість пам’яті та заповненість каналів

cr0x@server:~$ sudo dmidecode -t memory | egrep -i 'Locator:|Size:|Speed:|Configured Memory Speed:'
Locator: DIMM_A1
Size: 32 GB
Speed: 3200 MT/s
Configured Memory Speed: 2933 MT/s
Locator: DIMM_B1
Size: 32 GB
Speed: 3200 MT/s
Configured Memory Speed: 2933 MT/s

Значення: DIMM-и зі швидкістю 3200, але сконфігуровані на 2933, вказують на зниження частоти (правила заповнення, змішані DIMM-и, BIOS).
Рішення: Виправте заповнення/швидкість пам’яті перед тим, як звинувачувати CPU. Навантаження, обмежені пам’яттю, ледь зрушаться з місця з «новими ядрами».

Завдання 5: Перевірте governor масштабування частоти CPU

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

Значення: «powersave» може бути прийнятним на деяких серверних платформах (він усе одно може підвищуватись), або ж обмежувати чутливість залежно від драйвера/політики.
Рішення: Якщо важлива затримка, встановіть governor у performance (або переконайтеся, що прошивка платформи керує цим передбачувано) і повторіть тест.

Завдання 6: Підтвердіть, що turbo/boost увімкнено

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

Значення: «1» означає, що turbo вимкнено.
Рішення: Якщо ви заплатили за вищі boost-значення, увімкніть turbo (якщо дозволяють потужність/термальні умови) або перестаньте очікувати виграшів покоління на однониткових навантаженнях.

Завдання 7: Спостерігайте реальний CPU і iowait під навантаженням

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

12:02:01 PM  CPU    %usr   %sys  %iowait  %idle
12:02:02 PM  all    72.10   6.20    0.10  21.60
12:02:02 PM   0    98.00   1.00    0.00   1.00
12:02:02 PM   1    96.00   2.00    0.00   2.00

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

Завдання 8: Перевірте тротлінг CPU та термальні/енергетичні ліміти через dmesg

cr0x@server:~$ dmesg | egrep -i 'thrott|thermal|powercap|rapl' | tail -n 5
intel_rapl_common: Found RAPL domain package
thermal thermal_zone0: critical temperature reached (105 C), shutting down
CPU0: Core temperature above threshold, cpu clock throttled

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

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

cr0x@server:~$ sudo turbostat --Summary --quiet --interval 1 --num_iterations 3
     Core     CPU Avg_MHz   Busy%  Bzy_MHz  TSC_MHz  IPC   PkgWatt
       -       -     980    68.2     1437     2200  0.72     165.4
       -       -     990    69.1     1432     2200  0.70     168.1
       -       -     975    67.5     1440     2200  0.73     164.9

Значення: Busy MHz проти очікуваного all-core turbo показує, чи ліміти потужності або термальна голова обмежують вас.
IPC ≈0.7 натякає на затримки пам’яті або розгалужений код.
Рішення: Якщо Bzy_MHz низький — налаштуйте потужність/термальні умови. Якщо IPC низький — фокусуйтеся на пам’яті/кеші/алгоритмах, а не на «поколінні» CPU.

Завдання 10: Перевірте прапці віртуалізації та припущення про nested virtualization

cr0x@server:~$ lscpu | egrep 'Virtualization|Flags'
Virtualization:                       VT-x
Flags:                                fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ss ht syscall nx pdpe1gb rdtscp lm constant_tsc arch_perfmon ... vmx ...

Значення: Наявність розширень віртуалізації не гарантує продуктивності; поведінка EPT/NPT та пом’якшення мають значення.
Рішення: Якщо «новий CPU» відстає в VM, перевірте мітки ядра та мікрокоду на хості і тип CPU, який експонується у VM, перед тим як звинувачувати обладнання.

Завдання 11: Проінспектуйте черги блокових пристроїв і планувальник (I/O може маскуватися під повільний CPU)

cr0x@server:~$ lsblk -o NAME,MODEL,ROTA,TYPE,SIZE,MOUNTPOINT
NAME        MODEL             ROTA TYPE  SIZE MOUNTPOINT
nvme0n1     SAMSUNG MZVL21T0     0 disk  1.8T
├─nvme0n1p1                     0 part  512M /boot
└─nvme0n1p2                     0 part  1.8T /

cr0x@server:~$ cat /sys/block/nvme0n1/queue/scheduler
[none] mq-deadline kyber bfq

Значення: Для NVMe часто використовується «none» (це нормально), але деякі навантаження виграють від mq-deadline.
Рішення: Якщо затримка зберігання стрибкоподібна і ви бачите глибокі черги, протестуйте mq-deadline і виміряйте p99 перед тонкою настройкою CPU.

Завдання 12: Перевірте файлову систему та опції монтування (особливо для затримки)

cr0x@server:~$ findmnt -no SOURCE,TARGET,FSTYPE,OPTIONS /
/dev/nvme0n1p2 / ext4 rw,relatime,errors=remount-ro

Значення: Опції монтування можуть змінити поведінку writeback та затримки. «relatime» зазвичай підходить.
Рішення: Якщо ваше «оновлення CPU» співпало з перевстановленням, перевірте, чи опції монтування не змінилися (наприклад, barriers, discard) і випадково не підмінили затримання.

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

cr0x@server:~$ vmstat 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
 8  0      0 245100000 120000 8200000    0    0     1    12  920 18000 70  6 24  0  0
 9  0      0 245080000 120000 8200100    0    0     0     8  890 17650 72  6 22  0  0

Значення: Високий r відносно кількості CPU свідчить про конкуренцію; високий cs — про накладні витрати планування або дуже малі timeslice.
Рішення: Якщо черга виконання висока і cs величезний, налаштуйте конкурентність і пул потоків; «більше ядер» не врятує від шторму потоків.

Завдання 14: Визначте топ-споживачів CPU і чи масштабується їхня робота

cr0x@server:~$ ps -eo pid,comm,pcpu,pmem,psr --sort=-pcpu | head
  9123 java            780.2  12.1  18
  1044 postgres        210.4   3.8   2
  2211 node            115.0   1.2  44

Значення: Одна процеса з сотнями %CPU може все ще бути обмеженою кількома гарячими потоками.
Рішення: Якщо топ-споживач — однонитково обмежений, зосередьтеся на продуктивності на ядро, конкуренції локів і афініті — не тільки на кількості ядер.

Завдання 15: Перевірте perf-лічильники на предмет затримок (дешевий реалістичний чек)

cr0x@server:~$ sudo perf stat -a -e cycles,instructions,cache-misses,branches,branch-misses -I 1000 sleep 3
#           time             counts unit events
     1.000307907    12,345,678,901      cycles
     1.000307907     5,432,109,876      instructions
     1.000307907        98,765,432      cache-misses
     1.000307907       876,543,210      branches
     1.000307907        12,345,678      branch-misses

Значення: IPC приблизно дорівнює instructions/cycles. Великі cache-misses можуть означати обмеження пам’яті.
Рішення: Якщо IPC низький і промахи кешу великі, «нове покоління» CPU з подібною підсистемою пам’яті не допоможе; пріоритет — локальність кешу, NUMA, швидкість пам’яті.

Завдання 16: Підтвердіть швидкість/ширину PCIe для NIC і NVMe (платформа важлива)

cr0x@server:~$ sudo lspci -vv -s 01:00.0 | egrep -i 'LnkCap|LnkSta'
LnkCap: Port #0, Speed 16GT/s, Width x16, ASPM L1, Exit Latency L1 <64us
LnkSta: Speed 8GT/s (downgraded), Width x16 (ok)

Значення: Пристрій здатний на PCIe 4.0 (16GT/s), але працює на PCIe 3.0 (8GT/s). Це не проблема CPU.
Рішення: Виправте налаштування BIOS, riser-и, вибір слоту або кабелювання перед бенчмарком «покоління» CPU. Інакше ви бенчмаркуєте понижений лінк.

Жарт №2: Якщо ваш PCIe лінк скочив до Gen3, вітаю — ви винайшли «режим ефективності», який ніхто не просив.

Три корпоративні міні-історії зі світу «має бути швидше»

Міні-історія 1: Інцидент через хибне припущення

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

Перший симптом не був явним простою. Він був гіршим: повільна ерозія. p95 затримка в API поволі зростала, потім p99 почав
стрибати в дні деплоїв. На чергуванні бачили CPU на рівні 60–70% і відкидали це як достатній запас. «У нас є підголівок.»
Тим часом кількість тайм-аутів на даунстрім запитах зросла настільки, щоб викликати ретраї, які створювали ще більше навантаження. Класика.

Коли вони нарешті профілювали хости, IPC був низьким, а цикли затримки пам’яті — високими. «Нове покоління» мало більше ядер, але
конфігурація пам’яті була неправильною: через заміну постачальника менше каналів були заповнені на сокет. Пікова пропускна здатність впала.
Під старим флотом вони були обмежені CPU; під новим — пам’яттю. Той самий код, інша фізика.

Корінь інциденту не був у моделі CPU. Це було припущення, що покоління означає підвищення на ядро незалежно від деталей платформи.
Виправлення було нудним і ефективним: виправити заповнення DIMM-ів, підтвердити налаштовану швидкість пам’яті і оновити модель ємності, використовуючи
виміряну пропускну здатність на вузол. Мітка «покоління» ніколи не з’явилася в постмортемі. І не повинна була.

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

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

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

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

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

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

Інша організація оновлювалася нудним, але правильним способом. До приходу заліза вони визначили специфічний для навантаження acceptance test:
три мікробенчмарки (CPU, пам’ять, I/O) плюс один репрезентативний бенчмарк сервісу в конфігурації, схожій на продакшн.
Вони занотували версії прошивки, ядро, мікрокод і BIOS-налаштування. Вони розглядали тест як артефакт релізу.

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

Вони швидко знайшли проблему: налаштування PCIe bifurcation відрізнялися від золотого конфігу, що змусило NIC-і домовитися на нижчій швидкості.
Це підняло навантаження softirq і збільшило затримку запитів. CPU був невинний; винною виявилася конфігурація платформи.
Оскільки acceptance тест включав мережеву навантажену прогінку сервісу, проблему виявили до розгортання.

Рятівний момент — нудна дисципліна: порівнюйте системи з вирівняними прошивками, профілями живлення і вимірювальними acceptance-гейтами.
Без героїки, просто чекліст і готовність відкласти розгортання. Це не захопливо, але так зберігають SLO.

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

• Симптом: Однониткова продуктивність не змінилася після «оновлення».
  Корінь проблеми: Turbo вимкнено, консервативний governor або жорсткіші ліміти потужності, ніж на попередній платформі.
  Виправлення: Перевірте intel_pstate/no_turbo, governor, профіль BIOS; повторіть тест з ідентичними налаштуваннями і підтвердіть стійкий boost через turbostat.
• Симптом: Багатониткова пропускна здатність ледь росте; завантаження CPU високе, але IPC низький.
  Корінь проблеми: Насичення пропускної здатності пам’яті або віддалений доступ NUMA; більше ядер лише додає конкуренцію.
  Виправлення: Підтвердьте канали і швидкість пам’яті, зафіксуйте процеси до NUMA, зменшіть крос-вузлові розподіли, розгляньте менше-швидші ядра або більше каналів пам’яті.
• Симптом: Хвостова затримка гірша на новому CPU при змішаному навантаженні.
  Корінь проблеми: Тротлінг по теплу/енергії, фонові роботи конфліктують з foreground, або падіння частот під важкими векторними інструкціями.
  Виправлення: Покращіть охолодження/енергетичні ліміти, плануйте фонові роботи, налаштуйте розміри батчів і виміряйте стійкі частоти під найгіршою конкуренцією.
• Симптом: Стек зберігання «відчувається повільніше», хоча CPU виглядає ледачим.
  Корінь проблеми: Чергування I/O і затримки: NVMe лінк підлаштований вниз, невідповідний планувальник або зміни прошивки при перевстановленні.
  Виправлення: Перевірте швидкість PCIe, затримки NVMe, глибину черг і планувальник; підтвердіть, що параметри монтування та конфігурації зберігання відповідають старому флоту.
• Симптом: VM-навантаження регресують незважаючи на «кращий CPU».
  Корінь проблеми: Різні мітки пом’якшення, експонування моделі CPU у VM, відмінності nested virtualization або розміщення NUMA у гіпервізорі.
  Виправлення: Вирівняйте ядро/мікрокод хоста, підтвердіть тип CPU у VM, перевірте vNUMA і порівнюйте «яблука з яблуками» з заблокованими ресурсами.
• Симптом: Бенчмарки показують покращення, але продакшн — ні.
  Корінь проблеми: Бенчмарк поміщається в кеш, використовує інші прапці компілятора або запускається з низькою конкурентністю; продакшн потрапляє на пам’ять, блокування або I/O.
  Виправлення: Використовуйте репрезентативні датасети і конкурентність; додавайте perf-лічильники і відсоткові ділянки затримки; розглядайте синтетичні бенчмарки як компонентні тести, а не як acceptance.
• Симптом: «Та сама генерація CPU» поводиться по-різному на різних вузлах.
  Корінь проблеми: Різні версії BIOS, мікрокод, мікси DIMM-ів або профілі живлення; дрейф прошивки.
  Виправлення: Застосуйте базові конфіги, аудит через автоматизацію і блокуйте розгортання при виявленні дрейфу.

Чеклісти / покроковий план (оновлюємося без самопошкоджень)

Крок 1: Визначте, що означає «краще» для вашого навантаження

• Виберіть 2–4 ключові метрики: p99 затримка, пропускна здатність, вартість за запит, ватт на запит, час збірки, час виконання запиту.
• Виберіть один репрезентативний сценарій продакшну: той самий розмір датасету, та сама конкурентність, ті самі фон-роботи.
• Оформіть пороги прийнятності, які готові відстоювати.

Крок 2: Нормалізуйте середовище перед порівняннями CPU

• Та сама ОС, ядро, політика мікрокоду і налаштування пом’якшень.
• Такий самий профіль BIOS живлення (performance vs balanced), та сама політика turbo.
• Ті самі правила заповнення пам’яті і перевірена налаштована швидкість.
• Та сама прошивка NIC і перевірка швидкості лінку.

Крок 3: Запустіть набір тріаж-тестів компонентів

• CPU: стійкий всьо-ядерний тест і однонитковий тест; підтвердіть частоти і поведінку потужності.
• Пам’ять: перевірка пропускної здатності й затримки; підтвердьте штрафи NUMA.
• Зберігання: послідовні і випадкові тести; підтвердіть планувальник I/O і поведінку черг.
• Мережа: підтвердіть лінійну швидкість, розподіл IRQ і поведінку softirq.

Крок 4: Запустіть сервісний бенчмарк і зафіксуйте контекст

• Збирайте: turbostat summary, perf stat counters, iostat і ключові метрики сервісу.
• Фіксуйте: версії прошивки, налаштування BIOS і будь-які відхилення.
• Зберігайте результати як артефакти; не покладайтеся на скриншоти в чаті.

Крок 5: Рішення на основі вузьких місць, а не брендингу

• Якщо обмеження — пам’ять: пріоритет — канали пам’яті, швидкість, кеш і топологія NUMA, а не «нове покоління».
• Якщо обмеження — I/O: пріоритет — лінії/покоління PCIe, конфігурація зберігання/NIC і обробка переривань.
• Якщо обмеження — CPU: тоді так — мікроархітектура і стійкі частоти мають значення; підтвердіть енергетичний запас і охолодження.

Крок 6: Розгортайте з запобіжниками

• Canary-вузли з моніторингом SLO і автоматичним відкатом.
• Тримайте старий флот у резерві, поки новий не доведе себе під піковим трафіком.
• Блокуйте масштабування, якщо з’явився дрейф прошивки або acceptance-бенчмарки відкотилися.

FAQ

1) Як зрозуміти, що «нове покоління» CPU фактично є рефрешем?

Дивіться на походження мікроархітектури і stepping, а не тільки на назву. Перевірте через lscpu і мікрокод/stepping, потім порівняйте
розміри кешів, канали пам’яті і I/O платформи. Якщо платформа і дизайн ядер не змінилися, очікуйте інкрементальні відмінності.

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

Turbo залежить від лімітів потужності, термальних умов і політики. Якщо turbo вимкнено, governor консервативний або платформа швидко досягає лімітів,
ви не побачите рекламований буст. Вимірюйте через turbostat під реальним навантаженням.

3) Чи кращий метрик — IPC чи GHz?

IPC інформативніший, але тільки в контексті. IPC падає, коли ви обмежені пам’яттю або маєте багато промахів по переходах. Новий CPU може підвищити IPC
на обчислювальних ядрах, але не на вашому навантаженні з промахами кешу. Використовуйте perf-лічильники і корелюйте з поведінкою пам’яті/кешу.

4) Чому більше ядер може погіршити хвостову затримку?

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

5) Які зміни платформи важливіші за ядра CPU?

Канали і швидкість пам’яті, покоління PCIe і доступність ліній, поведінка IOMMU і зрілість прошивки.
Для зберігання і мережі краща I/O платформа може бути справжнім «апгрейдом», навіть якщо продуктивність ядер схожа.

6) Як бенчмаркувати чесно, не обманюючи себе?

Використовуйте двошаровий підхід: мікробенчмарки для ізоляції компонентів та один репрезентативний end-to-end бенчмарк із продакшн-подібним
розміром датасету і конкурентністю. Записуйте налаштування потужності/тепла і прошивки. Якщо не можете відтворити результат — він не відбувся.

7) Чи можуть заходи безпеки уповільнити новий CPU?

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

8) Який найшвидший спосіб вирішити, чи купувати «нове покоління»?

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

9) Коли ребренд все ще варто купувати?

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

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

«Покоління» CPU — не контракт. Це історія. Ваше завдання — перетворити історію назад на вимірювання.
Найшвидший спосіб програти гроші в інфраструктурі — купувати обчислювальні ресурси, щоб вирішити пам’яттєве або I/O вузьке місце.

Наступні кроки, що віддають дивіденди відразу:

• Побудуйте acceptance test, який включає turbostat + perf-лічильники + ваш справжній сервісний бенчмарк.
• Стандартизуйте BIOS/профілі живлення і впровадьте виявлення дрейфу прошивок по флоту.
• Зробіть заповнення пам’яті і налаштовану швидкість релізним гейтом, а не післямірним кроком.
• Коли хтось каже «наступне покоління», відповідайте: «покажіть стійкі частоти, IPC і p99 у межах наших лімітів потужності».

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