Чи достатньо 8 ядер у 2026 році? Чесна відповідь

Чесна відповідь: кому 8 ядер ще підходять (і кому — ні)

8 ядер покривають «усіх» тільки якщо ваш понятійний зріз «усіх» застряг у 2018 році. У 2026 році 8-ядерний CPU може бути відмінним. Він також може бути тихим гальмом, що марнує дорогі GPU, гальмує CI-пайплайни й призводить до падіння продакшн-вузлів у найневідповідніший момент.

8 ядер все ще достатньо для:

• Типової офісної роботи (браузер, документи, Slack, відеодзвінки), навіть з кількома «важкими» вкладками. Тут важливіша пам’ять, аніж ядра.
• Ігор на розумних налаштуваннях, особливо якщо рушій гри все ще залежить від декількох «гарячих» потоків. Сильна одноядерна продуктивність важливіша, ніж 16 посередніх ядер.
• Легкої творчої роботи (інколи редагування фото, невеликі проекти у DAW, хобі-відеомонтаж), якщо ви не запускаєте одночасно кілька важких додатків.
• Більшість домашніх лабораторних сервісів (DNS, Home Assistant, кілька контейнерів, невеликий NAS), за умови що сховище не виконує важкої inline-компресії/шифрування на CPU.
• Розробки на одній машині, якщо ваш робочий процес не передбачає постійних перекомпіляцій величезних кодових баз або одночасної роботи кількох БД локально.

8 ядер часто недостатньо для:

• Серйозних збірок ПЗ (C++ монорепозиторії, великі проєкти на Rust, Android-збірки). Ви можете паралелити збірки, але не можете паралелити брак ядер без витрат часу.
• CI-ранерів, де конкурування — це гроші. Недокомплектні ранери перетворюють «швидку команду» на експеримент з теорії черг.
• Сучасної реальності “робочої станції розробника”: IDE, браузер, локальний Kubernetes, кілька language server-ів, пара БД і агенти безпеки. Це робота, яка вбиває по-тихому тисячами потоків.
• Хостів з важкою віртуалізацією (кілька VM, що реально працюють). Overcommit — інструмент, а не стиль життя.
• Стеків зберігання, що виконують реальну роботу (дедуплікація, компресія, шифрування, контрольні суми при високій пропускній спроможності). Сховище може бути жадібним до CPU, особливо якщо ви хочете і швидкість, і цілісність.
• Продакшн-вузлів для сервісів з чутливою до затримок поведінкою, коли висока кількість з’єднань, TLS скрізь і фонова робота (GC, compaction, індексація) не питають дозволу.

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

Кількість ядер — не тотожність продуктивності (і «8 ядер» взагалі не однорідне поняття)

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

Чотири осі продуктивності, які люди плутають

1. Однопотокова продуктивність: частота під навантаженням, IPC, ієрархія кешу, прогнозування переходів. Ось чому деякі 8-ядерні чіпи відчуваються живими, а деякі 16-ядерні — ні.
2. Паралельна пропускна здатність: скільки роботи ви можете виконати, коли навантаження справді масштабується по ядрах. Компілятори, рендери, енкодери, CI, деякі завдання БД.
3. Ємність і пропускна здатність пам’яті: ядра не допоможуть, якщо ви свопите або якщо всі ядра конкурують за пропускну здатність RAM.
4. Затримка та пропускна здатність I/O: сховище, мережа, поведінка файлової системи та патерн I/O додатку. Багато «проблем з CPU» — це проблеми I/O в костюмі CPU.

У 2026 році «8 ядер» може означати зовсім різні речі. Є процесори, де 8 «продуктивних» ядер — монстри, і є системи, де 8 ядер — суміш продуктивних і ефективних ядер з дуже різною поведінкою планувальника. Є також системи, де CPU майже простаїв, бо ви заблоковані на латентності NVMe, мережевих хвостах або конкуренції за блокування.

Ще одне: ваша ОС і середовище виконання мають значення. Контейнери, cgroups, прив’язка VM, керування частотою CPU та ефекти «голосного сусіда» можуть зробити «8 ядер» схожими на «5 ядер по вівторках».

