Pentium 4 / NetBurst: найгучніша помилка ери ГГц

Теза: ГГц були проксі, а не продуктом

NetBurst створювали під частоту. Не під «якісну частоту», не під «ефективну частоту», а під «поставте число на коробку
і нехай світ сперечається пізніше». Intel роками привчав покупців інтерпретувати тактову частоту як продуктивність.
Ринок винагороджував таке спрощення. А потім прийшли рахунки: надто глибокі конвеєри інструкцій, через які помилки передбачення
обходилися дорого, підсистема пам’яті, що не поспішала за ядром, і щільність потужності, яка перетворила дизайн шафи в хобі для
фанатів ОВК.

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

Якщо перекласти це на SRE-мову: NetBurst оптимізували під пік у ідеальних мікробенчмарках і карали хвостову латентність
під реальним сумішевим навантаженням. Так ви можете доставити багато розчарування.

Один раз я бачив, як слайд закупівель виставляв «3.0 GHz» ніби це SLA пропускної здатності.
Це як оцінювати мережу, рахуючи літери в «Ethernet».

Внутрішня будова NetBurst: конвеєр, який з’їв ваш IPC

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

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

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

Trace cache: хитро, складно і чутливо до навантаження

Trace cache у NetBurst зберігав декодовані мікрооперації (uops), а не сирі x86-інструкції. Це було розумно: декодування x86 —
нетривіальна справа, і кеш uop може зменшити навантаження на фронт-енд. Але це також зробило продуктивність залежною від потоку коду
і вирівнювання. Якщо ваш стрім інструкцій не «грає ввічливо» — багато гілок, дивне вирівнювання, погана локальність — trace cache
переставав бути благом і ставав ще одним місцем для промаху.

Ідея не була хибною; вона була ранньою й крихкою. Сьогодні uop-кеші успішні тому, що решта системи стала краще їх підгодовувати,
а компроміси потужність/продуктивність менеджаться з більшим тактом.

FSB і спільний northbridge: пункт пропуску пропускної здатності

Системи Pentium 4 залежали від front-side bus (FSB) до окремого контролера пам’яті (northbridge). Це означає, що ваше CPU-ядро швидке,
а пам’ять — «деінде», і кожен запит — подорож через спільну шину. Під навантаженням ця шина перетворюється на задачу планування.
Додайте кілька CPU — і це стає груповим проєктом.

Порівняйте це з пізнішими дизайнами з інтегрованими контролерами пам’яті (AMD зробив це раніше на x86; Intel пізніше).
Коли пам’ять ближче й має більше виділених шляхів, ви зменшуєте конкуренцію й знижуєте латентність. В продакшні латентність — валюта.
NetBurst витрачав її як турист.

SSE2/SSE3 ера: сильний у потоковій математиці, нерівний в інших задачах

NetBurst непогано справлявся з деякими векторизованими, потоковими навантаженнями — кодом, що міг передбачувано обробляти масиви
і уникати розгалуженої логіки. Ось чому бенчмарки могли виглядати нормально, якщо їх будували під тип навантаження, який машина любила.
Але реальні сервіси не ввічливі. Вони парсять, розгалужуються, виділяють пам’ять, блокуються й чекають на I/O.

NetBurst був еквівалентом двигуна, налаштованого під певний трек. Посадіть його в міський рух — і ви дізнаєтеся, що таке «крива крутного моменту».

Чому реальні навантаження болять: кеші, гілки, пам’ять і очікування

IPC — те, що ви відчуваєте; ГГц — те, чим хвалитеся

Інструкцій за такт (IPC) — грубий, але корисний проксі для «скільки роботи виконується за тик». NetBurst часто мав нижчий IPC,
ніж contemporaries у багатьох загальноцільових навантаженнях. Тому чіп працював на вищій частоті, щоб компенсувати.
Це може працювати — поки не перестає, тому що:

• Розгалужений код викликає помилки передбачення, які дорожчі в глибоких конвеєрах.
• Промахи кешу зупиняють виконання, а швидке ядро просто раніше доходить до паузи.
• FSB/латентність пам’яті стає жорсткою стіною, яку частотою не переломиш.
• Енергетика/терміки примушують троттлити, тож обіцяні ГГц — скоріше бажання.

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

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

