Вибір CPU на 5 років: купуйте за навантаженням, а не за логотипом

Основний принцип: навантаження перш за все, логотип останнім

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

Купуйте, відповівши на ці питання з доказами:

• Що насичується першим? CPU-цикли, пропускна здатність пам’яті, кеш, I/O або мережа?
• Яке критичне SLO? Пропускна здатність, p99 латентність, час завершення задачі або вартість за одиницю?
• Яка модель конкурентності? Однопотоковий «гарячий» цикл, багато незалежних потоків чи fork/join?
• Наскільки «сплескове» навантаження? Чи можна використовувати turbo/boost, чи ви працюєте на стійкому навантаженні на всі ядра?
• Що ще там буде працювати? Сайдкари, агенти, шифрування, стиснення, перевірка, резервні копії, телеметрія.

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

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

Короткі факти та історія, яка справді має значення

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

1. Частоти перестали масштабуватися лінійно в середині 2000-х через щільність потужності і тепло; індустрія різко перейшла до багатоядерності.
2. «Turbo»/boost змінили закупівельну математику: короткі сплески можуть виглядати чудово в бенчмарках, але руйнуються при тривалому завантаженні всіх ядер.
3. Hyper-threading/SMT це не «2x ядер»; це трюк для використання ресурсів, який допомагає деяким навантаженням і шкодить іншим, особливо під час конкуренції.
4. NUMA — це тихий податок на продуктивність серверів десятиліттями: локальна пам’ять швидка; віддалена пам’ять — «доволі швидка, поки не стає нею».
5. Розміри кешу виросли, бо пам’ять не встигала; затримка до DRAM усе ще дорога, і багато навантажень випадково обмежені латентністю пам’яті.
6. AES-NI та подібні розширення інструкцій зробили шифрування достатньо дешевим, щоб його вмикали «за замовчуванням», змістивши вузькі місця в інші частини стека.
7. Міри проти спекуляції (після 2018 року) зробили мікроархітектурні деталі важливими в експлуатації; рівні патчів можуть змінювати профілі продуктивності.
8. Кількість ліній PCIe стала критерієм ємності коли NVMe, GPU та smart NIC стали нормою в «загального призначення» серверах.

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

Форми навантажень: що насправді робить ваш CPU

1) Сервіси, критичні до латентності (тут живе p95/p99)

Веб-API, автентифікація, торги оголошеннями, ринкові дані, платежі: бізнес-метрика — хвостова латентність. Ці навантаження часто мають
невеликі «гарячі» цикли, багато розгалужень і часті пропуски кешу через великі робочі набори або інтенсивне виділення пам’яті.

Чого бажати:

• Сильна одно-потокова продуктивність (не лише піковий turbo на одному ядрі, а стійка під реальним навантаженням).
• Велика й ефективна ієрархія кешу; менше пропусків кешу у масштабі краще за «більше ядер» для хвостової латентності.
• Передбачувана поведінка частоти при теплових та енергетичних обмеженнях.
• Чітка стратегія NUMA: закріплюйте критичні процеси, тримайте пам’ять локально, уникайте міжсокетного шуму.

2) Пропускні навантаження (пакети, ETL, рендеринг, офлайн-обчислення)

Якщо важливіший час завершення, часто можна додати ядра — поки не вдаритеся в межу пропускної здатності пам’яті або I/O.
Компілятори, ферми збірки, ETL і деяка аналітика люблять паралелізм, але лише якщо вони не конкурують за канали пам’яті.

Чого бажати:

• Більше фізичних ядер і достатня пропускна здатність пам’яті, щоб їх годувати.
• Стійка продуктивність на всі ядра в межах живлення, а не спалахи маркетингових частот.
• Достатньо PCIe для зберігання й мережі, які ви неминуче додасте в середині життєвого циклу.

3) Хости віртуалізації та контейнерів («змішаний набір»)

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

Чого бажати:

• Достатньо ядер для консолідації, але не настільки багато, щоб втратився контроль над локальністю по сокетах.
• Добра ємність пам’яті і канали; overcommit пам’яті перетворюється на своп, а своп — на екзистенціальний жах.
• Стабільність платформи: передбачувані налаштування BIOS, стабільний мікрокод і чиста поведінка IOMMU для passthrough за потреби.

4) Сервери зберігання (так, CPU має велике значення)

Стек зберігання споживає CPU в непрезентабельні способи: контрольні суми, стиснення, паритет RAID, шифрування, дедуплікація (якщо сміливі),
та операції з метаданими. ZFS, Ceph, mdraid, LVM, dm-crypt — це не безкоштовно.

Чого бажати:

• Достатньо ядер для фонової роботи (scrub, ребаланс, compact) під час обслуговування foreground I/O.
• Сильна підсистема пам’яті; I/O, насичений метаданими, стає обмеженим латентністю пам’яті.
• Лінії PCIe і топологія, що відповідають вашому розташуванню HBA/NVMe; «підходить у слот» не означає «працює швидко».

5) Спеціалізовані обчислення (транскодування, ML, крипто, стиснення)

Їх найпростіше влучно налаштувати і найпростіше зіпсувати. Правильно: вимірювати використовувані інструкції і обирати найкращий шлях акселерації
(GPU, Quick Sync, AVX-512 тощо). Неправильно: припускати, що блискуче векторне розширення CPU — гарантований плюс.

Чого бажати:

• Підтримка набору інструкцій, якою реально користується ваше ПЗ (і під яку воно зкомпільоване).
• Термал і подача живлення, що підтримують векторні навантаження (вони можуть сильно знижувати частоту).
• Достатньо I/O для підгодовування звіра (NVMe для датасетів, швидка мережа тощо).

Властивості CPU, що впливають на результат (і ті, що ні)

Ядра vs частота: перестаньте ставитися до цього як до бінарного вибору

Кількість ядер допомагає, коли у вас є паралельна робота, яку можна тримати завантаженою без боротьби за спільні ресурси.
Частота допомагає, коли невелика кількість потоків домінує в латентності або коли конкуренція за блокування робить «більше потоків» по суті більшою конкуренцією.
За п’ять років ваше навантаження зміниться. Але воно рідко перевернеться з «гарячого однопотокового циклу» в «ідеально паралельне».

Практичний підхід — класифікувати навантаження за ефективним паралелізмом:

• 1–4 гарячі потоки мають значення: віддавайте перевагу сильній продуктивності на ядро і кешу, і тримайте платформу прохолодною.
• 8–32 корисні потоки: баланс частоти і ядер, слідкуйте за пропускною здатністю пам’яті.
• 64+ корисних потоків: домінують ядра і канали пам’яті; топологія і NUMA стають прихованою прірвою.

Кеш часто цінніший, ніж ви закладаєте

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

Канали пам’яті, частота та ємність: тихий обмежувач

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

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

На двосокетних системах (і навіть на деяких складних односокетних конструкціях) локальність пам’яті має значення. Доступ до віддаленої пам’яті додає латентність,
знижує пропускну здатність і збільшує дисперсію — особливо помітно на p99.

Якщо ви плануєте мульти-сокет, закладіть час на:

• NUMA-усвідомлене планування (systemd CPUAffinity, Kubernetes CPU Manager, pinning процесів БД).
• Перевірку, що ваші NIC і NVMe пристрої підключені до сокета, який виконує навантаження.
• Вимірювання з реальним трафіком, не синтетичними тестами, що випадково залишаються в межах одного NUMA-вузла.

Лінії PCIe і топологія I/O: пастка в «сервері загального призначення»

Ви можете купити CPU з достатньою обчислювальною потужністю і потім задушити його I/O: занадто мало ліній PCIe, перенавантажені корені,
або NVMe, підключені через свитч, що ділить пропускну здатність не так, як ви моделювали. За п’ять років ви додасте NIC, більше NVMe,
можливо GPU, можливо DPU. Обирайте платформу з резервом.

Обмеження потужності і охолодження: стійка продуктивність — це єдина продуктивність

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