Жарт №1: Якщо ви коли-небудь говорили «але в нього 8 ядер» у відгуку про продуктивність — вітаю — ви зустріли дорослий варіант «але я перезавантажував».

Факти та історія, що пояснюють плутанину

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

• Факт 1: Довгі роки мейнстрімні споживчі CPU застрягали близько 4 ядер, головно тому, що покращення одноядерної продуктивності ще давало виграш, і багато навантажень погано масштабувалися. Потім кількість ядер швидко зросла, коли змінилися технологічні та ринкові умови.
• Факт 2: Hyper-threading (SMT) заплутав людей, змусивши думати «потоки = ядра». SMT допомагає пропускній здатності в деяких навантаженнях, ледве допомагає в інших і може погіршувати хвостову затримку в умовах сильної конкуренції.
• Факт 3: Наприкінці 2010-х — початку 2020-х 8 ядер стало «солодкою точкою», бо ігри та загальне використання десктопа вигравали більше від сильної одноядерної продуктивності й помірної паралельності, ніж від великої кількості ядер.
• Факт 4: Поширення TLS (HTTPS скрізь, service mesh, mTLS) збільшило обсяг роботи CPU на запит. Сучасні сервіси виконують більше криптографії й парсингу, ніж старі стекі.
• Факт 5: NVMe знизив латентність сховища й збільшив пропускну здатність, що виявило накладні витрати CPU у місцях, де їх раніше не очікували — контрольні суми, компресія, накладні витрати ядра, обслуговування файлової системи та БД.
• Факт 6: «Мікросервіси» змінили не тільки архітектуру; вони змінили локальну розробку й тестування. «Просто сервіс» часто означає запуск маленького міста залежностей.
• Факт 7: Сучасні CPU стали більш асиметричними в деяких лінійках (продуктивні проти енергоефективних ядер). Сира «кількість ядер» може приховувати, що ваші 8 ядер не є рівними між собою.
• Факт 8: Хмарна економіка штовхнула команди до більшої консолідації. Вища консолідація підвищує ризик від взаємного впливу і робить помилки у підборі CPU дорожчими.
• Факт 9: Обсервабельність стала краще, але й важчою. Метрики, трейсинг та логування можуть споживати реальний CPU — особливо під час інцидентів, коли ви вмикаєте «трохи більше деталей».

Коли люди питають «чи достатньо 8 ядер», насправді вони питають: «чи буде ця система швидкою у найгірший мій день?» Це не питання специфікації. Це питання навантаження.

Матриця рішень, якою можна справді користуватися

Ось відверта версія. Почніть з вашого основного навантаження, потім налаштуйте під конкуренцію і «фонову реальність».

Обирайте 8 ядер у 2026, якщо:

• Ви віддаєте пріоритет інтерактивності одного користувача і ваш CPU має сильну одноядерну продуктивність.
• Ваші важкі завдання сплескові (періодичні збірки, експорт) і ви можете терпіти іноді очікування.
• Ви не запускаєте кілька важких сервісів локально і не віртуалізуєте багато VM.
• Ваше сховище швидке і просте (NVMe, без важкої inline-шифрації/компресії на NAS-рівні).

Купуйте 12–16+ ядер, якщо:

• Ви часто робите збірки, рендери, кодування.
• Вам важлива пропускна здатність, а не просто «чутливість» (CI, пакетні задачі, обробка даних, хости контейнерів).
• Ви запускаєте локальний Kubernetes або багато контейнерів і хочете, щоб вони були швидкими одночасно.
• Ви запускаєте VM, які реально працюють, і хочете ізоляцію без постійної конкуренції за CPU.
• Ви запускаєте локальні бази даних з реалістичними наборами даних і хочете передбачуваної затримки під час іншої роботи.

Не вирішуйте тільки за кількістю ядер

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

Мій операційний підхід: якщо можете дозволити — купіть достатньо ядер, щоб зберегти 30–40% запасу під час нормального піку. Запас — це те, що поглинає сплески деплоїв, фонові компакти, антивірусні сканування й «сюрпризне» навантаження, яке хтось запустить посеред інциденту.

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

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

