Core і Core 2: повернення Intel після NetBurst (і чому це важливо для операцій)

January 13, 2026 • February 3, 2026 • Читання: 4 хв • Views: 0

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

Архітектуру процесора не відчуваєш у графіку бенчмарків. Її відчувають о 03:12, коли хвостова латентність стрибає, база даних раптом «зависає», а on-call намагається зрозуміти графік, що нагадує кардіограму.

Поворот Intel від NetBurst (Pentium 4, Pentium D) до Core/Core 2 — це не були маркетингові правки. Це був радикальний перегляд пріоритетів: виконаної роботи за цикл, передбачуваної латентності та теплового пакету, який реально охолодити. Якщо ви керуєте production-системами — або їх успадковуєте — розуміння цього переходу допоможе діагностувати збої, які досі з’являються під іншими назвами.

NetBurst: коли GHz стали продуктом

NetBurst — це ставка Intel початку 2000-х на те, що майбутнє за тактовою частотою. Епоха Pentium 4 навчила покупців ставити лише одне запитання: «Скільки GHz?» NetBurst намагався зробити це питання простим, підвищуючи частоту через дуже глибокий конвеєр і агресивні проєктні рішення, орієнтовані на високі тактові частоти.

І деякий час це спрацьовувало у вузькому сенсі: частота зростала. Але системи працюють не на кількості тактів; вони працюють на виконаній роботі. З точки зору експлуатації, NetBurst приніс неприємну комбінацію: велике енергоспоживання, теплові обмеження і продуктивність, що може сильно коливатися залежно від поведінки гілок, промахів кешу та латентності пам’яті.

Ось що вбивало production-навантаження:

Глибокі конвеєри означали, що промахи прогнозування переходів дорого обходилися. Якщо ваше навантаження має непередбачувані гілки (сжаття, шифрування, парсинг, VM exits), ви за це платите.
Висока щільність потужності означала, що ви швидше досягали теплових лімітів. Це проявляється як тротлінг, вентилятори на повній потужності і інциденти «чому цей вузол повільніший за свого близнюка?».
Залежність від Front-Side Bus утримувала доступ до пам’яті як спільний вузький горлечко. Якщо кілька ядер (привіт, Pentium D) конкурують за той самий шинний інтерфейс, латентність — це не теорія, це ваша черга.

NetBurst не був «поганою інженерією». Це була інженерія, оптимізована під ринкову мотивацію: продавати GHz. Платили за це всі, хто намагався запускати змішані навантаження наcommodity x86 серверах.

Короткий жарт №1: NetBurst був як обіцяти доставляти посилки швидше, купивши швидшу вантажівку, а потім виявити, що на вашому складі платформа прийому пропускає тільки одну вантажівку за раз.

Чому «гонка GHz» розвалилася в реальних системах

Швидкість годинника — це множник. Якщо роботи на такт мало, можна множити скільки завгодно і все одно не отримати бажаного. Глибина конвеєра в NetBurst збільшила вартість «ой» моментів — промахів прогнозування гілок, промахів кешу, скидань конвеєра. Сервери повні таких «ой» моментів, бо реальний продакшен-код заплутаний: багато гілок, багато переходів по вказівниках, багато очікування на пам’ять або I/O.

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

Core: момент «досить копати»

Архітектура Intel Core (спочатку в мобільних пристроях, потім ширше) фактично визнала, що NetBurst — не шлях до стійкої продуктивності. Внутрішня філософія змістилася в бік IPC (інструкцій за цикл), ефективності та збалансованого проєктування системи.

Якщо NetBurst був «ми будемо грубо нарощувати частоту», то Core сказав «ми робитимемо більше корисної роботи за такт і витрачати менше енергії даремно». Це означало покращення у:

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

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

Core 2: повернення, що прижилося

Core 2 (Conroe/Merom/Woodcrest) — це не просто «Core, але швидший». Він з’явився як реальна заміна для Pentium 4/Pentium D на десктопах і серверах і змінив закупівлі та планування потужностей практично за одну ніч.