Стіна пам’яті: коли ядро випереджає систему

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

З точки зору оператора це проявляється так: високе завантаження CPU, посередня пропускна здатність і система, яка здається «застряглою»
без очевидної насиченості I/O. Вона не застрягла. Вона чекає на пам’ять і б’ється сама з собою.

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

Спекуляція — це спосіб, яким сучасні CPU отримують продуктивність: вгадати шлях, виконати його, викинути якщо помилилися.
У глибокому конвеєрі неправильний шлях дорогий. Ставка NetBurst була в тому, що кращі такти компенсують це. Іноді так і було.
Часто — ні.

Одна з найпростіших операційних інструкцій із епохи NetBurst: не приймайте «CPU завантажено на 95%» за «CPU виконує 95% корисної роботи».
Потрібні лічильники, а не відчуття.

Терміки та енергоспоживання: коли процесор торгується з фізикою

Щільність потужності стала функцією продукту (випадково)

NetBurst грівся. Особливо пізні моделі на базі Prescott, які стали легендарними через споживання і нагрівання. Тепло — це не лише рахунок за електрику;
це ризик надійності, шум вентиляторів і змінність продуктивності.

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

Троттлінг за температурою: невидимий гальмо

Коли CPU тротлиться, частота змінюється, виконання змінюється, і хвостова латентність вашого сервісу змінюється так, як ваші тести ніколи не моделювали.
У системах епохи NetBurst не рідкість було бачити «бенчмарк каже X», але «прод каже Y», бо умови у навколишньому середовищі не лабораторні.

Жарт №1: Prescott не був обігрівачем, але сидіти поруч зі стійкою в холодну пору стало трохи приємніше.

Надійність і експлуатація: гарячі системи старіють швидше

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

Парафраз відомої ідеї, часто приписуваної В. Едвардсу Демінгу, чітко підходить для опсів: «Ви не можете керувати тим, чого не вимірюєте».
З NetBurst вам доводилося вимірювати терміки, бо CPU це робив точно.

Hyper-Threading: хороший трюк, що виявив погані припущення

Hyper-Threading (SMT) з’явився на деяких моделях Pentium 4 і був реально корисний за відповідних умов:
він міг заповнювати «прогалини» в конвеєрі, запускаючи інший потік, коли один застряг. Це звучить як безкоштовна продуктивність,
і іноді так воно й було.

Коли допомагало

• Змішані навантаження, де один потік чекає на промахи кешу, а інший може використати виконавчі блоки.
• Сервіси з інтенсивним I/O, де потік часто блокується, і накладні витрати планувальника керовані.
• Деякі ролі серверів, орієнтовані на пропускну здатність, з незалежними запитами і обмеженою конкуренцією за блокування.

Коли шкодило

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

Hyper-Threading на NetBurst — це мікрокосм правила: SMT робить добрі дизайни кращими, а крихкі — дивнішими.
Воно може підвищити пропускну здатність і водночас зробити латентність потворною. Якщо ваше SLO — p99, не «увімкніть і моліться».
Тестуйте з production-подібною конкуренцією і контролюйте хвіст.

Історичні факти, які мають значення (і кілька, що ще болять)

1. NetBurst дебютував з Willamette (Pentium 4, 2000), віддаючи пріоритет частоті над IPC.
2. Northwood покращив ефективність і такти, і став «менш болючим» Pentium 4 для багатьох покупців.
3. Prescott (2004) перейшов на тонший техпроцес, додав функції й став відомим через нагрів і енергоспоживання.
4. «Гонка ГГц» настільки вплинула на рішення про покупку, що «вища частота» часто перемагає кращу архітектуру в комерційних бесідах.
5. Доступ до пам’яті через FSB означав, що CPU конкурував за пропускну здатність по спільній шині до northbridge.
6. Trace cache зберігав декодовані мікрооперації, намагаючись зменшити накладні витрати декоду і постачати довгий конвеєр ефективно.
7. Hyper-Threading з’явився на вибраних моделях і міг підвищити пропускну здатність, використовуючи проста клітинка виконання.
8. Pentium M (з родоводу P6) часто перевершував Pentium 4 при значно нижчих тактах, особливо в реальних задачах.
9. Intel зрештою змінив курс від NetBurst; лінійка Core (на іншому фундаменті) замінила стратегію замість нескінченного її розвитку.

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

