Pentium II / III: золота епоха, коли такти ще мали значення

December 28, 2025 • February 3, 2026 • Читання: 5 хв • Views: 0

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

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

Але в епоху Pentium II / Pentium III ви часто могли вказати на число MHz і — з певними застереженнями — передбачити результат.
Не тому, що Intel був магічним, а тому, що обмеження машини були читабельні. Вузькі місця були голосні, лінійні й часто поправні викруткою, налаштуванням BIOS
або просто купівлею правильної оперативної пам’яті.

Чому такти «мали значення» на Pentium II/III

Казати «MHz мали значення» не означає «MHz були істина». Це означає, що модель продуктивності системи мала менше ступенів свободи.
У вас був одноядерний CPU з відносно прямим зв’язком між частотою і пропускною здатністю, фронтальна шина (FSB), яку було легко
наситити й тому легко побачити, і сховище, яке було настільки повільним, що всі знали — воно повільне.

Pentium II і Pentium III жили у світі, де:

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

Ця простота — не ностальгія. Це діагностична перевага. Якщо ви навчитеся мислити про вузькі місця Pentium II/III,
ви станете кращими в діагностиці сучасних більш заплутаних: тому що перестанете гадати й почнете вимірювати шлях: CPU → кеш → пам’ять → шина → диск → мережа.

Одна цитата, бо вона й досі боляче потрапляє в ціль. Відомий маніфест надійності Гіна Кіма часто цитують; ось парафразована ідея:
Ліквідуйте toil, зробивши роботу видимою, повторюваною й виміряною; героїзм — це режим відмови, а не стратегія. — Gene Kim (парафраз)

9 фактів, що пояснюють ту епоху

Slot 1 — це була не мода, а логістика: Pentium II постачався в картриджі (SECC) з кеш-чіпами на модулі, а не на материнській платі.
Зовнішній L2 часто працював на половині швидкості ядра: Багато Pentium II мали зовнішній L2 на 1/2 частоти CPU, що робило поведінку кешу помітною людині.
Pentium III «Coppermine» приніс L2 на кристалі: Інтегрований L2 на повній швидкості був великою причиною, чому «такий самий MHz» все ще міг означати «швидший CPU».
FSB був публічним числом, яке можна було наситити: Рішення 66/100/133 MHz FSB були реальними архітектурними рішеннями, а не маркетинговим дрібним шрифтом.
AGP змінив відчуття робочої станції: Переміщення графіки з PCI на AGP зменшило конкуренцію за шину і зробило «відгук десктопа» вимірюваним по-новому.
SSE з’явився й мав значення для певного коду: SSE у Pentium III справді міг прискорювати мультимедіа та деякі наукові навантаження — якщо програмне забезпечення його використовувало.
PC100/PC133 SDRAM були вибором SKU: Ви могли купити не ту оперативну пам’ять і провести наступний рік, вдаючи, що ОС «роздута».
Режими IDE DMA — це були обриви продуктивності: Один неправильно налаштований диск, що повертався до PIO, міг перетворити апгрейд CPU на генератор скарг.
Терміни керування теплом були простішими, але не відсутні: Вентилятори ламалися, радіатори розхитувалися, і «випадкові зависання» часто означали «він перегрівається».

Практичний огляд архітектури: що фактично обмежувало вас

1) Ядро CPU: IPC до того, як це стало модним словом

Pentium II і III були ядрами з виконанням поза порядком і пристойним передбаченням переходів того часу, але їх все ще можна було розуміти як:
«Скільки корисних інструкцій на цикл моє навантаження завершує і що його зупиняє?»
Частина «завершує» — це ключ. Ви можете працювати на 1 GHz і нічого корисного не робити, якщо весь час чекаєте пам’ять.

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

2) Кеш: найголосніший учитель у будівлі

У ту епоху кеш був сюжетним поворотом, який ви могли відчути. Великий робочий набір? Продуктивність падала з обривом.
Малий робочий набір? CPU виглядав як супергерой.

Дизайн Pentium II з зовнішнім L2 часто на половині швидкості робив це жорстоко очевидним:
кеш не був магічною бічною опцією. Це був компонент продуктивності першого класу.
Коли Pentium III Coppermine переніс L2 на кристал і на повну швидкість, це не просто «покращило продуктивність».
Це змінило форму продуктивності. Латентність зменшилась, пропускна здатність покращилася, і навантаження з повторюваними шаблонами доступу до пам’яті отримали реальний приріст.

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