Головні вигоди Core 2, помітні для ops:

Краще співвідношення продуктивності до ват: ви могли упакувати більше обчислень у той самий енергетичний бюджет, не перегріваючи стійку.
Сильніший IPC: навантаження з великою кількістю гілок або чутливі до пам’яті працювали краще без покладення на екстремальні частоти.
Спільний L2 кеш у багатьох конструкціях Core 2: два ядра могли співпрацювати, а не поводитися як сусіди, що борються за кухню.

І менш гламурна правда: Core 2 зробив продуктивність більш передбачуваною. Передбачуваність — це фіча SRE. Ви не можете автоскейлити хаотичну латентність.

Що означає «IPC важливіше за GHz» у продакшені

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

Core 2 не зробив латентність пам’яті невидимою. Він не усунув Front-Side Bus у тому поколінні. Але він поліпшив здатність ядра приховувати затримки і виконувати корисну роботу, тож менше циклів витрачалося даремно на очікування.

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

Конвеєр NetBurst відомий своєю глибиною (різні покоління Pentium 4 мали відмінну глибину), що збільшувало вартість промахів прогнозування і скидань конвеєра.
Pentium D фактично був двома ядрами NetBurst, запакованими разом, що часто посилювало конкуренцію за Front-Side Bus під багатопотоковим навантаженням.
Родовід Core значною мірою спирався на філософію P6 (епоха Pentium Pro/II/III): збалансований дизайн, сильніша робота за такт.
Core з’явився спочатку в мобільних пристроях, де енергоспоживання і тепловий режим — непохитні обмеження; ця дисципліна перейшла й у сервери.
Core 2 зробив «продуктивність на ват» метрикою ради директорів для x86-закупівель, а не лише аргументом для батареї ноутбука.
Багато дизайнів Core 2 використовували спільний L2 кеш, що зменшувало певний міжядерний трафік порівняно з окремими кешами, що борються за шину.
Маркетинг Intel переключив акцент з GHz на брендинг «Core», бо частота перестала бути надійним показником продуктивності.
TDP (Thermal Design Power) став операційно центральним: планування щільності стійок дедалі частіше використовувало вати як первинне обмеження.

Що це змінило для реальної операційної роботи

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

Латентність: чому Core 2 здавався «швидшим» навіть при нижчих частотах

Команди операцій часто бачать дві системи з подібним «CPU%», але які поводяться зовсім по-різному під навантаженням. Одна має стабільний p99. Інша падає в лавину латентності. За епохи NetBurst, глибші конвеєри і нижчий IPC означали, що невеликі неефективності перетворювалися на великі черги. Core 2 не усував усі обриви, але відсував їх і зробив схил менш крутим.

Живлення і терміка: менше непомітних уповільнень

Тротлінг через тепло — це баг продуктивності, який не видно у рев’ю коду. За NetBurst було легше досягти теплових лімітів, особливо у щільних стійках або при погано налаштованих кривих вентиляторів. Завдяки ефективності Core 2 ті самі умови навколишнього середовища рідше призводили до загадкових «різних швидкостей для однакових SKU».

Віртуалізація і консолідація: ера «запустимо більше на менше машин»

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

Одна інженерна цитата (перефразована ідея)

перефразована ідея: Надія — не стратегія — приписують у культурі ops генералу Gordon R. Sullivan. Ставтеся до планування CPU як до вимірюваного процесу: вимірюйте, а не бажайте.

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

Це порядок дій, який позбавить вас годин аргументів з графіками. Мета — відповісти: «Це CPU, пам’ять, contention планувальника чи щось інше, що прикидається CPU?»

Спочатку: підтвердьте, який саме «тип уповільнення» у вас