Завдання 1: Підтвердити, що «8 ядер» означає на цій машині

cr0x@server:~$ lscpu
Architecture:                         x86_64
CPU(s):                               16
Thread(s) per core:                   2
Core(s) per socket:                   8
Socket(s):                            1
Model name:                           ExampleCPU 8-Core Processor

Значення: У вас 8 фізичних ядер і SMT ввімкнено, отже 16 логічних CPU. Тут «8 ядер» — це реальні ядра, а не маркетинг.

Рішення: Для сервісів, чутливих до затримки, ставтеся до SMT-потоків як до часткової пропускної здатності. Для пропускних навантажень SMT може допомогти. Перевіряйте навантаження тестами.

Завдання 2: Перевірити поведінку частот під навантаженням (тротлінг — тихий вбивця)

cr0x@server:~$ grep -E "cpu MHz" /proc/cpuinfo | head
cpu MHz         : 3592.000
cpu MHz         : 3610.123
cpu MHz         : 3588.765

Значення: Поточні частоти близькі до очікуваного бусту. Якщо частоти падають під тривалим навантаженням, ваші 8 ядер можуть поводитися як 6.

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

Завдання 3: Визначити — насичення CPU чи тиск черги runnable

cr0x@server:~$ uptime
 14:22:10 up 12 days,  3:18,  2 users,  load average: 12.45, 10.80, 9.92

Значення: Load average ~12 на системі з 16 потоками не автоматично «погано», але натякає на чергування. На коробці з 8 фізичними/16 логічними потоками тривале навантаження > 16 часто означає конкуренцію або блокований I/O, який рахується як runnable.

Рішення: Якщо load average високий і затримка погана, переходьте до глибших перевірок (черга run, iowait і головні споживачі). Не купуйте ядра, поки не підтвердите, що причина — CPU.

Завдання 4: Подивитися, чи ви CPU-bound або чекаєте на I/O

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

01:22:11 PM  CPU   %usr  %nice  %sys  %iowait  %irq  %soft  %steal  %idle
01:22:12 PM  all  62.00   0.00  12.00    0.50   0.00   1.20    0.00  24.30
01:22:13 PM  all  64.50   0.00  11.20    0.40   0.00   1.10    0.00  22.80

Значення: Високий %usr при низькому %iowait підказує, що робота — CPU. Високий %iowait вказує на вузьке місце в зберіганні або блокований I/O.

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

Завдання 5: Знайти процесні пожирачі CPU (і чи вони масштабуються)

cr0x@server:~$ top -b -n 1 | head -20
top - 14:22:40 up 12 days,  3:19,  2 users,  load average: 12.10, 10.90, 10.05
Tasks: 312 total,   3 running, 309 sleeping,   0 stopped,   0 zombie
%Cpu(s): 63.2 us, 11.4 sy,  0.0 ni, 24.7 id,  0.5 wa,  0.0 hi,  0.2 si,  0.0 st
  PID USER      PR  NI    VIRT    RES    SHR S  %CPU  %MEM     TIME+ COMMAND
18422 app       20   0 2316828 221340  36204 R  690.0   1.3  12:10.12 java
 9912 db        20   0 4010320 820112  52320 S  220.0   4.8  41:22.90 postgres

Значення: Процес з 690% CPU використовує приблизно 7 ядер. Це реальна паралельність. Якщо це ваш критичний шлях — 8 ядер можуть швидко стати тісними.

Рішення: Для стійких багатоядерних споживачів (JVM, збірки, кодування) додайте ядра або ізолюйте навантаження через cgroups/контейнери/VM.

Завдання 6: Перевірити тиск пам’яті (своп видає себе за «повільний CPU»)

cr0x@server:~$ free -h
               total        used        free      shared  buff/cache   available
Mem:            32Gi        27Gi       1.2Gi       1.1Gi       3.8Gi       3.1Gi
Swap:          8.0Gi       2.4Gi       5.6Gi

Значення: Низький available плюс небезпечно активний swap — це ризик для продуктивності. Апгрейд CPU не врятує, якщо ви свопите.

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