3) Front-side bus: спільний коридор, за який усі борються

FSB був спільним коридором між CPU і northbridge (контролер пам’яті й супутні компоненти). CPU міг бути швидким;
коридор усе одно міг бути вузьким. Саме тому 100→133 MHz FSB не було дрібницею — це була структурна зміна в тому, наскільки швидко CPU могли отримувати дані.

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

4) Сховище та I/O: коли диск чесно визнавав свою повільність

Диски кінця 90-х не були тонкими. Якщо ваше навантаження зверталося до диска, ви це знали. Ядро це знало. Користувачі це знали.
Така чесність була навчальною: вона змушувала визнати I/O як ресурс першого класу, а не як післядумку.

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

Жарт №1: У дні Pentium II «міграція в хмару» означала переставити бежеву вежу подалі від вікна, щоб до модему не потрапив дощ.

Навантаження, що масштабувалися з MHz — і ті, що ні

Добре масштабувалися: щільні цикли, малі робочі набори, передбачувані переходи

Якщо у вас було навантаження, зв’язане з CPU, і дані лишалися «гарячими» в кеші, підвищення MHz виглядало як реальне прискорення.
Думайте про: класичні збірки, малі веб-навантаження та певні чисельні ядра.
SSE у Pentium III також давала вам осьову перевагу: частина коду ставала швидшою без підвищення MHz,
але тільки якщо вона була написана або скомпільована з використанням SSE.

Не масштабувалися: обмежені пам’яттю, шиною або I/O навантаження

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

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

Правило великої пальця «такт мав значення» (з попередженням)

Ось практично корисна версія:

Якщо CPU майже насичений, і навантаження не блокується на I/O або пам’яті, швидші такти допоможуть.
Якщо CPU мало завантажений, але латентність висока, такти — відволікання: вимірюйте черги й затримки.
Якщо CPU високо завантажений, але iowait теж високий, ймовірно ви просто витрачаєте цикли, чекаючи.

Попередження: навіть у ту епоху кеш і FSB могли анулювати наївну порівняння MHz.
Це не суперечність. Це сенс: продуктивність — це конвеєр, і MHz описує лише один його етап.

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

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

Середня компанія працювала з власною системою введення замовлень на двох старих x86 серверах. Сервіс був «нормальний» до кінця місяця, коли
користувачі скаржилися, що збереження замовлення займало 20–40 секунд. Команда опсів зробила звичну річ: подивилась CPU і бачила, що він лише на 30–40%.
Вони припустили, що база даних «недозавантажена», і вирішили, що апгрейд CPU буде дешевим і безпечним.

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

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

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

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

Міні-історія 2: Оптимізація, що обернулась проти

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

Продакшн не переймався їхніми синтетичними бенчмарками. Під реальним трафіком аплікація писала логи сплесками.
Система почала накопичувати dirty-сторінки швидше, ніж могла їх скидати, а потім настав writeback-шторм.
Латентності зросли. Користувачі отримали таймаути. CPU виглядав завантаженим під час шторму, але він виконував роботу ядра — flush-треди, reclaim та планування I/O.

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

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

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

Інша компанія керувала внутрішнім буд-фармом, що компілював великі C/C++ проєкти за ніч. Нічого гламурного. Одного вечора час збірки подвоївся,
і on-call отримав пейдж, бо downstream-джоби пропускали свої вікна.

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

Через те, що у них був базовий рівень (попередні тривалості збірок, попередня поведінка частоти CPU та збережена копія очікуваних налаштувань BIOS),
вони повернули профіль BIOS і відновили продуктивність за годину. Без заміни заліза. Без «переробки пайплайна».

Урок: нудні базові показники кращі за захопливі припущення. Найбільш надійний інструмент продуктивності — вчорашні відомі добрі числа.

Жарт №2: Бенчмаркування без контексту продакшну — це як хронометрувати евакуаційну тривогу, щоб довести, що ваша будівля не горить.

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