Це латентність (p95/p99) чи пропускна спроможність (requests/sec)? Проблеми з латентністю часто ховаються за «CPU лише 40%».
Перевірте чергу запуску та час steal. Якщо ви віртуалізовані, «CPU%» може бути брехнею.
Перевірте частоту і тротлінг. CPU, що застряг на низьких частотах, поводиться як повільний, а не як зайнятий.

Далі: визначте, чи CPU виконує корисну роботу

Високий %usr? Ймовірно, обчислення додатка або крипто/стиснення.
Високий %sys? Накладні витрати ядра: мережева робота, зберігання, перемикання контексту, contention замків.
Високий iowait? CPU чекає; вузьке місце — у сховищі або десь нижче по ланцюжку.

Третє: вирішіть, чи це обчислення, пам’ять чи contention

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

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

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

Task 1: Identify the CPU family and model (and infer era)

cr0x@server:~$ lscpu | egrep 'Model name|CPU\(s\)|Thread|Core|Socket|Vendor|MHz'
Vendor ID:                            GenuineIntel
Model name:                           Intel(R) Xeon(R) CPU           E5430  @ 2.66GHz
CPU(s):                               8
Thread(s) per core:                   1
Core(s) per socket:                   4
Socket(s):                            2
CPU MHz:                              2660.000

Значення: Імена моделей на кшталт «E5xxx» натякають на еру Core 2 у Xeon. Один потік на ядро може свідчити про відсутність Hyper-Threading на цьому SKU (або про його відключення). CPU MHz може показувати поточну, а не максимальну частоту.

Рішення: Якщо ви бачите симптоми низького IPC на системі епохи NetBurst, апгрейд — це не «приємна додатковість». Якщо у вас силікон епохи Core 2, зосередьтеся на пам’яті/шині та станах енергоспоживання, перш ніж звинувачувати «старий CPU».

Task 2: Check current frequency and governor (throttling suspicion)

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

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

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

Task 3: Validate actual frequency under load (not just “policy”)

cr0x@server:~$ grep -E 'cpu MHz' /proc/cpuinfo | head -4
cpu MHz		: 1596.000
cpu MHz		: 1596.000
cpu MHz		: 1596.000
cpu MHz		: 1596.000

Значення: Якщо 2.66GHz CPU працює близько ~1.6GHz під трафіком, або governor надто консервативний, або відбувається тротлінг по енергії/теплу.

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

Task 4: Quick “is it CPU, iowait, or steal?” snapshot

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

11:21:10 AM  CPU   %usr  %nice  %sys  %iowait  %irq  %soft  %steal  %idle
11:21:11 AM  all   62.10  0.00   8.20  0.30    0.00  1.10   0.00    28.30
11:21:11 AM    0   84.00  0.00   6.00  0.00    0.00  0.00   0.00    10.00
11:21:11 AM    1   81.00  0.00   7.00  0.00    0.00  0.00   0.00    12.00
11:21:11 AM    2   14.00  0.00   6.00  0.00    0.00  0.00   0.00    80.00
11:21:11 AM    3   12.00  0.00   5.00  0.00    0.00  0.00   0.00    83.00

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

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

Task 5: Check run queue and load relative to cores

cr0x@server:~$ uptime
 11:21:40 up 23 days,  4:18,  2 users,  load average: 12.40, 10.10, 8.50

Значення: Load average вище за кількість ядер (8) вказує на чергу runnable або незмінно заблоковані завдання (часто I/O). Тут значення явно вищі за 8.

Рішення: Якщо %iowait низький, але load високий — підозрюйте contention замків або занадто багато runnable-потоків; якщо %iowait високий — підозрюйте сховище.

Task 6: Spot context switch storms (contention smell)

cr0x@server:~$ vmstat 1 5
procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st
12  0      0  82136  10240 512000    0    0     1     3 2200 48000 62  8 28  1  0
11  0      0  82040  10240 512040    0    0     0     0 2100 51000 63  7 29  1  0
13  0      0  81980  10240 512120    0    0     0     0 2150 53000 61  8 29  1  0