Завдання 7: Підтвердити реальну активність свопінгу (а не лише виділений swap)

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
 4  0 248576 1184300  92160 2998200   0    0    15    40 1100 2200 61 12 26  1  0
 9  1 248576  954200  92160 2970000  80   120   600   980 1800 4200 35 10 45 10  0

Значення: Ненульові si/so означають активний swap in/out. Це може зруйнувати хвостову затримку.

Рішення: Якщо свопінг відбувається при звичайному навантаженні — розглядайте це як інцидент потужності. Додайте RAM, зменшіть конкуренцію або виправте витоки пам’яті перед дебатами 8 vs 16 ядер.

Завдання 8: Виявити сплески латентності сховища (класика «CPU простає, але все повільно»)

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

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
          40.12    0.00    8.10    9.80    0.00   41.98

Device            r/s     w/s   rMB/s   wMB/s  await  svctm  %util
nvme0n1          220.0   140.0   55.2    21.1   8.60   0.20  74.0

Значення: await — середній час на I/O. Якщо він високий (для NVMe «високим» може бути кілька мілісекунд під навантаженням залежно від патерну), ви блокуєтеся на зберіганні.

Рішення: Якщо await і %util високі, виправляйте шлях зберігання (глибина черги, файлову систему, налаштування БД, «галасливих сусідів») перед додаванням CPU.

Завдання 9: Перевірити простір файлової системи та виснаження інодів (так, таке буває)

cr0x@server:~$ df -h
Filesystem      Size  Used Avail Use% Mounted on
/dev/nvme0n1p2  900G  810G   45G  95% /

cr0x@server:~$ df -i
Filesystem       Inodes  IUsed    IFree IUse% Mounted on
/dev/nvme0n1p2  5900000 5800000 100000   99% /

Значення: Файлова система на 95% заповнена і виснаження інодів може зробити операції болісно повільними та ламати додатки дивними способами.

Рішення: Виправте тиск на диск спочатку. Апгрейд від 8 до 16 ядер не зробить повідомлення «no space left on device» оптимістичнішим.

Завдання 10: Виміряти мережеву насиченість і втрати (CPU може бути ні при чому)

cr0x@server:~$ ip -s link show dev eth0
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP mode DEFAULT group default qlen 1000
    RX:  bytes  packets  errors  dropped  missed  mcast
    9876543210  8123456  0       1200     0       0
    TX:  bytes  packets  errors  dropped  carrier collsns
    1234567890  2456789  0       800      0       0

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

Рішення: Якщо кількість дропів зростає з трафіком — налаштуйте qdisc, кількість буферів NIC або збільшіть пропускну здатність. Апгрейд CPU не виправить втрати пакетів.

Завдання 11: Перевірити CPU-тротлінг у контейнерах (ядра є, але вам не дозволено їх використовувати)

cr0x@server:~$ cat /sys/fs/cgroup/cpu.stat
usage_usec 12873422340
user_usec 10122344000
system_usec 2751078340
nr_periods 90321
nr_throttled 18200
throttled_usec 9234000000

Значення: Високі nr_throttled і throttled_usec означають, що cgroups обмежують CPU. У вузлі може бути 64 ядра; ваш контейнер може жити на дієті.

Рішення: Якщо тротлінг корелює з погіршенням затримки — підвищте ліміти/requests, налаштуйте квоти або розподіліть навантаження. Не звинувачуйте «8 ядер», якщо ви сконфігурували 2.

Завдання 12: Перевірити allocatable CPU вузла Kubernetes проти requests (виявлення ілюзії ємності)

cr0x@server:~$ kubectl describe node worker-01 | sed -n '1,120p'
Name:               worker-01
Capacity:
  cpu:                16
Allocatable:
  cpu:                15500m
Non-terminated Pods:          (22 in total)
Allocated resources:
  (Total limits may be over 100 percent, i.e., overcommitted.)
  Resource           Requests      Limits
  cpu                14000m (90%)  22000m (141%)

Значення: Requests на 90% означає, що планувальник вважає вузол майже заповненим. Limits на 141% означає, що ви overcommitted і ставитеся до того, що не всі будуть завантажені одночасно.