Ці завдання написані для Linux, бо саме там живе більшість SRE-м’язової пам’яті, але ментальна модель легко мапується на будь-яку ОС:
ідентифікуйте насичення, черги та затримки. Кожне завдання містить реалістичну команду, приклад виводу, що це означає, і яке рішення прийняти.

Завдання 1: Підтвердіть модель CPU, MHz і флаги (історично важливе SSE)

cr0x@server:~$ lscpu | egrep 'Model name|CPU MHz|Flags|L1d|L2|L3|Socket|Core'
Model name:                           Intel(R) Xeon(R) CPU E5-2680 v4 @ 2.40GHz
CPU MHz:                              2394.454
Flags:                                fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp lm constant_tsc
L1d cache:                            32K
L2 cache:                             256K
L3 cache:                             35M
Socket(s):                            2
Core(s) per socket:                   14

Що це означає: Ви отримали ідентифікацію CPU і топологію кешів. Історично наявність/відсутність SSE змінювала продуктивність для конкретних навантажень.

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

Завдання 2: Перевірте, чи CPU дроселюється або зафіксований на низькій частоті

cr0x@server:~$ sudo cpupower frequency-info | egrep 'driver|governor|current policy|current CPU frequency'
  driver: intel_pstate
  current policy: frequency should be within 1200 MHz and 3000 MHz.
                  The governor "powersave" may decide which speed to use
  current CPU frequency: 1200 MHz (asserted by call to hardware)

Що це означає: Під навантаженням ви можете бути все ще зафіксовані на низькій частоті. «powersave» з intel_pstate може бути прийнятним, але «asserted» на 1200 MHz підозріло, якщо ви повільні.

Рішення: Якщо продуктивність впала після оновлення прошивки/BIOS, тимчасово тестуйте з governor «performance» і порівняйте.

Завдання 3: Подивіться, чи система CPU-bound, I/O-bound або в очікуванні (vmstat)

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 812344  65284 9321440    0    0   112   398  812 2211 22  6 67  5  0
 6  1      0 799120  65284 9329900    0    0   124  4120  910 3102 28  7 44 21  0
 5  2      0 792884  65284 9321024    0    0    96  3856  901 2904 24  6 40 30  0
 3  0      0 806220  65284 9334500    0    0    88   512  780 2401 20  5 73  2  0
 7  3      0 790004  65284 9320044    0    0   144  4096  950 3200 26  7 39 28  0

Що це означає: «wa» (iowait) підскакує до 21–30%. «b» (заблоковані процеси) >0. Це класичний тиск на I/O.

Рішення: Припиніть говорити про апгрейд CPU. Перейдіть до метрик диска і файлової системи (iostat, pidstat, глибина черг сховища).

Завдання 4: Виявити насичення диска та латентність (iostat)

cr0x@server:~$ iostat -xz 1 3
Linux 6.5.0-18-generic (server) 	01/09/2026 	_x86_64_	(56 CPU)

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
          21.3    0.0     6.2    18.9     0.0    53.6

Device            r/s     w/s   rkB/s   wkB/s  rrqm/s  wrqm/s  %util  await  r_await  w_await
nvme0n1         120.0   980.0  6400.0 52000.0    0.0    0.0   98.7   14.2     2.1     15.7
sdb               0.0   220.0     0.0  8800.0    0.0   40.0   96.1   42.8     0.0     42.8

Що це означає: Два пристрої близькі до 100% використання. «await» високе на sdb (42.8 ms). Це латентність, видима користувачу.

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

Завдання 5: Знайти процес, що викликає I/O wait (pidstat)

cr0x@server:~$ pidstat -d 1 5
Linux 6.5.0-18-generic (server) 	01/09/2026 	_x86_64_	(56 CPU)

03:10:11 PM   UID       PID   kB_rd/s   kB_wr/s kB_ccwr/s iodelay  Command
03:10:12 PM  1001     18422      0.00  18240.00      0.00     120  postgres
03:10:12 PM     0      1223      0.00   6400.00      0.00      80  systemd-journald
03:10:12 PM  1002     22019    512.00    128.00      0.00      10  nginx

Що це означає: Postgres і journald — великі писателі. iodelay підвищений.

Рішення: Якщо journald шумить, обмежте частоту або віднесіть логи на інший диск. Для Postgres перевірте контрольні точки, розміщення WAL і поведінку fsync.