Значення: Високе cs (контекстні переключення) вказує на contention, занадто багато потоків або часті пробудження. Високе r підтримує ідею черг runnable.

Рішення: Дослідіть пула потоків, гарячі точки замків і поведінку планувальника. Core 2 проти NetBurst не врятує додаток, який сам себе доводить до смерті контекстними переключеннями.

Task 7: Identify top CPU consumers immediately

cr0x@server:~$ ps -eo pid,comm,%cpu,%mem --sort=-%cpu | head
 24831 java            380.5 12.1
  1142 irq/24-eth0       85.0  0.0
  9876 postgres          72.1  4.2
  2210 ksoftirqd/1       40.3  0.0
  3333 nginx             18.0  0.3

Значення: Один процес Java, що споживає ~380% на восьмиядерній машині, свідчить про багатопотокові обчислення. Високі IRQ та softirq потоки вказують на мережеві накладні витрати або дисбаланс переривань.

Рішення: Якщо IRQ-потоки високі — налаштуйте IRQ affinity і NIC offloads. Якщо один процес домінує — профілюйте його замість «налаштування ядра».

Task 8: Look for interrupt imbalance (classic “one core pegged”)

cr0x@server:~$ cat /proc/interrupts | head -10
           CPU0       CPU1       CPU2       CPU3       CPU4       CPU5       CPU6       CPU7
 24:    9823412      12034      11022      10987      10221       9987       9876      10002  IR-PCI-MSI  eth0

Значення: Переривання eth0 приходять майже повністю на CPU0. Це ядро стає випадковим вузьким місцем.

Рішення: Виправте розподіл IRQ (irqbalance або ручна прив’язка). Це особливо важливо на старих платформах, де насичення одного ядра відбувається раніше.

Task 9: Confirm C-states and possible latency impact

cr0x@server:~$ cat /sys/devices/system/cpu/cpu0/cpuidle/state*/name
POLL
C1
C2
C3

Значення: Глибші C-state-и економлять енергію, але можуть додавати латентність пробудження. Системи епохи Core/Core 2 з агресивним управлінням живленням можуть здивувати вас під стрибкоподібним трафіком.

Рішення: Для ультранизької латентності обмежте глибші C-state-и через параметри ядра або BIOS. Вимірюйте до і після; не наслідуйте сліпо.

Task 10: Validate memory pressure vs CPU pressure

cr0x@server:~$ free -m
               total        used        free      shared  buff/cache   available
Mem:           16000       15200         120         180         680         420
Swap:           2048        1100         948

Значення: Невеликий обсяг available memory і використання swap можуть перетворити «проблему CPU» на катастрофу з пейджингом. CPU виглядає завантаженим, бо він займається промахами кешу і затримками пам’яті.

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

Task 11: See if storage latency is the real culprit (iowait lies sometimes)

cr0x@server:~$ iostat -xz 1 3
avg-cpu:  %user   %nice %system %iowait  %steal   %idle
          55.20    0.00    8.10    6.70    0.00   30.00

Device            r/s     w/s   rkB/s   wkB/s  avgrq-sz avgqu-sz   await  r_await  w_await  svctm  %util
nvme0n1         120.0   220.0  6400.0 11200.0     76.5     8.20   23.10    18.00    26.20   0.80  28.0

Значення: await близько ~23ms — це не надто добре для очікувань NVMe-подібних систем. Глибина черги підвищена. Навіть якщо CPU «зайнятий», латентність сховища може обмежувати прогрес.

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

Task 12: Capture top kernel/user hotspots with perf

cr0x@server:~$ sudo perf top -g --stdio --delay 2 --count 5
Samples: 5K of event 'cpu-clock:pppH', Event count (approx.): 1250000000
  18.20%  java            libjvm.so             [.] G1ScanRSForRegion
  12.10%  java            libjvm.so             [.] Unsafe_CopyMemory
   9.50%  vmlinuz         [kernel.kallsyms]     [k] tcp_recvmsg
   7.80%  vmlinuz         [kernel.kallsyms]     [k] __memcpy
   6.40%  postgres        postgres              [.] ExecHashJoin