Рішення: Якщо ви бачите часті CPU-тротлінги або сплески затримки — зменшіть overcommit або перейдіть на вузли з більшим числом ядер (або більше вузлів).

Завдання 13: Знайти «шторми переключень контексту» (занадто багато runnable-потоків)

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

14:25:01   UID       PID   cswch/s nvcswch/s  Command
14:25:02  1001     18422   1200.00   8500.00  java
14:25:02  999       9912    800.00   2200.00  postgres

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

Рішення: Якщо преемпція висока і затримка погана — додайте ядра або зменшіть runnable-потоки (налаштуйте thread pools, concurrency, GC, фонві задачі).

Завдання 14: Перевірити %steal у віртуалізованому середовищі (хтось інший використовує «ваші» ядра)

cr0x@server:~$ mpstat 1 3 | tail -n +4
01:28:01 PM  all  48.00   0.00  10.00    0.20   0.00   0.90    6.50  34.40
01:28:02 PM  all  50.10   0.00  10.40    0.30   0.00   0.80    7.20  31.20

Значення: %steal близько 6–7% означає, що гіпервізор не віддає вам повний час CPU. Ваш інстанс може виглядати «нормально», але повільно працювати.

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

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

cr0x@server:~$ /usr/bin/time -v make -j8
        Command being timed: "make -j8"
        User time (seconds): 742.12
        System time (seconds): 91.44
        Percent of CPU this job got: 765%
        Elapsed (wall clock) time (h:mm:ss or m:ss): 1:48.92

Значення: ~765% CPU означає, що збірка використала близько 7.6 ядер ефективно. На 8-ядерній системі ви близькі до ліміту; будь-яка інша робота буде конкурувати за CPU.

Рішення: Якщо збірки — щоденний біль, переходьте на 12–16+ ядер або розподіляйте збірки. Це один із найчистіших випадків, де «більше ядер вирішує проблему».

Ось закономірність: не питайте «чи достатньо 8?» Питайте «де я блокуюся й що це мені коштує?» І потім підбирайте відповідний розмір.

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

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

По-перше: визначте, чи ви CPU-bound, memory-bound або I/O-bound

1. Швидкий погляд на CPU: mpstat -P ALL 1 3 і uptime. Якщо %idle низький і load високий — CPU-напруження реальне.
2. Швидкий погляд на пам’ять: free -h і vmstat 1 5. Будь-який активний swap — червона прапорова ознака для чутливості й хвостової затримки.
3. Швидкий погляд на I/O: iostat -xz 1 3. Якщо await росте і %util високий — ядра не ваші проблеми.

По-друге: знайдіть головного порушника і класифікуйте його

1. На рівні процесу: top або ps -eo pid,comm,%cpu,%mem --sort=-%cpu | head, щоб знайти домінуючого споживача.
2. На рівні потоків (якщо потрібно): високі контекстні перемикання (pidstat -w) можуть виявити конкуренцію, вибух пулів потоків або GC-треш.
3. На рівні контейнера: перевірте тротлінг cgroup (/sys/fs/cgroup/cpu.stat) перед тим, як звинувачувати залізо.

По-третє: підтвердіть одним малим експериментом

• Зменшіть конкуренцію (знизьте кількість воркерів) і подивіться, чи покращується затримка. Якщо так — ви щось насичуєте.
• Прив’яжіть та ізолюйте (перенесіть галасливу задачу на інший вузол/VM) і перевірте, чи відновлюється сервіс. Якщо так — потрібні або більше ядер, або краща ізоляція.
• Змініть патерн I/O (записи пакетами, налаштуйте контрольні точки БД, вимкніть патологічний debug-log) і перевірте, чи падає await.

Тільки після цього вирішуйте, чи 8 ядер недостатньо. Мета — купити правильне рішення, а не заспокійливе.

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

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

Середня компанія запускала внутрішній API за кеш-слоєм. Вони мігрували на нові інстанси і стандартизувалися на «8 ядер, достатньо RAM» для кеш-вузлів, бо кеш в основному тримав гарячі дані і мало що обчислював. Так вони думали.