Завдання 6: Виміряти переключення контексту і тиск черги виконання (pidstat -w)

cr0x@server:~$ pidstat -w 1 3
Linux 6.5.0-18-generic (server) 	01/09/2026 	_x86_64_	(56 CPU)

03:11:02 PM   UID       PID   cswch/s nvcswch/s  Command
03:11:03 PM  1001     18422    220.00    980.00  postgres
03:11:03 PM  1003     19110  12000.00  31000.00  java

Що це означає: Java сильно переключається між контекстами. Може бути contention на блокуваннях, забагато потоків або поведінка GC.

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

Завдання 7: Підтвердити тиск по пам’яті та великі сторінкові помилки (sar)

cr0x@server:~$ sar -B 1 3
Linux 6.5.0-18-generic (server) 	01/09/2026 	_x86_64_	(56 CPU)

03:11:40 PM  pgpgin/s pgpgout/s   fault/s  majflt/s  pgfree/s pgscank/s pgscand/s pgsteal/s    %vmeff
03:11:41 PM      0.00    8200.00  24000.00     12.00  18000.00   4200.00      0.00   4100.00     97.6
03:11:42 PM      0.00    7900.00  23000.00     10.00  17500.00   3800.00      0.00   3700.00     97.4
03:11:43 PM      0.00    8600.00  25000.00     15.00  19000.00   4500.00      0.00   4400.00     97.8

Що це означає: Є великі сторінкові помилки (majflt/s ≈ 10–15). Це повільно. Може вказувати на тиск пам’яті або активний обмін сторінками файлів.

Рішення: Якщо латентність важлива — зменшіть overcommit пам’яті, налаштуйте кеші або додайте RAM. Не «оптимізуйте код», коли відбувається пагінг.

Завдання 8: Перевірити використання swap і чи відбувається свопінг

cr0x@server:~$ free -h
               total        used        free      shared  buff/cache   available
Mem:           125Gi        92Gi       1.2Gi       2.4Gi        32Gi        28Gi
Swap:          8.0Gi       3.1Gi       4.9Gi

Що це означає: Swap використовується. Не завжди фатально, але якщо свопінг триває під навантаженням — очікуйте сплески латентності.

Рішення: Корелюйте з vmstat «si/so». Якщо активно, зменшіть пам’ятний слід, додайте RAM або перерозподіліть навантаження.

Завдання 9: Підтвердити опції монтованої файлової системи (штрафи за sync реальні)

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

Що це означає: ext4 в режимі ordered, relatime. Немає очевидно шкідливих опцій як «sync» або «noatime», які замінюють розмови замість даних.

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

Завдання 10: Інспектувати черги блочного шару і планувальник

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

Що це означає: Активний «none». На NVMe це часто нормально; на SATA HDD вибір планувальника може грати більшу роль.

Рішення: Якщо ви на ротаційному носії з мікшованими навантаженнями, розгляньте mq-deadline/bfq (тестуйте обережно). На NVMe фокусуйтеся на шаблонах додатку і глибині черги перш за все.

Завдання 11: Швидко зловити причини простоїв CPU (perf stat)

cr0x@server:~$ sudo perf stat -p 18422 -- sleep 10
 Performance counter stats for process id '18422':

        12,004.12 msec task-clock                       #    1.200 CPUs utilized
     3,812,332,100      cycles                          #    3.175 GHz
     2,104,221,900      instructions                    #    0.55  insn per cycle
        44,110,220      branches
         1,102,114      branch-misses                   #    2.50% of all branches

      10.003941915 seconds time elapsed

Що це означає: IPC ≈ 0.55. Це низько для багатьох навантажень, часто вказує на простої (пам’ять, блокування, I/O). Не доказ, але сильний натяк.

Рішення: Якщо IPC низький і iowait високий — ганяйте I/O. Якщо IPC низький і iowait низький — шукайте пропуски кешу, проблеми з локальністю або contention на блокуваннях.

Завдання 12: Визначити топ латентних системних викликів (підсумок strace)