Міні-історія 1: інцидент через хибне припущення («ГГц = ємність»)

Середня компанія успадкувала парк застарілих веб-серверів і планувала швидке оновлення. Критерії вибору були надто прості: беріть
найбільш високочастотні Pentium 4 в межах бюджету. Нотатка закупівель буквально прирівнювала «+20% частоти» до «+20% запитів в секунду».
Ніхто не був злий умисно; вони були зайняті.

Розгортання пройшло гладко, поки трафік не досяг звичного піка. Завантаження CPU виглядало нормально — високо, але стабільно.
Мережа була під контролем. Диски не кричали. Але p95 латентність піднялася, потім p99 пішов вертикально. Команда on-call зробила те, що й роблять команди:
перезапустили сервіси, переклали трафік, звинуватили балансувальник і дивилися на графіки, поки графіки не стали дивитися назад.

Справжня проблема була в поведінці пам’яті. Навантаження змінилося з роками: більше персоналізації, більше логіки шаблонів, більше динамічної маршрутизації.
Це означало більше «pointer-chasing» і розгалужень. Нові сервери мали вищі частоти, але схожу латентність пам’яті і спільну топологію FSB, що ставала гіршою під конкуренцією.
Вони швидше доходили до тих самих пам’яттєвих пауз, а Hyper-Threading додав конкуренцію в найгірший момент.

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

Міні-історія 2: оптимізація, що відкотилася («увімкнемо HT і отримаємо безкоштовну продуктивність»)

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

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

Вони намагалися виправити це, збільшуючи heap, потім прив’язуючи потоки, потім крутячи різні системні ручки. Деякі речі допомогли, більшість — ні.
Справжній виграш прийшов від кроку назад: ставитися до Hyper-Threading як до інструмента пропускної здатності з витратами на латентність.
Виміряйте витрати.

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

Міні-історія 3: нудна, але правильна практика, що врятувала день («термальний запас — це ємність»)

Команда фінансових сервісів запускала обчислювально-важкі нічні завдання на кластері, який включав вузли епохи Prescott Pentium 4.
Ніхто не любив ті коробки, але завдання були стабільні, і кластер «був достатнім». Тиха суперсила команди — вони розглядали середовище як частину ємності:
моніторинг температури впускного повітря, перевірки стану вентиляторів і оповіщення про індикатори троттлінгу.

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

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

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

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

Це виконувано на типовому сервері Linux. Мета не «довести, що NetBurst поганий» у 2026 році.
Ви вчитеся розпізнавати ті самі режими відмов: зупинки в конвеєрі, стіна пам’яті, артефакти планування, термальне троттлінг
і оманлива завантаженість.

Завдання 1: Визначте CPU і чи є HT

cr0x@server:~$ lscpu
Architecture:            x86_64
CPU op-mode(s):          32-bit, 64-bit
CPU(s):                  2
Thread(s) per core:      2
Core(s) per socket:      1
Socket(s):               1
Model name:              Intel(R) Pentium(R) 4 CPU 3.00GHz
Flags:                   fpu vme de pse tsc ... ht ... sse2

Що це значить: «Thread(s) per core: 2» вказує на Hyper-Threading. Model name дає родину CPU.

Рішення: Якщо HT є, тестуйте з HT увімкненим/вимкненим для latency-чутливих сервісів; не вважайте, що це виграш.

Завдання 2: Перевірте поточну частоту і драйвер масштабування

cr0x@server:~$ grep -E 'model name|cpu MHz' /proc/cpuinfo | head
model name	: Intel(R) Pentium(R) 4 CPU 3.00GHz
cpu MHz		: 2793.000

Що це значить: CPU не на номінальній частоті. Може бути енергозбереження або троттлінг.

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

Завдання 3: Підтвердіть governor частоти CPU

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