Міграція співпала з двома іншими змінами: увімкненням TLS між сервісами (mTLS) і включенням стиснення payload для великих відповідей. Жодне з цих рішень не було спірним. Разом вони створили ідеальний шторм на 8-ядерних кеш-вузлах під піковим трафіком: шифрування, стиснення і надмірно балакучий агент обсервабельності розділяли один бюджет CPU.

Під час звичайного пікового навантаження p95 затримки подвоїлась. Потім p99 став нелінійним. Коефіцієнт попадання кешу майже не змінився, що спочатку вводило в оману. Графіки CPU показували «лише» 70–80% завантаження, що виглядало нормально для менеджерів. Але черга runnable була високою, контекстні переключення шаленіли, і система витрачала занадто багато часу на перемикання потоків, які всі прагнули зробити дрібні частини роботи.

Виправлення не було магічною налаштуванням ядра. Вони підняли кількість ядер до 16 на кеш-вузлах і зменшили накладні витрати на запит шляхом пакетування метрик. Затримка повернулась у норму. Урок був неприємний: коли ви додаєте CPU-коштовні фічі (TLS, компресію, трейси), ваш «простіший» шар перестає бути простим.

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

Міні-історія 2: Оптимізація, що зламала (перетворення всього на «більше паралелі» на 8 ядрах)

Інша організація мала сервіс інгесту даних, який «був занадто повільний». Інженер зробив те, що роблять розумні інженери: збільшив конкурування. Більше потоків. Більше goroutine. Більші thread pool-и. Сервіс в основному робив невеликі трансформації і записував у базу даних — ідеальний кандидат для паралелізації, здавалося б.

На 8-ядерних хостах пропускна здатність покращилася в синтетичних тестах. У продакшені затримка пішла убік. CPU не був повністю завантажений, але хвостова затримка стала жахливою. Команда БД скаржилась на шалену зміну з’єднань. SRE помітили зростання контекстних переключень і блокувань у рантаймі додатка. Iowait диска підскочив, бо БД тепер отримувала сплески записів і робила частіші fsync.

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

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

Жарт №2: Підвищувати concurrency без backpressure — це як додавати смуги на шосе, малюючи лінії на капоті вашого авто.

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

Команда фінансових сервісів запускала набір сервісів на Kubernetes. Їх типовий тип вузла — 16 ядер, але вони тримали пул 8-ядерних вузлів для «дрібних» і dev-воркслендів. Нудна практика: вони вимагали requests, які відображали реальність, тримали запас CPU і використовували pod disruption budgets із продуманістю.

Одного дня пакетна задача, яка мала запускатися щотижня, запустилася кілька разів через upstream-баг у планувальнику. Вона потрапила в пул малих вузлів, бо на папері «виглядала маленькою». Насправді вона не була малою: виконувала важке стиснення і обчислення контрольних сум на багатогігабайтних файлах і відправляла результати по мережі.

Різниця від попередніх історій — дисципліна. Вузли мали запас, а задача мала CPU-ліміт, який не дозволив їй захопити все. Задача виконалась повільніше, так. Але сервіси з клієнтами не впали. Сигнали спрацювали, люди відреагували, і вони перемістили задачу до великого пулу, поки фіксили баг планувальника.

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

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

1) Симптом: CPU «лише» 60–70%, але затримка жахлива

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

Виправлення: перевірте uptime load average, pidstat -w на контекстні переключення та cgroup cpu.stat на тротлінг. Зменшіть concurrency, налаштуйте thread pools або підвищте CPU limits.

2) Симптом: система «пригальмовує» кожні кілька хвилин

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

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

3) Симптом: інтерактивний десктоп гальмує, але бенчмарки нормальні

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

Виправлення: перевірте стійкі частоти, змініть енергетичний профіль/губернатора, покращте охолодження і не запускайте локальний Kubernetes плюс три БД на 8-ядерному ноутбуці, якщо ви хочете «швидкості».

4) Симптом: CPU бази даних високий після ввімкнення компресії/шифрування