Значення: У вас є реальні символи: сканування GC, копіювання пам’яті, шлях отримання TCP і hash join у базі. Це — дія.

Рішення: Якщо гарячі точки — memcopy/GC, швидше за все ви обмежені пропускною здатністю пам’яті; розгляньте налаштування алокатора/GC, батчинг і розташування даних. Якщо ядро TCP домінує — дивіться налаштування мережевого стека, пакетну інтенсивність і offloads.

Task 13: Detect CPU throttling from thermal/power constraints

cr0x@server:~$ sudo dmesg | egrep -i 'thermal|throttl|powercap' | tail -6
[102938.112] CPU0: Core temperature above threshold, cpu clock throttled
[102938.113] CPU0: Core temperature/speed normal

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

Рішення: Виправте повітряний потік, радіатори, ліміти BIOS живлення, криві вентиляторів, пил (так) і розміщення у стійці. Потім перетестуйте. Це не софтова помилка.

Task 14: Check if virtualization is stealing your cycles

cr0x@server:~$ mpstat 1 2 | tail -2
Average:     all   44.50    0.00    6.00    0.20    0.00    0.70   18.30   30.30

Значення: %steal ~18% — гіпервізор говорить вам: «ви хотіли CPU, але хтось інший отримав його».

Рішення: Перемістіть VM, відрегулюйте shares/limits або резервуйте CPU. Не налаштовуйте потоки додатка, поки ви не припините витік часу steal.

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

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

Середня компанія запускала pipeline аналітики клієнтів на змішаному флоті. Деякі вузли були «старими, але працювали» Pentium D коробками, які пережили кілька циклів оновлення, бо «в них все ще два ядра». Припущення команди було простим: два ядра — це два ядра, і завдання пакетне, тож кому яке діло.

Потім pipeline розширили для обробки near-real-time потоків. Той самий код, той самий планувальник кластера, просто жорсткіші дедлайни. Поза ніч, система почала пропускати вікна обробки. On-call побачив CPU, що завантажений, і припустив, що це просто питання ємності: додайте більше воркерів.

Вони додали воркерів. Стало гірше. Планувальник розміщував більше завдань на Pentium D вузлах, бо вони «доступні», і ті вузли стали пляшковим горлечком кластера. Пам’яттєві етапи нагромаджувалися на спільному Front-Side Bus. Контекстні переключення зросли. Інші вузли чекали на відстаючі. Хвостова латентність pipeline не була регресією софту; це була архітектурна перетяжка.

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

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

Сервіс, пов’язаний з трейдингом, хотів знизити латентність. Хтось помітив, що governor не встановлено в performance на наборі Core 2 серверів. Це змінили по всьому флоту і отримали приємне покращення p99 у перший день. Переможний рапорт.

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

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

Вони відкотили цю масову зміну і зробили все правильно: тримати performance governor тільки на вузлах критичних за латентністю, обмежити turbo/boost де потрібно та виправити повітряний потік/заслінки. Оптимізація була реальна, але розгортання — безвідповідальне. З точки зору SRE: ви покращили один SLI, погіршивши інший (тепловий запас), поки це не вдарило по вам.

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

Один SaaS-провайдер мав практику, що виглядала болісно не гламурно: кожне покоління апаратури отримувало невеликий canary pool з ідентичними образами ОС, і той самий production-навантаження програвався щодня. Ніякої магії, лише відтворюване вимірювання.

Коли вони оцінювали оновлення від старих NetBurst-відходів до Core 2 серверів для вторинного шару, результати канарки показали несподіване: пропускна здатність зросла помірно, але великий виграш був у стабільності хвостової латентності під змішаними навантаженнями. Графіки не були драматичними; вони були спокійні. Спокій — безцінний.

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

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

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