Що це значить: «ondemand» може знижувати частоту до росту навантаження; на старіших платформах він може повільно реагувати.

Рішення: Для вузлів з низькою латентністю розгляньте «performance» і повторіть тест; для батчів «ondemand» може бути прийнятним.

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

cr0x@server:~$ for z in /sys/class/thermal/thermal_zone*/temp; do echo "$z: $(cat $z)"; done
/sys/class/thermal/thermal_zone0/temp: 78000
/sys/class/thermal/thermal_zone1/temp: 65000

Що це значить: Температури в міліградусах Цельсія. 78000 = 78°C.

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

Завдання 5: Виявлення індикаторів троттлінгу в kernel логах

cr0x@server:~$ dmesg | grep -i -E 'throttl|thermal|critical|overheat' | tail
CPU0: Thermal monitoring enabled (TM1)
CPU0: Temperature above threshold, cpu clock throttled
CPU0: Temperature/speed normal

Що це значить: CPU знизив швидкість через нагрів. Ваша «загадкова» пропускна здатність може бути простою фізикою.

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

Завдання 6: Швидко перевірте чергу запуску і насиченість 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
 2  0      0 120000  15000 210000    0    0     2     5  900 1400 85 10  5  0  0
 4  0      0 118000  15000 209000    0    0     0     8 1100 1800 92  7  1  0  0

Що це значить: «r» (черга запуску) постійно вище за кількість CPU вказує на конкуренцію за CPU. Низький «id» означає зайнятість.

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

Завдання 7: Знайдіть головних споживачів CPU і чи вони «крутяться» в циклі

cr0x@server:~$ top -b -n 1 | head -n 15
top - 12:14:01 up 21 days,  3:11,  1 user,  load average: 3.90, 3.60, 3.20
Tasks: 184 total,   2 running, 182 sleeping,   0 stopped,   0 zombie
%Cpu(s): 92.0 us,  7.0 sy,  0.0 ni,  1.0 id,  0.0 wa,  0.0 hi,  0.0 si,  0.0 st
PID USER      PR  NI    VIRT    RES    SHR S  %CPU %MEM     TIME+ COMMAND
2174 app      20   0  1856m  612m  122m R  98.7  7.6  12:11.02 java

Що це значить: Високий user CPU все ще може бути «в очікуванні» (промахи пам’яті, промахи прогнозів гілок).
Низький «wa» не означає, що CPU не стоїть.

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

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

cr0x@server:~$ pidstat -w 1 5
Linux 6.1.0 (server) 	01/09/2026 	_x86_64_	(2 CPU)

12:14:20      UID       PID   cswch/s nvcswch/s  Command
12:14:21     1001      2174   1200.00    350.00  java

Що це значить: Дуже високі контекстні переключення можуть означати забагато потоків, контенцію за блокування або інтенсивний таймер/IO churn.

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

Завдання 9: Сигнали перевантаження пропускної здатності пам’яті через perf (cycles vs stalled frontend/backend)

cr0x@server:~$ sudo perf stat -p 2174 -e cycles,instructions,branches,branch-misses,cache-misses -a -- sleep 10
 Performance counter stats for 'system wide':

     32,100,000,000      cycles
     12,400,000,000      instructions              #    0.39  insn per cycle
      2,900,000,000      branches
        145,000,000      branch-misses             #    5.00% of all branches
        610,000,000      cache-misses

Що це значить: Низький IPC (0.39) плюс багато кеш/гілкових промахів вказують, що CPU зайнятий, але непродуктивний.

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

Завдання 10: Підтвердіть, чи ви дійсно обмежені I/O

cr0x@server:~$ iostat -xz 1 3
avg-cpu:  %user   %nice %system %iowait  %steal   %idle
          90.50    0.00    7.20    0.10    0.00    2.20

Device            r/s     w/s   rkB/s   wkB/s  rrqm/s  wrqm/s  %util  await
sda              2.10    1.00   45.0    28.0     0.0     0.2    3.0    1.2

Що це значить: Диск ледь завантажений; await низький. Це не вузьке місце зберігання.

Рішення: Перестаньте звинувачувати диски. Зосередьтесь на CPU/пам’яті/блокуваннях і профілюванні на рівні запиту.