Корінна причина: накладні витрати CPU змістилися зі сховища в обчислення. Компресія може змінити I/O на CPU; шифрування додає витрати на сторінку/з’єднання.

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

5) Симптом: продуктивність VM непослідовна на однакових «8-ядерних» інстансах

Корінна причина: %steal через контенцію на хості або галасливі сусіди.

Виправлення: перевірте %steal. Перейдіть на виділені хости, зменшіть oversubscription або обирайте типи інстансів з кращими гарантіями.

6) Симптом: CI-пайплайн сповільнився зі зростанням команди

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

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

7) Симптом: «Ми оновили до 16 ядер і нічого не змінилося»

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

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

8) Симптом: CPU сервера зберігання гарячий під час бекапів

Корінна причина: накладні витрати на контрольні суми/компресію/шифрування або випадковий I/O дрібних блоків, що створює накладні витрати ядра і файлової системи.

Виправлення: налаштуйте розміри блоків/записів, тонко підберіть компресію, відвантажте шифрування або додайте ядра. Також перевірте, чи не насичене сховище (await/%util).

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

Чеклист A: Купівля CPU для робочої станції у 2026

1. Перелічіть три найважчих навантаження (збірки, кодування, локальний кластер, VM). «Веб-серфінг» — не тривалий профіль, якщо ви не працюєте в ad tech.
2. Оцініть реальну конкуренцію: кількість VM, контейнерів, завдань IDE, фонвих агентів.
3. Визначте, що оптимізуєте: інтерактивність (одноядерну) чи пропускну здатність (багатоядерну). На кожному бюджету не вдасться максимізувати і те, і інше.
4. Поставте ціль по запасу: прагніть, щоб звичайний пік ≤ 70% CPU. Якщо ви завжди на 90% — ви живете в часовій шкалі інциденту.
5. Не економте на RAM: якщо ви обговорюєте 8 vs 16 ядер і маєте 16GB RAM — ви оптимізуєте не ту частину.
6. Перевірте зберігання: швидкий NVMe зі стабільною латентністю зробить 8-ядерну систему кращою за 16-ядерну на жалюгідному сховищі.

Чеклист B: Розмір вузла сервера (хост VM, робочий вузол Kubernetes, БД)

1. Виміряйте поточний CPU на одиницю роботи: запитів в секунду, задач за хвилину, збірок за годину. «CPU%» — це не одиниця роботи.
2. Знайдіть поведінку p95 і p99: середнє завантаження брешуть. Хвостова затримка — там, де виявляються paging і конкуренція.
3. Перевірте steal time (віртуалізовано): якщо є steal — ваша кількість ядер — фікція.
4. Підтвердіть латентність I/O: якщо await сховища стрибає — додаткові ядра лише пришвидшать очікування.
5. Плануйте ізоляцію: відокремте шумні пакетні задачі від сервісів, чутливих до затримки, через node pools, cgroups або виділені інстанси.
6. Прогнозуйте для фіч: TLS, компресія, трейси, міграції схем, побудова індексів. Це не безкоштовно.

Чеклист C: Якщо ви змушені лишити 8 ядер — як це зробити працюючим

1. Зменшіть неконтрольовану конкуренцію: thread pools, worker counts, async fan-out.
2. Забезпечте backpressure: обмежені черги, timeouts, circuit breakers.
3. Пакетуйте I/O: менше fsync, менше дрібних записів, менше системних викликів мережі.
4. Прив’язуйте важкі задачі: відокремлюйте CPU або ізолюйте через cgroups, щоб захистити критичний шлях.
5. Тримайте пам’ять здоровою: уникайте свопу при постійному навантаженні.
6. Не запускайте все на всіх машинах: локальні dev-стеки потребують дисципліни (або більше ядер).

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

Цитата (парафразована ідея): Werner Vogels неодноразово підкреслював думку, що «все ламається, весь час», тому проектуйте і оперуйте з урахуванням відмов і варіабельності.

FAQ

1) Чи достатньо 8 ядер для ігор у 2026?