cr0x@server:~$ sudo strace -ttT -p 18422 -f -o /tmp/trace.log -s 80 -qq -e trace=%file,%network,%process,%memory -c -w -q sleep 5
% time     seconds  usecs/call     calls    errors syscall
 42.18    0.812345        2201       369           fsync
 25.02    0.481002          92      5200      120  openat
 18.11    0.348771         301      1158           pwrite64
  7.44    0.143201          55      2600           recvfrom
  7.25    0.139001          61      2250           futex
------ ----------- ----------- --------- --------- ----------------
100.00    1.924320                   12735       240 total

Що це означає: fsync домінує за часом. Це латентність сховища, write barriers або поведінка WAL-подібних систем.

Рішення: Якщо fsync домінує — потрібні швидкі й довговічні записи (окремий пристрій, краще сховище, стратегія пакетування), а не «ще CPU».

Завдання 13: Перевірити, що мережа не є прихованим вузьким місцем (ss)

cr0x@server:~$ ss -s
Total: 1320 (kernel 0)
TCP:   1180 (estab 640, closed 420, orphaned 0, timewait 390)

Transport Total     IP        IPv6
RAW	  0         0         0
UDP	  48        44        4
TCP	  760       702       58
INET	  808       746       62
FRAG	  0         0         0

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

Рішення: Якщо латентність «рандомна», перевірте статистику інтерфейсу і ретрансляції (наступне завдання).

Завдання 14: Перевірити ретрансмісії та пропуски NIC (ip -s link)

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
    link/ether 3c:fd:fe:aa:bb:cc brd ff:ff:ff:ff:ff:ff
    RX:  bytes  packets  errors  dropped  missed  mcast
    9876543210  8123456       0     1200       0    220
    TX:  bytes  packets  errors  dropped  carrier collsns
    1234567890  2345678       0        0       0       0

Що це означає: RX dropped 1200. Може бути переповнення кільця, проблеми драйвера або просто сплески, що перевищують пропускну здатність.

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

Завдання 15: Підтвердити, що терміни або апаратні помилки не імітують «проблеми продуктивності»

cr0x@server:~$ sudo dmesg -T | egrep -i 'thermal|thrott|mce|edac|error' | tail -n 8
[Thu Jan  9 14:58:12 2026] mce: [Hardware Error]: CPU 3: Machine Check: 0 Bank 6: b200000000070005
[Thu Jan  9 14:58:12 2026] mce: [Hardware Error]: TSC 0 ADDR fef1c140 MISC d012000100000000 SYND 4d000000 IPID 600b000000000
[Thu Jan  9 14:58:12 2026] EDAC MC0: 1 CE memory read error on CPU_SrcID#0_Channel#1_DIMM#0 (channel:1 slot:0 page:0x12345 offset:0x0 grain:32)

Що це означає: Кориговані помилки ECC і MCE. Проблеми продуктивності можуть бути через повторні спроби, дроселювання або сигналів про неминучу відмову обладнання.

Рішення: Ескалюйте на заміну апаратного забезпечення або мігруйте робочі навантаження. Не «налаштовуйте» помираючу коробку.

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

Це той шматок, який варто надрукувати й приклеїти біля монітора. Мета — швидкість із правильністю: визначити, яка підсистема насичена,
потім вибрати наступне вимірювання, що або підтвердить, або виключить вашу основну гіпотезу.

Спочатку: класифікуйте проблему (секунди)

Це пропускна здатність чи латентність? «Джоби тривають довше» проти «запити таймаутяться». Різні режими відмови.
Глобально чи локально? Один хост, одна зона, один орендар, один шард, один endpoint.
Нове чи циклічне? Регресії пахнуть конфігураціями/релізами. Цикли пахнуть пакетними роботами та лімітами ємності.

Друге: перевірте насичення і очікування (1–2 хвилини)

CPU: vmstat 1 і mpstat -P ALL 1. Шукайте тиск черги виконання і сплески system time.
Диск: iostat -xz 1. Шукайте %util близько 100% і зростання await.
Пам’ять: free -h, sar -B. Шукайте великі сторінкові помилки, своп-чорги.
Мережа: ss -s, ip -s link. Шукайте пропуски, ретрансляції, ріст з’єднань.

Третє: атрибутуйте навантаження (5–15 хвилин)

Який процес? pidstat -d, pidstat -u, top або htop.
Який патерн системних викликів? strace -c, щоб виявити fsync-шторми, openat-чад, futex-contestion.
Яка мікро-причина? perf stat (підказка про IPC) і прицільне трасування (якщо потрібно).