Бренд — це не стратегія

Купуйте частину, яка перемагає по ваших метриках, на вашому компіляторі/рантаймі, в межах вашого енергетичного конверта і вашого ланцюга постачання. Потім валідуйте.
Ось і все. Логотип — для рахунку-фактури.

Жарт №2: Найкращий CPU — той, що не змушує вас опановувати новий портал постачальника о 3:00 ранку.

Планування на п’ять років: що змінюється, а що ні

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

• Оновлення програмного забезпечення, що змінюють характеристики продуктивності (нова JIT-поведінка, нові налаштування двигуна зберігання, новий планувальник ядра).
• Режими патчів безпеки, що можуть впливати на мікроархітектурну продуктивність.
• Нові агенти спостереження, які «трохи потребують CPU». Всі вони так говорять.
• Зростання розмірів датасетів, що перетворює кеш-дружні навантаження на обмежені латентністю пам’яті.
• Платформний дрейф: оновлення BIOS, зміни мікрокоду і фірмверні фічі, як-от налаштування енергозбереження за замовчуванням.

Купуйте запас у правильному вимірі

Запас — це не «на 50% більше ядер». Запас це:

• Ємність пам’яті, щоб рости без свопу.
• Пропускна здатність пам’яті, щоб додані ядра не простоювали.
• Лінії PCIe для розширення без перенавантаження I/O.
• Тепловий запас, щоб тривале навантаження не знижувало частоту.
• Сімейство SKU, яке можна буде і надалі придбати в третій рік без благань.

Віддавайте перевагу нудним платформам, коли uptime — це продукт

Передові платформи підходять, коли у вас є лабораторія, вільні потужності та план відкату. Якщо у вас невелика команда,
віддавайте перевагу комбінації CPU/платформи з передбачуваним фірмвером, зрілою підтримкою ядра та відомою сумісністю NIC/HBA.
Вам не платять за новизну.

Цитата, бо це досі найкраща порада для ops

Надія — не стратегія. — Джеймс Кемерон

Це дивно добре підходить до планування потужностей і купівлі CPU.

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

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

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

За кілька днів p99 почав стрибати. Не середня латентність. Не завантаження CPU. Саме p99, в сплесках, що збігалися з піками трафіку.
Команда припустила налаштування GC. Вони змінили розміри кучи, колектори, відкатували і накочували. Піки лишалися.

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

Виправлення не потребувало героїзму. Вони закріпили CPU-set і політики пам’яті для критичних підів, налаштували IRQ affinity, щоб черги NIC були локальні до обчислювального сокету,
і валідували це perf counters. P99-піки зникли. CPU не був поганий. Припущення було.

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

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

Пропускна здатність інжесту спочатку покращилася. Дашборд виглядав краще. Потім тижневе вікно scrub почало заходити в робочий час, бо scrubs стали довшими.
Латентність читань стала більш шумною, і кілька клієнтів поскаржились на тайм-аути під час фонових обслуговувань.

Стиснення не було лиходієм; безконтрольне стиснення — було. Система тепер жонглювала foreground стисненням, фоновими контрольними сумами scrubs
і мережевими перериваннями на тих же ядрах. Вони випадково перемістили вузьке місце з дисків у планування CPU і тиск кешу.

Частковий відкат вирішив проблему: вони залишили стиснення для холодних даних і налаштували recordsize та рівень стиснення для «гарячих» бакетів.
Більш важливо, вони зарезервували ядра для технічного обслуговування зберігання і ізолювали обробку переривань. Продуктивність повернулась, а вікна scrub стали передбачуваними.
Урок: «CPU дешевий» — небезпечне речення, коли вам потрібна детермінована підтримка.

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

Фінансова компанія мала звичку, що виглядала надмірно консервативною: перед затвердженням будь-якої нової платформи CPU вони запускали тижневу канарку в продакшені з зеркальним трафіком і строгими SLO-рейтинґами.
Закупівлі це ненавиділи. Інженери іноді бурчали.
Це уповільнювало «інновації». Але це й врятовувало від інцидентів.

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