Зазвичай так — якщо ці 8 ядер мають сильну одноядерну продуктивність і у вас достатньо RAM. Багато ігор і досі звужуються по кількох основних потоках. Якщо ви стрімите, запускаєте голос/відео і тримаєте купу вкладок, додаткові ядра допоможуть згладити роботу.

2) Чи достатньо 8 ядер для розробки ПЗ?

Для малих і середніх проєктів — так. Для великих кодових баз, частих збірок, кількох language server-ів, локальних контейнерів і БД 8 ядер стають тим рівнем, при якому постійно «втоплюєтсья вентилятор». Якщо збірки щоденні — 12–16+ ядер окупаються в часі.

3) Чому мій 8-ядерний CPU показує 16 CPU в Linux?

Бо SMT/hyper-threading виставляє по два логічні потоки на ядро. Це може підвищити пропускну здатність, але не подвоює продуктивність. Ставтеся до цього як до бонусу, а не як до заміни справжніх ядер.

4) Якщо завантаження CPU низьке, чому система повільна?

Тому що ви можете бути заблоковані на I/O, чекати на блокування, тротлитися cgroups або страждати від пам’ятного тиску. Використовуйте iostat, vmstat та метрики контекстних переключень, щоб знайти справжнє вузьке місце.

5) Що обрати: менше швидших ядер чи більше повільніших?

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

6) Чи завжди більше ядер покращує бази даних?

Ні. Багато задач баз даних упираються в латентність сховища, блокування або пам’ять. Деякі задачі (компресія, окремі запити, фонове обслуговування) добре масштабуються по ядрах; інші — ні. Вимірюйте: CPU-час на запит, iowait і конкуренцію.

7) Чи допоможе перехід з 8 на 16 ядер контейнерам?

Тільки якщо вашим контейнерам дозволено їх використовувати. CPU-limits і квоти можуть тротлити вас. Також, якщо у вас дефіцит пам’яті або I/O-обмеження — більше ядер не вирішать проблему.

8) Чи достатньо 8 ядер для домашнього NAS?

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

9) Який найпростіший знак, що мені точно потрібно більше ніж 8 ядер?

Тривалий високий CPU-пресинг під час ваших критичних робочих процесів плюс доказ того, що навантаження масштабується по паралельності (наприклад, збірки, що регулярно показують 700–800% CPU або черги на CI-ранерах).

10) А якщо я в хмарі і не можу «купити CPU»?

Ви все одно орендуєте ядра. Перевірте %steal, впевніться, що вас не тротлять, і обирайте сімейства інстансів за навантаженням: compute-optimized для CPU-bound, memory-optimized для кеш-хеві, storage-optimized коли домінує I/O.

Висновок: практичні кроки (без героїзму)

Чи достатньо 8 ядер для всіх у 2026? Ні. Вони покривають багато випадків і покривають їх добре — коли решта системи (RAM, латентність зберігання, термічні умови, обмеження планувальника) в порядку і навантаження в основному односпоживче.

Але «усі» нині включають розробників, які запускають міні-продакшн на своїх ноутбуках, команди, що безперервно збирають гігантські кодові бази, і сервіси, що за замовчуванням роблять криптографію та обсервабельність. У такому світі 8 ядер — не універсальна відповідь. Це відправна точка.

Що робити цього тижня

1. Пройдіть швидкий план діагностики на вашій найповільнішій системі або найдорожчому пайплайні. Визначте CPU vs пам’ять vs I/O.
2. Збережіть тиждень реальності: піки CPU, активність swap, await сховища і тротлінг/steal time. Не плануйте за тихим вівторком.
3. Визначте ціль: якщо потрібна інтерактивність — пріоритет одноядерної продуктивності і уникнення тротлінгу. Якщо потрібна пропускна здатність — купуйте ядра і зберігайте запас.
4. Виправте дешеві вузькі місця спочатку: swap, латентність I/O, тротлінг, неконтрольована конкуренція. Потім вирішуйте, чи потрібні додаткові ядра.

Якщо після всього цього 8 ядер все ще виглядають добре — насолоджуйтеся ними. Якщо ні — апгрейдьте впевнено і перестаньте сприймати кількість ядер як рису особистості.