Завдання 11: Перевірте тиск пам’яті і сторінкування (тихий вбивця продуктивності)

cr0x@server:~$ free -m
               total        used        free      shared  buff/cache   available
Mem:            2048        1720         120          12         207         210
Swap:           2048         900        1148

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

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

Завдання 12: Підтвердьте активне сторінкування, а не просто використання swap

cr0x@server:~$ sar -B 1 5
Linux 6.1.0 (server) 	01/09/2026 	_x86_64_	(2 CPU)

12:15:10  pgpgin/s pgpgout/s   fault/s  majflt/s  pgfree/s pgscank/s pgsteal/s
12:15:11      0.00      0.00    820.00      0.00   1200.00      0.00      0.00
12:15:12     10.00     45.00   2100.00     15.00    400.00    800.00    300.00

Що це значить: Major faults (majflt/s) і сканування вказують на реальний тиск пам’яті.

Рішення: Сторінкування під навантаженням — це проблема ємності. Усуньте проблему з пам’яттю, а не з налаштуваннями CPU.

Завдання 13: Огляньте тиск планувальника одним поглядом

cr0x@server:~$ cat /proc/pressure/cpu
some avg10=12.34 avg60=10.01 avg300=8.55 total=987654321

Що це значить: CPU PSI «some» вказує час, який задачі проводять в очікуванні CPU-ресурсів.

Рішення: Якщо PSI росте разом з латентністю, вам потрібен більш ефективний CPU (IPC), менше runnable-потоків або політика зниження навантаження.

Завдання 14: Виявлення контенції за блокуваннями (часто діагностують як «повільний CPU»)

cr0x@server:~$ sudo perf top -p 2174
Samples: 31K of event 'cpu-clock', 4000 Hz, Event count (approx.): 7750000000
Overhead  Shared Object        Symbol
  12.40%  libc.so.6            [.] pthread_mutex_lock
   9.10%  libjvm.so            [.] SpinPause

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

Рішення: Зменшіть контенцію (шардінг локів, зменшення потоків, виправлення гарячих критичних секцій). Більше ГГц вас не врятують.

Завдання 15: Перевірте дружність до кешу через швидкий мікробенч (не заміна реальних тестів)

cr0x@server:~$ taskset -c 0 sysbench cpu --cpu-max-prime=20000 run
CPU speed:
    events per second:  580.21

General statistics:
    total time:                          10.0004s
    total number of events:              5804

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

Рішення: Використовуйте мікробенчмарки тільки для базової перевірки; рішення приймайте на основі реалістичних тестів навантаження й латентності.

Жарт №2: Якщо ваш план — «додайте потоків, поки не стане швидше», ви не оптимізуєте — ви закликаєте демони контенції.

Швидка діагностика: що перевірити першим/другим/третім

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

Перше: переконайтеся, що CPU, який ви думаєте, — це той, що у вас є

1. Частота під навантаженням: перевірте /proc/cpuinfo MHz, governor та dmesg на предмет троттлінгу.
2. Терміки: перегляньте термальні зони та стан вентиляторів/повітряного потоку через наявну телеметрію.
3. Віртуалізація: підтвердіть, що вас не обмежують квоти CPU або «шумні сусіди» (PSI, cgroups).

Мета: виключити «CPU буквально не працює на очікуваній швидкості» за 5 хвилин.

Друге: визначте, чи ви обчислювально-зв’язні, пам’яттєво-зв’язні чи контенційно-зв’язані

1. Черга запуску і PSI: vmstat та /proc/pressure/cpu для очікування CPU.
2. perf IPC: cycles vs instructions; низький IPC вказує на зупинки/промахи.
3. Сигнали контенції за локами: perf top, pidstat контекстні переключення, дампи потоків додатка.

Мета: класифікувати проблему. Ви не зможете виправити те, що не назвали.

Третє: підтвердіть, що це не I/O і не сторінкування

1. Диск: iostat -xz для завантаження і await.
2. Сторінкування: sar -B для major faults і сканування.
3. Мережа: перевірте втрати/помилки і черги (не показано вище, але обов’язково).