Четверте: вирішіть, чи мають тут значення такти (урок Pentium II/III застосований)

Якщо вузьке місце пов’язане з обчисленням з пристойним IPC і мінімальними очікуваннями — допоможуть швидші такти/ядра.
Якщо вузьке місце — i/o wait або черги, швидші такти здебільшого лише згоратимуть електрику, поки ви чекаєте швидше.
Якщо вузьке місце — затримки пам’яті, виправляйте локальність, кешування або пропускну здатність/латентність пам’яті — не MHz.

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

1) «CPU лише 40%, тож CPU не може бути проблемою»

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

Корінна причина: Навантаження блокується (диск, мережа, блокування), тож CPU стоїть у просте.

Виправлення: Виміряйте iowait і черги: vmstat, iostat, pidstat -d. Виправте реальне вузьке місце (індекси, сховище, contention).

2) «Виправимо продуктивність, збільшивши розміри буферів»

Симптом: Середня латентність покращується, хвостова латентність гіршає; з’являються періодичні зупинки.

Корінна причина: Ви створили вибухоподібну поведінку flush/reclaim (writeback-шторми, GC-шторми, checkpoint-шторми).

Виправлення: Налаштуйте для передбачуваності: обмежте dirty ratios, згладьте checkpoints, обмежуйте продуцентів і валідируйте за p95/p99, а не лише середніми.

3) «Порівняння MHz між CPU справедливе»

Симптом: Новий CPU з тією ж GHz швидший/повільніший, ніж очікували.

Корінна причина: Різниця IPC, зміни ієрархії кешів, відмінності підсистеми пам’яті, поведінка turbo.

Виправлення: Порівнюйте з бенчмарками, специфічними для робочого навантаження, та лічильниками: perf stat і метрики SLO аплікації.

4) «Диск зараз швидкий, тож нам не треба піклуватись про I/O патерни»

Симптом: SSD показує високий %util, латентність зростає при конкурентності.

Корінна причина: Насичення глибин черги, синхронні навантаження, write amplification, дрібні випадкові записи.

Виправлення: Розділяйте WAL/логи, пакетируйте записи, обирайте коректні опції mount, і розраховуйте IOPS, а не лише ємність.

5) «Система повільна після зміни, тож винен код»

Симптом: Регресія після обслуговування, патчів або перезавантаження.

Корінна причина: Скидання BIOS, зміна governor, зміна драйвера, зміна політики RAID cache.

Виправлення: Перевірте політику частоти, dmesg на апаратні помилки, налаштування сховища і порівняйте з базовими показниками перед тим, як звинувачувати аплікацію.

6) «Додаючи потоки, ми додаємо пропускну здатність»

Симптом: CPU зростає, пропускна здатність на місці, латентність гіршає.

Корінна причина: Контеншн блокувань, bounce кеш-ліній, накладні переключень контексту.

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

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

Контрольний список A: Коли хтось пропонує «просто купити швидший CPU»

Попросіть про метрику, що падає: p95 латентність, пропускна здатність, час у черзі або CPU time.
Запустіть vmstat 1 10 і зафіксуйте: run queue (r), blocked (b), iowait (wa).
Запустіть iostat -xz 1 5 і зафіксуйте: %util, await, та співвідношення читань/записів.
Запустіть pidstat -u 1 5 і pidstat -d 1 5 щоб знайти топові процеси.
Якщо CPU-bound: підтвердіть поведінку частоти командою cpupower frequency-info.
Якщо memory-bound: підтвердіть великі сторінкові помилки командою sar -B і перевірте своп.
Лише потім обговорюйте зміни SKU CPU, і лише з бенчмарками робочого навантаження.

Контрольний список B: «Швидкі але крихкі» зміни налаштувань (не відправляйте їх всліпу)

Визначте успіх через хвостові метрики (p95/p99) і помилки.
Проведіть canary зміни на одному вузлі або малому шарді.
Переконайтеся, що ви не поміняли дрібні постійні зупинки на періодичні великі.
Зафіксуйте до/після: частоту CPU, iostat await і гістограми латентності аплікації.
Майте відкат однією командою або одним перемикачем конфігурації.