Симптом: «CPU лише 40%, але p99 жахливий.»
Корінна причина: Вузьке місце одного потоку, дисбаланс IRQ або масштабування частоти тримає частоти низькими.
Виправлення: Перевірте поядкове використання CPU (mpstat -P ALL), переривання (/proc/interrupts) і governor/частоту. Збалансуйте IRQ; підніміть частоти для латентних шарів; профілюйте гарячий потік.
Симптом: Два ідентичні сервери поводяться по-різному під тим самим навантаженням.
Корінна причина: Тротлінг через тепло, різні BIOS-настройки живлення або поведінка прошивки у фоні.
Виправлення: Перевірте dmesg на тротлінг, порівняйте конфіги BIOS, перевірте криві вентиляторів та температуру на вході. Ставтеся до терміки як до залежності продакшену.
Симптом: Додавання більше робочих потоків зменшує пропускну здатність.
Корінна причина: Contention і переключення контексту; Front-Side Bus і тиск кешу (особливо на старій архітектурі).
Виправлення: Зменшіть кількість потоків, використайте батчинг, вимірюйте contention замків, профілюйте. На старому обладнанні віддавайте перевагу меншій кількості активних потоків.
Симптом: Високий sys% і softirq-потоки їдять ядро.
Корінна причина: Перевантаження пакета, imbalance переривань або неефективний мережевий шлях.
Виправлення: Розподіліть IRQ, розгляньте RSS, перевірте NIC offloads і зменшіть швидкість пакета (батчинг, вибір MTU) де можливо.
Симптом: «Апгрейд CPU не допоміг затримці бази даних.»
Корінна причина: Латентність зберігання або тиск пам’яті домінують; CPU ніколи не був вузьким місцем.
Виправлення: Використайте iostat -xz, перевірте free -m і профілюйте плани запитів. Розгляньте оновлення сховища і пам’яті перед тим, як кидати ядра.
Симптом: Високий load average з низькими %usr і %sys.
Корінна причина: Завдання застрягли в незаперервному сні (часто I/O) або є проблеми в ядрі.
Виправлення: Перевірте vmstat на заблоковані завдання (b), запустіть iostat і дослідіть сховище/зовнішні сервіси.

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

Коли ви успадковуєте флот, що охоплює від NetBurst до Core 2-епохи

Перелікуйте моделі CPU (lscpu) і групуйте за поколіннями архітектури. Не розглядайте «кількість ядер» як нормалізовану одиницю.
Встановіть базову поведінку частот (governor + спостережувані MHz). Якщо частоти змінюються непередбачувано, ваші графіки вам брешуть.
Заміруйте хвостову латентність під змішаним навантаженням. Тести тільки на пропускну здатність приховують біль.
Виявляйте спільні вузькі місця: Front-Side Bus contention, пропускна здатність пам’яті, маршрутизація переривань, латентність сховища.
Встановіть політику планування: тримайте критичні за латентністю і чутливі до пам’яті робочі навантаження поза найслабшими/наймінливішими вузлами.
Вирішіть критерії виведення з експлуатації: будь-який вузол, що часто тротлить або спричиняє відстаючих, видаляється з критичних пулів.

Коли продуктивність регресує після «простої» зміни, пов’язаної з CPU

Спочатку перевірте частоти і тротлінг (governor, /proc/cpuinfo, dmesg).
Перевірте steal time, якщо віртуалізовано (mpstat).
Перевірте розподіл IRQ (/proc/interrupts).
Профілюйте гарячі точки (perf top) і вирішіть, чи це обчислення, пам’ять чи накладні витрати ядра.
Відкотіть, якщо не можете пояснити зміну. Продакшен — не виставка наукових проєктів.

Закупівлі і планування ємності (нудна частина, що запобігає інцидентам)

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

Питання та відповіді

1) Чому NetBurst мав труднощі на серверних навантаженнях порівняно з Core/Core 2?