Мета: припинити марнувати час на невірну підсистему.

Четверте: вирішіть, чи це проблема підходу апаратного забезпечення або ПО

• Якщо IPC низький через промахи кешу і помилки гілок — потрібна краща локальність або CPU з вищим IPC, а не більше ГГц.
• Якщо домінує контенція, зменшіть конкурентність або переробіть гарячі шляхи — апаратне оновлення не вирішить серіалізований код.
• Якщо є троттлінг, спочатку ліквідуйте проблеми охолодження і подачі живлення; інакше всі інші зміни стануть шумом.

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

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

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

Виправлення: Використайте perf stat, щоб підтвердити низький IPC і високі промахи; оптимізуйте локальність, зменшіть pointer-chasing і профілюйте гарячі шляхи коду. Якщо купуєте залізо, віддавайте пріоритет IPC і підсистемі пам’яті, а не тактовій частоті.

2) Симптом: «Сплески латентності з’являються лише в теплі після обіду / після заміни вентилятора»

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

Виправлення: Підтвердіть через dmesg і показники термальних зон; усуньте охолодження, почистіть фільтри, перевірте криві вентиляторів і зберігайте запас по вхідній температурі. Розглядайте терміки як критичний SLO-залежник.

3) Симптом: «Ми увімкнули Hyper-Threading і p99 стало гірше»

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

Виправлення: A/B тест HT увімкн./вимкн. з production-подібною конкуренцією; зменшіть кількість потоків; виправте гарячі блокування; розглядайте HT лише для задач орієнтованих на пропускну здатність або I/O-стримируваних навантажень.

4) Симптом: «Мікробенчмарки покращилися, але продакшн став повільнішим»

Корінна причина: Мікробенчмарки — обчислювальні і передбачувані; продакшн — розгалужений і пам’яттєво важкий. Дизайн NetBurst винагороджує перше і карає друге.

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

5) Симптом: «Load average зріс після того, як ми «оптимізували», додавши потоки»

Корінна причина: Перепідписка і контенція; більше runnable-потоків збільшує накладні витрати планування і блокувань.

Виправлення: Використайте pidstat для вимірювання контекстних переключень, perf top для символів, пов’язаних з блокуваннями, і зменшіть конкуренцію. Додавайте паралелізм тільки там, де робота є паралельною і вузьке місце зміщується.

6) Симптом: «Оновлення CPU не допомогло базі даних»

Корінна причина: Навантаження обмежене латентністю пам’яті або пропускною здатністю пам’яті (промахи буферного пулу, pointer-chasing у B-деревах, кеш-промахи).

Виправлення: Збільшіть ефективний показник попадань в кеш (індекси, форма запитів), додайте RAM, зменшіть робочий набір і виміряйте кеш-промахи/IPC. Не кидайте ГГц на стіну пам’яті.

7) Симптом: «Все виглядає нормально, окрім випадкових пауз і таймаутів»

Корінна причина: Сторінкування, паузи GC або сплески контенції, які не показуються як сталий рівень завантаження.

Виправлення: Перевірте major faults, PSI і метрики пауз додатка. Усуньте тиск пам’яті і зменшіть підсилення хвоста (таймаути, повторні спроби, «thundering herd»).

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

Чеклист A: Купівля обладнання без повторення помилки NetBurst

1. Визначайте успіх за латентністю і пропускною здатністю (p50/p95/p99 + стабільні RPS), а не за тактовою частотою.
2. Вимірюйте IPC-проксі: використовуйте perf на репрезентативних навантаженнях; порівнюйте cycles/instructions і рівні промахів.
3. Моделюйте поведінку пам’яті: розмір робочого набору, показник попадань у кеш, очікувана конкуренція і потреби в пропускній здатності.
4. Перевіряйте терміки: тестуйте в стійці, з реалістичною температурою навколишнього середовища і профілем вентиляторів.
5. Тестуйте вплив SMT/HT: увімкн./вимкн. з реальними кількостями потоків і відстеженням хвостової латентності.
6. Віддавайте перевагу збалансованим системам: кількість каналів пам’яті, розміри кешу і міжз’єднання важливі так само, як і частоти ядер.