Контрольний список C: Регресії після перезавантаження/обслуговування

Перевірте політику CPU: cpupower frequency-info.
Перевірте dmesg на апаратні помилки: dmesg -T | egrep -i 'mce|edac|thermal|error'.
Підтвердіть, що опції монтів і імена пристроїв не змінилися: findmnt, lsblk.
Переконайтеся, що NIC коректно домовився про швидкість (speed/duplex): ethtool eth0 (якщо доступно).
Порівняйте з baseline дашбордами або збереженими виводами з ранубуку.

Питання й відповіді (FAQ)

1) Чи коли-небудь MHz були хорошою метрикою продуктивності?

Це була груба метрика, коли архітектури були схожі, домінувало одноядерне виконання й вузькі місця були стабільними.
Навіть тоді різниця кешу й FSB могла зламати порівняння.

2) Чому Pentium II/III створювали відчуття «лінійності» в продуктивності?

Менше рухомих частин: менше динамічного бустингу, простіша топологія пам’яті, менше бекграунд-сервісів і навантаження, що часто були або compute-bound, або очевидно disk-bound.
Вузьке місце системи було легше ідентифікувати, тож апгрейди відчувалися передбачуваними.

3) Який сучасний аналог старого вузького місця front-side bus?

Оберіть щось на ваш смак: канали пам’яті, NUMA-зв’язки, спільний LLС, кореневий комплекс PCIe або глибина черги контролера зберігання.
Шаблон той самий: спільний шлях насичується, черги ростуть, латентність піднімається.

4) Чи змінив SSE у Pentium III історію «MHz означає продуктивність»?

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

5) Якщо такти тепер «мають менше значення», на що мені дивитися?

Дивіться на end-to-end латентність, черги й причини простоїв: iowait, disk await, run queue, великі сторінкові помилки і IPC.
Потім виміряйте CPU time на запит і час, проведений у очікуванні.

6) Як я зрозумію, що я memory-bound?

Звичні ознаки: низький IPC, високі показники промахів кешу (потрібне глибше профілювання) і продуктивність, що не покращується після додавання CPU.
Також слідкуйте за великими сторінковими помилками і активністю swap; пагінг може маскуватися під «повільний CPU».

7) Який найпростіший спосіб уникнути култя продуктивності?

Робіть baseline перед змінами: зафіксуйте iostat await, vmstat wa, політику частоти CPU і p95/p99 аплікації.
Якщо ви не можете порівняти «до/після», ви просто збираєте відчуття.

8) Чи є уроки з епохи Pentium II/III, що прямо застосовуються до SRE сьогодні?

Три великі: (1) локальність кешу важлива, (2) спільні шляхи/шини завжди стають вузькими місцями, (3) вимірюйте очікування і черги перед тим, як купувати більше CPU.
Та епоха була класом з меншими відволіканнями.

9) Якщо я на сучасному залізі, навіщо мені взагалі перейматись цією старою епохою?

Тому що це змушує думати в термінах конвеєрів, а не гасел. «Швидший CPU» — це гасло. «Це навантаження блокується на fsync-латентності» — це діагноз.
Епоха Pentium вчила людей бачити різницю.

Практичні наступні кроки

Якщо ви хочете винести щось операційно корисне з епохи Pentium II/III «коли такти мали значення», візьміть це:
продуктивність — сума конвеєра, а такти — лише один клапан. Ваше завдання — знайти клапан, що справді закритий.

Прийміть швидкий спосіб діагностики і запускайте його перед пропозицією зміни заліза.
Почніть збирати невеликий базовий набір для кожного сервісу: vmstat, iostat, політику частоти CPU і p95 латентність.
Коли підозрюєте CPU — підтвердіть це через IPC і метрики очікування, а не лише utilization.
Коли підозрюєте диск — доведіть це через await/%util і свідчення системних викликів (fsync/pwrite патерни).
Робіть налаштування непоказними: canary, вимірюйте хвости, відкат швидкий.

Роки Pentium II/III не були кращими тому, що машини були «простішими». Вони були кращими тому, що наслідки були ясніші.
Створіть системи, де наслідки знову стануть ясними: вимірюйте, атрибуйте й виправляйте вузьке місце, яке ви можете назвати.