Сервери мають багато гілок, чутливі до латентності пам’яті і запускають змішані навантаження. Глибокий конвеєр і енергоспоживання NetBurst робили ці реалії дорогими. Core/Core 2 покращили IPC і ефективність, тому те саме навантаження витрачало менше циклів і рідше досягало теплових лімітів.

2) Чи можна виміряти «IPC» у продакшені?

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

3) Чи Core 2 повністю вирішив проблему Front-Side Bus?

Ні. Core 2 все ще залежав від Front-Side Bus у тому поколінні; велика архітектурна зміна з інтегрованими контролерами пам’яті прийшла пізніше. Але Core 2 підвищив ефективність ядра і поведінку кешу, зменшивши частину болю й відклавши насичення.

4) Чому старі Pentium D коробки стають «відстаючими» у розподілених завданнях?

Бо розподілені системи часто обмежені найповільнішими виконавцями. Нижчий IPC, шина, що конкурує, і вищі коефіцієнти простоїв роблять деякі вузли систематично пізнішими. Хвіст вашої задачі стає її графіком.

5) Чи варто всюди ставити governor в performance?

Ні. Робіть це там, де латентність важлива і у вас є запас по теплу/енергії. Масові зміни можуть викликати тротлінг і знищити вигоди. Вимірюйте p99 і перевіряйте події тротлінгу.

6) Чому одне ядро завантажене на 100%, а інші простоюють?

Типові причини: вузьке місце в однопоточності, серіалізація роботи через замок або маршрутизація переривань, що скидає роботу на одне CPU. Перевірте mpstat -P ALL, ps і /proc/interrupts.

7) Яка практична різниця між «високим CPU» і «високим load average»?

Високий CPU означає, що ви витрачаєте цикли. Високий load average означає, що завдання чекають запуститися або застрягли незаперервно (часто I/O). Ви можете мати високий load при помірному CPU, коли система блокується на зберіганні або через contention.

8) Як уроки Core/Core 2 застосовуються до сучасних CPU?

Тема повторюється: ефективність і передбачуваність перемагають. Глибокі конвеєри, ліміти енергії і затримки пам’яті все ще мають значення, лише під іншими назвами (поведінка turbo, power caps, ієрархії кешу, NUMA). Діагностуйте систему, а не маркетингову етикетку.

9) Який найшвидший знак, що ви обмежені пам’яттю, а не CPU?

Гарячі точки у memcopy/GC, продуктивність, що не покращується з додатковими потоками, і симптоми на кшталт сильного тиску кешу. На практиці: perf top, що показує рух пам’яті і kernel copy-рутину, — сильна підказка.

10) Чи завжди треба виводити з експлуатації обладнання епохи NetBurst?

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

Короткий жарт №2: Якщо ви досі сперечаєтесь про GHz у 2026 році, у мене є стопка AOL-CD, що теж «шли з безкоштовним інтернетом».

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

Рух Intel від NetBurst до Core/Core 2 був не м’якою еволюцією — це була корекція. Для операторів висновок не в ностальгії за Conroe. Він у дисципліні ставитися до продуктивності CPU як до поведінки всієї системи: частоти, терміка, кеші, шляхи пам’яті, переривання і contention.

Практичні кроки, що швидко окупаються:

Сегментуйте флот за поколінням CPU і припиніть вважати ядра еквівалентними.
Прийміть швидкий порядок діагностики: частоти/тротлінг → steal/черга запуску → корисна робота vs очікування → профілювання гарячих точок.
Виправте дисбаланс переривань і неправильні налаштування частоти перед тим, як чіпати прикладний код.
Будуйте базові метрики і канарки, щоб апаратні й ядрові зміни перестали бути «загадковими».
Виводьте відстаюче апаратне забезпечення з критичних пулів. Вам не потрібна ностальгія; вам потрібна передбачувана латентність.

Схожі статті

Теплова стіна: як фізика поклала край улюбленій маркетинговій історії Пояснення процесних вузлів: що насправді означає «7nm / 5nm / 3nm»