Чеклист B: Коли розгортання «швидшого CPU» робить продакшн повільнішим

1. Підтвердіть частоту і троттлінг (governor, температури, dmesg).
2. Порівняйте perf IPC і рівні промахів до/після.
3. Перевірте кількість потоків і контекстні переключення; першим відкотіть зміни з «подвійними потоками».
4. Перевірте тиск пам’яті і сторінкування; негайно виправте major faults.
5. Шукайте регресії контенції за локами, введені новою конкуренцією.
6. Якщо неясно, захопіть flame graph або профіль і розгляньте його як хроніку інциденту.

Чеклист C: Стабілізувати хвостову латентність на старих, гарячих, частотозалежних системах

1. Зменшіть конкуренцію так, щоб відповідала кількості ядер (особливо з HT) і спостерігайте вплив на p99.
2. Прив’язуйте критичні потоки тільки якщо ви розумієте топологію; інакше прив’язка може закутати вас у кут.
3. Тримайте governor CPU послідовним (часто «performance» для вузлів з критичною латентністю).
4. Забезпечте термальний запас: надсилайте оповіщення про температуру і події троттлінгу, а не лише про завантаження CPU.
5. Оптимізуйте гарячі шляхи для локальності; по можливості усуньте непередбачувані гілки.
6. Введіть зворотний тиск і розумні таймаути, щоб уникнути лавини повторних спроб.

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

1) Чи був Pentium 4 справді «поганим», чи просто його неправильно розуміли?

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

2) Чому вищі ГГц не перетворювалися на вищу продуктивність?

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

3) Який операційний урок для сучасних систем?

Не приймайте заголовкову метрику як істину. Для CPU це ГГц; для зберігання — «IOPS»; для мережі — «Gbps».
Завжди запитуйте: при якій латентності, з якою конкуренцією і як поводиться хвіст?

4) Чи «виправив» Hyper-Threading NetBurst?

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

5) Чому Pentium M іноді обганяв Pentium 4 при значно нижчих частотах?

Pentium M (з роду P6) наголошував на IPC і ефективності. У розгалужених, чутливих до кешу навантаженнях вищий IPC і краща ефективність
часто перемагають сирі такти, особливо коли висока частота спричиняє енергетичні і термічні троттлінги.

6) Як визначити, чи моє навантаження обмежене пам’яттю, а не CPU?

Шукайте низький IPC з високими промахами кешу в perf, а також обмежений ефект від додавання ядер або підвищення частоти.
Ви також побачите плато пропускної здатності при «завантаженому» CPU. Це зазвичай стіна пам’яті або стіна контенції.

7) Чи реально важливий троттлінг за температурою?

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

8) Що потрібно бенчмаркувати, щоб уникнути помилок ери ГГц?

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

9) Чи є сучасні аналоги пастки NetBurst?

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

Висновок: що робити, коли вам знову продають ГГц

NetBurst — це не лише ретро-трівіал про CPU. Це чітка історія про інцентиви, вимірювання і ціну ставки на одне число.
Intel оптимізував під частоту, бо ринок платив за частоту. Навантаження, що мали значення —
розгалужений серверний код, пам’яттєво важкі системи, стійки з термічними обмеженнями — виставили рахунок.

Практичні кроки далі — нудні, і саме тому вони працюють:

1. Визначайте продуктивність через хвостову латентність, а не пікову пропускну здатність і тим паче не через частоту.
2. Інструментуйте вузькі місця: perf-лічильники, PSI, метрики сторінкування і термічні/троттлінгові сигнали.
3. Бенчмаркуйте як продакшн: конкуренція, розмір даних, поведінка кешу, прогон з нагрівом і реалістичні суміші запитів.
4. Розглядайте терміки як ємність: якщо CPU тротлиться, ваша архітектура «обмежена охолодженням». Визнайте це.
5. Сумнівайтеся в «безкоштовній продуктивності»: HT/SMT, агресивна конкуренція і мікро-оптимізації, що ігнорують контенцію.

Якщо запам’ятати лише одне: такти — це компонент, а не гарантія. Система — це продукт. Експлуатуйте її відповідно.