Вони працювали з вендором і знайшли взаємодію фірмверу + налаштувань BIOS по енергоменеджменту, яка спричиняла короткі стрибки латентності в обробці переривань.
Оновлення фірмверу і зміна налаштування BIOS вирішили проблему. Жоден клієнт цього не помітив. Інцидент-рев’ю не потрібне.

Практика не була гламурною: довгі канарки, нудні критерії прийняття і відмова вірити одному бенчмарку.
Так виглядає «reliability engineering», коли він працює.

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

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

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

cr0x@server:~$ lscpu
Architecture:                         x86_64
CPU(s):                               64
Thread(s) per core:                   2
Core(s) per socket:                   32
Socket(s):                            1
Model name:                           AMD EPYC 7543 32-Core Processor
NUMA node(s):                         1
L3 cache:                             256 MiB

Що це означає: Тепер ви знаєте свою базу: 32 фізичні ядра, SMT увімкнений, один сокет і великий L3 кеш.

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

Завдання 2: Перевірте поведінку частоти під навантаженням (governor і scaling)

cr0x@server:~$ cpupower frequency-info
analyzing CPU 0:
  driver: acpi-cpufreq
  CPUs which run at the same hardware frequency: 0
  available cpufreq governors: performance powersave
  current policy: frequency should be within 1500 MHz and 3700 MHz.
                  The governor "performance" may decide which speed to use
  current CPU frequency: 3692 MHz (asserted by call to hardware)

Що це означає: Ймовірно ви не застрягли в енергозбережному governor. Є голова частоти до ~3.7 GHz.

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

Завдання 3: Подивіться, чи ви насичені CPU або просто «зайняті»

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   62.10   0.00  10.40    0.20  0.10   1.30    0.00  25.90
12:00:02 PM   0   95.00   0.00   4.00    0.00  0.00   0.00    0.00   1.00
12:00:02 PM   1   10.00   0.00   1.00    0.00  0.00   0.00    0.00  89.00

Що це означає: Загалом є запас, але CPU0 гарячий. Це проблема планування або «гаряча точка» переривань, а не «потрібно більше ядер».

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

Завдання 4: Перевірте чергу виконання (чи чекаєте ви 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
 8  0      0 802312  11232 9212440    0    0     0    12 5821 9902 64 11 25  0  0
12  0      0 801900  11232 9212600    0    0     0     0 6001 11022 72 12 16  0  0

Що це означає: r одно8–12 виконуваних задач. Якщо це постійно вище за кількість ядер, ви CPU-навантажені. Тут це нижче за 64 потоки, але може бути вище за фізичні ядра на менших системах.

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

Завдання 5: Визначте, чи пропускна здатність/латентність пам’яті є обмежувачем

cr0x@server:~$ perf stat -a -e cycles,instructions,cache-misses,LLC-load-misses -I 1000 sleep 3
#           time             counts unit events
     1.000349290    3,210,442,991      cycles
     1.000349290    2,120,112,884      instructions
     1.000349290       45,332,100      cache-misses
     1.000349290       12,501,883      LLC-load-misses

     2.000719401    3,188,102,112      cycles
     2.000719401    2,098,554,001      instructions
     2.000719401       46,110,220      cache-misses
     2.000719401       12,980,004      LLC-load-misses

Що це означає: Instructions per cycle близько 0.65 (2.1B / 3.2B), і LLC misses значні. Це натякає на затримки пам’яті.

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

Завдання 6: Перевірте NUMA-розмітку та відстані

cr0x@server:~$ numactl --hardware
available: 2 nodes (0-1)
node 0 cpus: 0-31
node 0 size: 257837 MB
node 0 free: 210112 MB
node 1 cpus: 32-63
node 1 size: 257838 MB
node 1 free: 211004 MB
node distances:
node   0   1
  0:  10  21
  1:  21  10

Що це означає: Два NUMA-вузли з віддаленим доступом приблизно в 2x дорожчим за локальний (відстань 21 vs 10). Це нормально, але проявиться на p99, якщо ігнорувати.

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

Завдання 7: Зіставте PCIe-пристрої з NUMA-вузлами (NIC, NVMe, HBA)

cr0x@server:~$ lspci -vv | grep -E "Ethernet|Non-Volatile|NUMA"
3b:00.0 Non-Volatile memory controller: Samsung Electronics Co Ltd NVMe SSD Controller SM981/PM981/PM983
	NUMA node: 1
41:00.0 Ethernet controller: Mellanox Technologies MT27800 Family [ConnectX-5]
	NUMA node: 0

Що це означає: Ваш NIC локальний для вузла 0, NVMe — для вузла 1. Якщо шлях I/O перетинає сокети, ви щойно купили дисперсію латентності.

Рішення: Вирівняйте навантаження з їхніми I/O-пристроями (закріпіть обчислення поруч з NIC/NVMe) або пересійте апарат. Для нових покупок обирайте платформи з достатніми лініями, щоб уникнути незручного розміщення.

Завдання 8: Виявіть гарячі точки переривань (часто плутають із необхідністю апгрейду CPU)

cr0x@server:~$ cat /proc/interrupts | head -n 8
           CPU0       CPU1       CPU2       CPU3
  24:  99211231          0          0          0   PCI-MSI 524288-edge      mlx5_comp0@pci:0000:41:00.0
  25:         0   98122010          0          0   PCI-MSI 524289-edge      mlx5_comp1@pci:0000:41:00.0
  26:         0          0   99100110          0   PCI-MSI 524290-edge      mlx5_comp2@pci:0000:41:00.0
  27:         0          0          0   98911220   PCI-MSI 524291-edge      mlx5_comp3@pci:0000:41:00.0

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

Рішення: Якщо переривання накопичуються на одному CPU, виправте IRQ affinity і налаштування черг перед зміною CPU. Хвостова латентність значно покращується при правильному розподілі переривань.

Завдання 9: Перевірте тротлінг і теплові обмеження

cr0x@server:~$ dmesg | grep -iE "thrott|thermal|powercap" | tail -n 5
[ 8921.112233] intel_rapl_common: Found RAPL domain package
[ 9122.445566] CPU0: Core temperature above threshold, cpu clock throttled (total events = 3)
[ 9122.445700] CPU0: Package temperature/speed normal

Що це означає: Іноді у вас відбувається тротлінг. Це варіативність продуктивності, яку ви відчуєте на p99.

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

Завдання 10: Перевірте накладні витрати віртуалізації та steal time

cr0x@server:~$ mpstat 1 3 | tail -n 3
12:10:02 PM  all  40.00   0.00   8.00   0.00   0.00   0.50   7.50  44.00
12:10:03 PM  all  42.00   0.00   9.00   0.00   0.00   0.40   8.20  40.40
12:10:04 PM  all  41.50   0.00   8.80   0.00   0.00   0.60   8.10  41.00

Що це означає: %steal близько 8% вказує, що ваша VM чекає, бо гіпервізор перенавантажений або сусіди шумлять.

Рішення: Не «виправляйте» steal time апгрейдом CPU гостьової ОС. Виправте перенавантаження хосту, резервуйте CPU або перемістіть навантаження. При купівлі переконайтесь, що хости мають достатньо реальних ядер для цілей консолідації.

Завдання 11: Визначте, чи зберігання краде ваші цикли (приклад ZFS)

cr0x@server:~$ zpool iostat -v 1 3
              capacity     operations     bandwidth
pool        alloc   free   read  write   read  write
tank        7.21T  3.12T    980  4.20K  112M  610M
  raidz2    7.21T  3.12T    980  4.20K  112M  610M
    nvme0n1     -      -    120    520  14.0M 72.0M
    nvme1n1     -      -    118    525  13.8M 72.5M
    nvme2n1     -      -    121    515  14.2M 71.2M
    nvme3n1     -      -    119    518  13.9M 71.8M

Що це означає: Ви штовхаєте 610 MB/s записів з 4.2K ops/s. Якщо CPU також високий, контрольні суми/стиснення/паритет можуть бути обмежувачем, а не диски.

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

Завдання 12: Виміряйте навантаження обробки мережі (softirq pressure)

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

12:15:01 PM     IFACE   rxpck/s   txpck/s    rxkB/s    txkB/s
12:15:02 PM      eth0   120000    118500   980000    910000
12:15:03 PM      eth0   121200    119100   990500    915200

Що це означає: Дуже високі швидкості пакетів. Це робота CPU (softirq, interrupts), а не лише «мережева ширина каналу».

Рішення: Якщо швидкість пакетів висока, обирайте CPU з сильною продуктивністю на ядро і забезпечте коректну конфігурацію черг NIC/IRQ affinity. Іноді менше швидших ядер краще, ніж більше повільніших для пакетно-важких навантажень.

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

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

12:18:01 PM   UID       PID   cswch/s nvcswch/s  Command
12:18:02 PM     0      1221    1200.00    300.00  kubelet
12:18:02 PM   999      3456   22000.00   9000.00  java

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

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

Завдання 14: Переконайтеся, що ядро бачить правильні міри захисту (виробничі зміни продуктивності)

cr0x@server:~$ grep -E "Mitigation|Vulnerable" /sys/devices/system/cpu/vulnerabilities/* | head
/sys/devices/system/cpu/vulnerabilities/meltdown:Mitigation: PTI
/sys/devices/system/cpu/vulnerabilities/spectre_v1:Mitigation: usercopy/swapgs barriers and __user pointer sanitization
/sys/devices/system/cpu/vulnerabilities/spectre_v2:Mitigation: Retpolines; IBPB: conditional; STIBP: disabled; RSB filling

Що це означає: Ви не можете ігнорувати міри безпеки; вони впливають на навантаження з великою кількістю системних викликів і переключень контексту.

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

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

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

Перший крок: вирішіть, чи ви CPU-bound, IO-bound або чекаєте на щось інше

• Запустіть mpstat, щоб побачити idle, iowait і steal time.
• Запустіть vmstat, щоб побачити чергу runnable r і wait wa.
• Перевірте load average з uptime, але не сприймайте його як істину — сприймайте як дим.

Якщо %idle низький і r високий, ви ймовірно CPU-bound.
Якщо %iowait високий або з’являються заблоковані процеси, ви IO-bound.
Якщо %steal високий у VM, вас «ограбовує» гіпервізор.

Другий крок: класифікуйте тип болю CPU (обчислення vs пам’ять vs планувальник)

• Використовуйте perf stat для IPC і пропусків кешу. Низький IPC + високі пропуски вказують на затримки пам’яті.
• Використовуйте pidstat -w для переключень контексту. Високі переключення вказують на конкуренцію або надто велику кількість потоків.
• Перевірте NUMA з numactl --hardware і розміщення пристроїв з lspci.

Третій крок: шукайте платформно-специфічні пастки

• Тротлінг у dmesg (теплові/powercap).
• Нерівномірність переривань у /proc/interrupts.
• Невідповідний governor частоти у cpupower frequency-info.
• Steal time у віртуалізації: вирішуйте розміри хоста, а не CPU гостьової ОС.

Четвертий крок: вирішіть, що змінювати

• Якщо CPU-навантаження і масштабується з попитом: додайте ядра або розділіть сервіс.
• Якщо затримки пам’яті: віддайте пріоритет кешу/каналам пам’яті; розгляньте менше швидших ядер над багатьма повільними.
• Якщо NUMA/топологія: закріпіть, вирівняйте пристрої або віддайте перевагу односокетним рішенням для латентних рівнів.
• Якщо теплові/енергійні: виправте охолодження або припиніть купувати SKU, які ви не можете підтримувати.

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

1) Симптом: p99 латентність погіршилась після «апгрейду»

Корінь: Віддалений доступ до пам’яті NUMA, IRQ на неправильному сокеті або нестабільність частоти під навантаженням.

Виправлення: Закріпіть процеси і пам’ять, вирівняйте NIC/NVMe до того самого NUMA-вузла, встановіть відповідний governor і перевірте відсутність тротлінгу.

2) Симптом: CPU-використання високе, але пропускна здатність не зростає з додатковими ядрами

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

Виправлення: Виміряйте IPC і пропуски кешу, зменшіть кількість потоків, шардуйте або розбивайте роботу, або оберіть CPU з кращим кешем/підсистемою пам’яті замість більшої кількості ядер.

3) Симптом: «випадкові» сплески під час пікового трафіку

Корінь: Шторм переривань, шумні сусіди (steal), фонова робота (scrub, compaction), або тепловий тротлінг.

Виправлення: Ізолюйте ядра для IRQ і фонової роботи, резервуйте CPU, запускайте довгі канарки і аудитуйте термал під тривалим навантаженням.

4) Симптом: Load average високий, але CPU не зайнятий

Корінь: Завдання заблоковані в I/O, латентність зберігання або очікування ядра; load average рахує runnable і uninterruptible задачі.

Виправлення: Перевірте %iowait, статистику зберігання і заблоковані процеси. Оновіть зберігання або виправте шлях I/O; не купуйте CPU, щоб компенсувати повільні диски.

5) Симптом: Сервер зберігання не досягає очікуваних швидкостей NVMe

Корінь: Перенавантаження топології PCIe, неправильне підключення у слоті, спільний root complex або накладні витрати CPU на контрольні суми/паритет/шифрування.

Виправлення: Перевірте розміщення PCIe, переконайтесь у достатній кількості ліній, виміряйте вартість CPU для фіч зберігання і зарезервуйте CPU для фонових робіт.

6) Симптом: Бенчмарк виглядає чудово, а продакшен — посередньо

Корінь: Бенчмарк використовує один потік, вміщується в кеш або працює 30 секунд. Продакшен працює дні і весь час пропускає кеш.

Виправлення: Бенчмарк з реальними розмірами датасетів, конкуренцією і тривалістю. Використовуйте канарковий трафік і SLO-ворота.

7) Симптом: Продуктивність змінилася після оновлення фірмверу/мікрокоду

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

Виправлення: Ставтеся до фірмверу як до релізу: тестуйте, вимірюйте, зафіксуйте налаштування BIOS і документуйте «відомо-добру» конфігурацію для вашого флоту.

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

Покроково: як обрати правильний CPU на 5-річний горизонт

1. Запишіть реальний мікс навантажень. Включіть фонів задачі (резервні копії, scrubs, compaction, агенти спостереження).
2. Визначте метрики успіху. Пропускна здатність, p99 латентність, вартість за запит, час завершення. Виберіть дві, а не десять.
3. Зберіть докази поточних вузьких місць. Використовуйте mpstat, vmstat, perf stat, NUMA і карту I/O.
4. Класифікуйте форму навантаження. Критична до латентності vs пропускна здатність vs змішана віртуалізація vs тяжка на зберігання.
5. Спочатку оберіть обмеження платформи. Один чи два сокети, канали/ємність пам’яті, лінії PCIe, план NIC/HBA, живлення і охолодження в стійці.
6. Виберіть 2–3 кандидатні SKU. Один «безпечний», один «продуктивний», один «оптимізований за вартістю».
7. Запустіть реалістичні бенчмарки. Той самий kernel, ті самі міри захисту, той самий розмір датасету, та сама тривалість запуску.
8. Зробіть канарку в продакшені. Дзеркальний трафік, достатній час, щоб вдарити по термалам і циклам обслуговування.
9. Зафіксуйте налаштування BIOS і фірмверу. Документуйте їх. Робіть відтворюваними по всьому флоту.
10. Прийміть рішення з письмовим обґрунтуванням. Включіть, що ви оптимізуєте, на що йдете на компроміс і які докази.

Контрольний список: не потрапити в засідку в 3-му році

• Слоти пам’яті вільні для розширення, а не заповнені повністю на день один, якщо це не потрібно.
• Резерв ліній PCIe для додавання NVMe або швидших NIC пізніше.
• Тепловий запас протестований під тривалим навантаженням у вашому реальному шасі.
• Запас для фонових робіт (scrub, compaction, індексація, резервні копії).
• Перевірка ланцюга постачання: чи можна буде купити ту саму платформу пізніше?
• Готовність операційних інструментів: чи можна спостерігати використання по ядру, тротлінг і NUMA-проблеми?

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

• Governor CPU / профіль енергоспоживання
• Політика SMT (on/off) для кожного класу навантажень
• Політика балансування NUMA і стратегія pinning
• IRQ affinity і конфігурація черг NIC
• Стратегія фіксації версій мікрокоду і фірмверу
• Політика міри захисту ядра відповідно до безпекової позиції

Поширені запитання

1) Чи треба купувати максимальну кількість ядер, аби «заздалегідь захиститися»?

Ні. Купуйте правильний мікс. Багато ядер без пропускної здатності пам’яті і ефективності кешу часто погіршують p99 і підвищують вартість.
«Захист від майбутнього» зазвичай — ємність пам’яті + резерв PCIe + передбачувана стійка продуктивність.

2) Чи односокетна завжди краща за двосокетну?

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

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

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

4) Як зрозуміти, чи моє навантаження обмежене латентністю пам’яті?

Низький IPC, високі пропуски кешу/LLC і слабке масштабування з додатковими ядрами — класичні ознаки. Використовуйте perf stat для порівняння instructions vs cycles і пропусків кешу,
та валідуйте з розмірами датасетів, що відповідають продакшену.

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

Не марні — небезпечні, коли використовуються самі по собі. Вони корисні для відлову очевидних регресій і дефектів апаратури.
Вони погані у передбаченні хвостової латентності, NUMA-ефектів, питань топології I/O і стійкої теплової поведінки.

6) Що важливіше для хостів віртуалізації: ядра чи частота?

Обидва, але не забувайте пам’ять. Консолідація потребує ядер; шумні орендарі і накладні мережі/зберігання часто карають слабку продуктивність на ядро.
Для змішаних навантажень зазвичай потрібен збалансований CPU і сильна ємність/пропускна здатність пам’яті.

7) Якщо ми використовуємо ZFS або Ceph, чи варто пріоритетизувати CPU більше звичайного?

Так. Сучасні фічі зберігання — це фічі, що споживають CPU: контрольні суми, стиснення, шифрування, паритет і фонове обслуговування.
Також віддавайте пріоритет пам’яті (ARC, метадані, кешування) і топології PCIe, щоб ваші швидкі диски не зазнавали блокування вгорі.

8) Коли раціонально платити за «топ-бін» частини?

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

9) Як думати про споживання енергії за п’ять років?

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

10) Який найбільший «показник», що ми обираємо CPU за логотипом?

Коли оцінка закінчується «цей бенчмарк вищий», без уточнення, яку метрику ви оптимізуєте (p99 vs пропускна здатність) і без плану канарки.
Якщо ви не можете описати своє вузьке місце вимірюваннями, ви купуєте емоційно.

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

Якщо ви хочете рішення по CPU, про яке не будете шкодувати п’ять років, зробіть зараз негарні справи:

1. Профілюйте один репрезентативний хост за допомогою наведених вище команд і запишіть, що саме вас обмежує.
2. Визначте вашу головну метрику: p99 латентність, пропускна здатність або вартість за одиницю. Виберіть одну первинну і одну вторинну.
3. Складіть список кандидатів з 2–3 CPU і врахуйте обмеження платформи: канали пам’яті, лінії PCIe і охолодження.
4. Запустіть тривалий тест (години, а не хвилини). Включіть фонезйні роботи (scrub, резервні копії, compaction) у вікно тесту.
5. Зробіть канарку в продакшені з дзеркальним трафіком і перемикачем для відкату. Нудно, так. Ефективно — безумовно.
6. Задокументуйте рішення з доказами: що ви виміряли, що обрали і що свідомо не оптимізували.

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