Athlon: рік, коли Intel справді злякалася

Чому Athlon був загрозою (а не просто претендентом)

Athlon не був просто «AMD нарешті догнала». Це була AMD, яка вибирала правильні бої: продуктивність на такт, пропускна здатність пам’яті
і платформа, яка не виглядала як вибачення. Наприкінці 1990-х і на початку 2000-х бренд Intel
був базовим пунктом у замовленнях. Athlon показав, що такий пункт може бути неправильним.

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

Продуктивність — це не тактова частота; це час до корисної роботи

Intel і AMD обидві випускали швидкий кремній. Але Athlon частіше перетворював свою теоретичну можливість на доставлену
пропускну здатність — особливо у змішаних навантаженнях, які люди фактично запускали: ігри, збірки, workstation-застосунки та ранні серверні задачі, що дбали про поведінку пам’яті.

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

Історія шини й кешу (те, що маркетологи не люблять)

Екосистема Athlon змусила багатьох звернути увагу на платформу як систему: ядро CPU, ієрархія кешів,
розташування зовнішнього L2 (на ранніх моделях), підсистема пам’яті, якість чіпсету і — критично — як усе це взаємодіє під навантаженням.
Якщо ви колись бачили, як апгрейд до 2× CPU дає 0% покращення, бо ваша БД чекає на сховище, ви вже пережили цей урок.

Жарт №1: Єдина річ більш оптимістична за бенчмарк — це інженер, який запускал його на простій системі.

Короткі факти та історичний контекст

Конкретні точки, що важливі, бо вони формували дизайн-рішення й конкурентну поведінку:

1. Athlon запустили в 1999 році і він швидко став сприйматися як «найшвидший x86» у масовій свідомості, а не лише в нішевих колах.
2. Slot A виглядав як Slot 1 від Intel, але електрично був несумісний — навмисна платфорна лінія в піску.
3. Ранні Athlon використовували зовнішній L2 кеш, розташований на картриджі; пізніший «Thunderbird» переніс L2 на кристал, зменшивши затримку та покращивши ефективну пропускну здатність.
4. Спадщина шини EV6 (успадкована від DEC Alpha) дала Athlon історію платформи навколо пропускної здатності й масштабування, що виглядало сучасно для свого часу.
5. «Thunderbird» (2000) зробив Athlon не просто конкурентним, а часто домінантним у співвідношенні ціна/продуктивність для користувацьких навантажень.
6. Ера Pentium III від Intel мала сильну продуктивність на такт, але історія платформи і тиск на дорожню карту були реальними; ринок був менш однобічним, ніж натякав стікер «Intel Inside».
7. Брендинг мав значення: стиль найменувань AMD «Performance Rating» пізніше відобразив потребу індустрії відійти від чистих порівнянь MHz.
8. Терміни та енергоспоживання стали стратегічними у міру росту тактових частот; ця епоха підготувала пізніший поворот індустрії від «GHz будь-якою ціною».
9. Чіпсети були поверхнею ризику: зрілість сторонніх чіпсетів могла зробити або зламати реальну стабільність, передбачаючи нинішній ланцюг надійності «апаратне забезпечення + прошивка + драйвери».

Де Intel насправді зреагувала

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

Неприємна частина: Athlon зробив вибір за замовчуванням дискусійним

Великі постачальники процвітають завдяки інерції. Перевага Intel полягала не лише в інженерії; вона полягала у зручності закупівлі.
Коли Athlon був сильним, «нікому не вигідно звільнити за покупку Intel» стало менш правдою — бо люди почали звільнятися за купівлю дорожчого варіанту, що не давав кращої продуктивності за долар.

Конкурент, який змушує приймати рішення, є небезпечним. Це запускає ревізії: «Чи ми переплачуємо? Чи наша дорожня карта занадто оптимістична? Ми бенчмаркуємо правильну річ?»
Це страх у корпоративній формі: не терор, а прискіпливість.

Урок Intel (і ваш): дорожні карти реальні лише якщо фізика погоджується

Цей період нагадує, що інженерні обмеження рано чи пізно накопичують свій борг. Ви можете проговорити квартал. Ви не можете проговорити латентність пам’яті або щільність потужності вічно.
Успіх Athlon не лише вкрав продажі; він звузив графік реальності для Intel.

Вимога цитати (перефразована ідея): Ідея Джона Оустерхаута: не вгадуйте продуктивність — вимірюйте її, бо інтуїція систематично помиляється в реальних системах. — John Ousterhout (перефразовано)

Жарт №2: Якщо ваша дорожня карта залежить від «а потім кеш стане швидким», це не план; це казка перед сном.

Уроки архітектури, які повинні перейняти SRE

1) Вузькі місця переміщуються; вони не зникають

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

2) Якість платформи важить так само, як пікова швидкість CPU

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

3) Латентність — це фіча продукту, навіть якщо ви її не продаєте

Користувачі не купують «нижчу латентність кешу». Вони купують «це відчувається швидким» і «воно не підвисає».
Ваші клієнти не купують «p99 покращився на 30%». Вони купують «оплата пройшла» і «пошук не зависає».
Перевага Athlon у багатьох навантаженнях полягала в кращій реальній відчутній швидкості — не просто в показі в технічному паспорті.

4) Бенчмарки — інструменти, не вироки

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

5) Конкурентний тиск покращує дисципліну в операціях

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

План швидкої діагностики: знайдіть вузьке місце до зустрічі

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

По-перше: система завантажена CPU чи чекає?

• Перевірте load average у порівнянні з використанням CPU (високий load з низьким CPU часто означає очікування вводу/виводу).
• Подивіться на чергу виконання, зміну контекстів і iowait.
• Вирішіть: ганятися за CPU-циклами, за проблемами конкурентності чи за зовнішніми залежностями?

По-друге: якщо CPU гарячий — чи виконує він корисну роботу?

• Визначте процеси й потоки, що споживають найбільше.
• Перевірте надмірний sys time, переривання і softirqs (мережеві шторми, переривання сховища).
• Вирішіть: налаштувати додаток, налаштувати ядро/мережу або зменшити тиск переривань?

По-третє: якщо чекає — яка черга накопичується?

• Диск: латентність (await), завантаження, глибина черги.
• Мережа: повторні передачі, втрати, черги сокетів.
• Пам’ять: свопінг, великі помилки сторінок, thrash кешу сторінок.
• Вирішіть: масштабування, перерозподіл, виправлення конфігурації або зміна розміщення навантаження.

По-четверте: підтвердіть однією «земною правдою» — трасою

• Короткий замір perf, eBPF-трейс або захоплення повільних запитів бази даних.
• Вирішіть: випустити фікс, відкочувати чи застосувати хірургічну міру.

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

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

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

cr0x@server:~$ uptime
 14:22:10 up 32 days,  3:11,  2 users,  load average: 18.42, 17.90, 16.55

Значення: Load average ~18 на машині з, скажімо, 8 vCPU викликає підозру. Load рахує runnable та uninterruptible процеси.
Якщо використання CPU не відповідає, часто це очікування вводу/виводу або блокування.
Рішення: Не масштабувати CPU одразу. Спочатку перевірте iowait і чергу виконання.

Завдання 2: Підтвердити iowait, чергу виконання і steal time

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

14:22:12     CPU   %usr   %nice    %sys %iowait   %irq  %soft  %steal  %idle
14:22:13     all   22.10    0.00    6.45   38.90   0.10   1.25    0.00  31.20
14:22:13       0   25.00    0.00    7.00   41.00   0.00   1.00    0.00  26.00

Значення: iowait ~39% означає, що CPU простає, бо чекає на завершення I/O.
Рішення: Перейдіть до метрик шляху зберігання (iostat, nvme, mdraid, filesystem). Апгрейд CPU не допоможе.

Завдання 3: Перевірити латентність і черги по кожному диску

cr0x@server:~$ iostat -x 1 3
Linux 6.5.0 (server)  01/09/2026  _x86_64_  (16 CPU)

Device            r/s     w/s   rkB/s   wkB/s  avgqu-sz  await  r_await  w_await  %util
nvme0n1         120.0   450.0   8400   51200      9.20   18.4     4.2     22.1   96.0
nvme1n1         110.0   430.0   8000   49800      8.70   17.9     4.0     21.6   94.5

Значення: %util ~95% і avgqu-sz ~9 вказують на те, що NVMe-пристрої близькі до насичення; await ~18ms високий для NVMe при стабільному навантаженні.
Рішення: Зменшити write amplification (налаштування БД), перемістити «гарячі» дані, додати пристрої або виправити конфігурацію файлової системи/RAID.

Завдання 4: Визначити головні процеси-правопорушники

cr0x@server:~$ pidstat -d 1 3
Linux 6.5.0 (server)  01/09/2026  _x86_64_  (16 CPU)

14:22:20      UID       PID   kB_rd/s   kB_wr/s kB_ccwr/s  Command
14:22:21     1001     18422      80.00  22000.00  15000.00 postgres
14:22:21        0      1432       0.00   1800.00      0.00  journald

Значення: Postgres генерує інтенсивні записи, і багато з них — «cancelled writes» (поведінка кешу при writeback), часто пов’язана з fsync-паттернами.
Рішення: Перегляньте чекпойнти БД, налаштування WAL і опції монтування файлової системи; розгляньте виділення WAL на окремий пристрій.

Завдання 5: Помітити тиск пам’яті і свопінг (тиха вбивця латентності)

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
 6  4  262144  12000  32000 1800000  0   64   120  8400 4200 9800 18  6 33 43  0

Значення: Нульове, але не нульове значення so (swap out) вказує, що ядро витісняє сторінки в swap під тиском. У поєднанні з високим wa (iowait) це погіршує ситуацію.
Рішення: Зменшити пам’ятний слід, відрегулювати ліміти cgroup, додати ОЗП або ізолювати «жерців пам’яті» від сервісів, чутливих до латентності.

Завдання 6: Підтвердити файлову систему та опції монтування (синхронні пастки)

cr0x@server:~$ mount | grep ' /var/lib/postgresql '
/dev/nvme0n1p2 on /var/lib/postgresql type ext4 (rw,relatime,data=ordered)

Значення: ext4 data=ordered — нормальна опція, але патерни навантаження (інтенсивні fsync) все ще можуть шкодити. Також перевірте бар’єри, discard і поведінку журналювання залежно від пристрою.
Рішення: Якщо латентність нестабільна, розгляньте відділення WAL, налаштування чекпойнтингу або використання файлових систем/пристроїв, вирівняних під ваш профіль записів.

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

cr0x@server:~$ sudo nvme smart-log /dev/nvme0
Smart Log for NVME device:nvme0 namespace-id:ffffffff
critical_warning                    : 0x00
temperature                         : 44 C
available_spare                     : 100%
percentage_used                     : 72%
media_errors                        : 0
num_err_log_entries                 : 3

Значення: percentage_used 72% свідчить, що диск значно відпрацював; записи у журналі помилок існують, навіть якщо media_errors = 0.
Рішення: Заплануйте заміну до того, як це стане інцидентом надійності; перевірте прошивку і історію логів на наявність закономірностей.

Завдання 8: Знайти гарячі точки CPU коли CPU справді є межею

cr0x@server:~$ sudo perf top -g --call-graph dwarf
Samples: 2K of event 'cpu-clock:pppH', 4000 Hz, Event count (approx.): 500000000
  18.40%  postgres  libc.so.6          [.] __memcmp_avx2_movbe
  11.10%  postgres  postgres           [.] hash_search_with_hash_value
   7.25%  postgres  postgres           [.] ExecHashJoin

Значення: Гарячий CPU у шляхах hash join / hashing вказує на проблеми форми запитів або відсутні індекси; memcmp може вказувати на великі порівняння або поведінку сортування/колації.
Рішення: Змінити плани запитів (індекси), зменшити тиск hash join, налаштувати work_mem або змінити схему. Купівля CPU не вирішить патологічний запит.

Завдання 9: Діагностувати конкуренцію за блокування (класика «апгрейд CPU не допоміг»)

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

14:23:10      UID       PID   cswch/s nvcswch/s  Command
14:23:11     1001     18422   1200.00  8400.00   postgres

Значення: Дуже велика кількість неконтрольованих переключень контексту (nvcswch/s) часто означає, що потоки змушені покидати CPU — блокування, очікування I/O, примусова прекомпенсація.
Рішення: Корелюйте з блокуваннями БД, статистикою планувальника ядра та I/O. Якщо це блокування — виправляйте стратегію конкурентності, а не підвищуйте такти.

Завдання 10: Повторні передачі й втрати в мережі (невидима латентність)

cr0x@server:~$ ss -s
Total: 4128 (kernel 0)
TCP:   2987 (estab 1842, closed 1010, orphaned 0, timewait 680)

Transport Total     IP        IPv6
RAW       0         0         0
UDP       23        19        4
TCP       1977      1860      117
INET      2000      1879      121
FRAG      0         0         0

cr0x@server:~$ ip -s link show dev eth0
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP mode DEFAULT group default qlen 1000
    RX:  bytes  packets  errors  dropped  missed   mcast
    981G  1183M   0       4212     0       0
    TX:  bytes  packets  errors  dropped  carrier collsns
    1044G 1201M   0       0       0       0

Значення: Втрачені пакети RX можуть спричинити повторні передачі, спайки хвоста латентності й таймаути додатків, що виглядають як «CPU повільний».
Рішення: Перевірте кільця NIC, coalescing переривань, невідповідність MTU і вузькі місця вгорі; розгляньте налаштування RSS/IRQ affinity.

Завдання 11: Підтвердити топологію NUMA і чи немає крос-сокетних трешів

cr0x@server:~$ numactl --hardware
available: 2 nodes (0-1)
node 0 cpus: 0 1 2 3 4 5 6 7
node 0 size: 64280 MB
node 0 free: 4100 MB
node 1 cpus: 8 9 10 11 12 13 14 15
node 1 size: 64280 MB
node 1 free: 3800 MB

Значення: Два NUMA-ноди. Якщо ваш процес перетягує пам’ять між нодами, ви платите за затримку.
Рішення: Зафіксуйте критичні сервіси на NUMA-ноді (CPU + пам’ять) або використайте cpusets cgroup, щоб зменшити крос-нодальні штрафи.

Завдання 12: Перевірити розподіл переривань (IRQ-шторми шкодять «швидким CPU»)

cr0x@server:~$ cat /proc/interrupts | head
           CPU0       CPU1       CPU2       CPU3       CPU4       CPU5       CPU6       CPU7
  24:    182392     192301     188210     190102          0          0          0          0  IR-PCI-MSI 524288-edge      nvme0q0
  25:         0          0          0          0     210334     220991     215002     219114  IR-PCI-MSI 524289-edge      nvme0q1

Значення: Черги розподілені по множинах CPU — це добре. Якщо всі переривання прикріплені до одного CPU, то це стає вашим «Athlon vs Pentium» вузьким місцем: одне насичене ядро змушує всю машину виглядати повільною.
Рішення: Виправте IRQ affinity або увімкніть правильний RSS/multiqueue; потім повторно виміряйте p99 латентність.

Завдання 13: Підтвердити стек зберігання (RAID/LVM) щоб він не був прихованою чергою

cr0x@server:~$ lsblk -o NAME,TYPE,SIZE,FSTYPE,MOUNTPOINT
NAME        TYPE  SIZE FSTYPE MOUNTPOINT
nvme0n1     disk  1.8T
├─nvme0n1p1 part  512M vfat   /boot/efi
└─nvme0n1p2 part  1.8T ext4   /var/lib/postgresql
nvme1n1     disk  1.8T

Значення: Тут немає RAID/LVM — проста розкладка. Якщо у вас є mdraid/LVM, підтвердіть розмір смуги, налаштування черги та поведінку write cache.
Рішення: Тримайте простоту для шляхів, чутливих до латентності, якщо немає сильної причини та вимірів, які виправдовують складність.

Завдання 14: Підтвердити тиск на рівні ядра (PSI) щоб чітко бачити «очікування»

cr0x@server:~$ cat /proc/pressure/io
some avg10=22.31 avg60=18.02 avg300=12.44 total=128381223
full avg10=8.44 avg60=6.10 avg300=4.01 total=42188122

Значення: Значний IO тиск, включно з «full» старами, означає, що таски часто блокуються на I/O. Це ваш надійний доказ, коли дашборди неоднозначні.
Рішення: Ставтеся до цього як до проблеми ємності або формування навантаження (зменшити sync-записи, додати пристрої, ізолювати шумних сусідів), а не як до проблеми CPU.

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

cr0x@server:~$ curl -s localhost:9100/metrics | grep -E 'http_request_duration_seconds_bucket|http_request_duration_seconds_count' | head
http_request_duration_seconds_bucket{le="0.1"} 81234
http_request_duration_seconds_bucket{le="0.25"} 121882
http_request_duration_seconds_bucket{le="0.5"} 140012
http_request_duration_seconds_bucket{le="1"} 141100
http_request_duration_seconds_bucket{le="2.5"} 141360
http_request_duration_seconds_count 141420

Значення: Бакети показують поведінку хвоста. Якщо лічильник зростає, а низькі бакети вирівнюються, хвіст погіршується.
Рішення: Оптимізуйте для p95/p99, а не для середнього. Якщо хвіст корелює з IO тиском — виправляйте спочатку IO-подію.

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

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

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

Через кілька годин p99 латентність подвоїлася і з’явилися таймаути. Графіки CPU виглядали нормально. On-call робив те, що роблять, коли графік виглядає нормально: звинувачував додаток.
Команда додатку робила те, що роблять, коли їх звинувачують: надіслали десяток скріншотів і сказали «все працює на staging».

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

Фікс не був героїчним. Вони розділили журнал записів сервісу на локальний диск і залишили масивні дані на спільному сховищі.
p99 одразу відновився. Урок закарбувався: оновлення апаратури — це зміна платформи. Історія Athlon теж не була про «швидше ядро», а про ефективнішу систему в цілому.

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

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

Першим симптомом було дивне явище: пропускна здатність трохи зросла, але хвостова латентність стала скаженою. p50 покращився; p99 став жахливим.
Люди святкували p50 і ігнорували p99, поки клієнти не почали помічати. Класичний режим відмови: оптимізують медіану, а бізнес живе в хвості.

Сталося підсилення блокувань плюс підсилення I/O. Вища конкуренція спричинила більше конфліктів всередині бази — це збільшило переключення контексту.
Більший пул також дав більше забруднених сторінок і частіші writeback-шторми, наситивши NVMe-чергу і перетворивши iowait на повсякденність.

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

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

Команда фінансових сервісів запускала батч-систему, яка мала завершуватися до відкриття ринку. Нічого гламурного — ETL, звірка, генерація звітів.
Одного року вони мігрували вузли обчислення. Не тому що хотіли, а тому що продавець сказав, що стара платформа застаріла.

Вони зробили єдине, що працює під тиском: тримали базовий набір тестів. Не презентаційний базлайн — виконуваний.
Щотижня вони запускали той самий репрезентативний набір завдань, збирали латентність I/O, профілі CPU і кінцевий час. Версіонували це як код.

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

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

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

1) Симптом: високий load average, низьке використання CPU

Корінна причина: потоки застрягли в uninterruptible sleep (звично I/O з дисками, іноді NFS або перевантаження блочного шару).

Виправлення: Використайте mpstat щоб підтвердити iowait, а потім iostat -x і PSI (/proc/pressure/io) щоб визначити насичені пристрої. Зменшіть синхронні записи, додайте IOPS-ємності або відокреміть «гарячі» шляхи запису.

2) Симптом: апгрейд CPU не дає приросту пропускної здатності

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

Виправлення: Використайте perf top і pidstat -w. Якщо багато блокувань — зменшуйте конкурентність (шардування, партиціювання, переробіть критичні секції). Якщо I/O — виправляйте I/O.

3) Симптом: p50 покращується, але p99 погіршується після «оптимізації»

Корінна причина: збільшена черга через вищу конкуренцію; буфери заповнюються; writeback-шторми; паузи GC; перенаселення пулу з’єднань.

Виправлення: Обмежте конкуренцію. Виміряйте глибину черги і await. Налаштуйте чекпойнти/WAL БД, увімкніть backpressure і перестаньте вважати «більше потоків» стратегією.

4) Симптом: випадкові спайки латентності без очевидної кореляції

Корінна причина: періодичні завдання (бекупи, vacuum, compaction), профілі живлення прошивки або шумний сусід по I/O.

Виправлення: Корелюйте спайки з cron/systemd таймерами, профілями прошивки зберігання і IO pressure. Ізолюйте батч-роботи і перевірте налаштування енергозбереження пристроїв.

5) Симптом: таймаути мережі звинувачують «повільний сервер»

Корінна причина: втрата пакетів, повторні передачі, дисбаланс переривань NIC або невідповідність MTU, що викликає фрагментацію і втрати.

Виправлення: Перевірте ip -s link на втрати, ss -s на здоров’я сокетів і розподіл IRQ. Налаштуйте RSS/affinity і перевірте MTU енд-то-енд.

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

Корінна причина: дрібний випадковий I/O, синхронні записи, частота fsync або невідповідна глибина черги.

Виправлення: Оптимізуйте патерн I/O (пакетні записи, відокремлення WAL), налаштуйте файлову систему і переконайтеся, що пристрій не обмежує через терморежим або енергозбереження (перевірте NVMe SMART).

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

Коли хтось каже «новий хардвер повільніший»

1. Запустіть uptime і mpstat, щоб класифікувати CPU vs wait.
2. Якщо очікування: запустіть iostat -x і PSI IO, щоб визначити насичення пристроїв.
3. Перевірте тиск пам’яті за допомогою vmstat; зупиніться на свопінгу перш за все.
4. Перевірте мережеві втрати за допомогою ip -s link і стан сокетів через ss -s.
5. Захопіть короткий профіль CPU (perf top), якщо CPU є вузьким місцем.
6. Підтвердіть топологію: numactl --hardware і розподіл IRQ.
7. Зробіть одну зміну одночасно. Заново виміряйте. Зберігайте «до/після».

Перш ніж затверджувати «проект продуктивності»

1. Вимагайте репрезентативного навантаження, не лише синтетичного бенчмарка.
2. Визначайте успіх через p95/p99 і кількість помилок, а не лише через середню пропускну здатність.
3. Ідентифікуйте ймовірне вузьке місце і як воно може зміститися після зміни.
4. Наполягайте на кроках для rollback і плані канарки.
5. Запишіть базовий тест, який можна прогнати пізніше (версіюйте його).

Гігієна при зміні платформи (мудрість ери Athlon, модернізована)

1. Перелічіть налаштування прошивки/BIOS, що змінюють поведінку латентності (режими енергозбереження, профілі продуктивності).
2. Перевірте версії драйверів і конфігурації ядра для шляхів зберігання і мережі.
3. Переконайтесь, що файлові системи та опції монтування відповідають профілю записів навантаження.
4. Запустіть soak-тести достатньо довго, щоб впіймати періодичні технічні операції.

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

1) Чи був Athlon справді швидшим за Intel у всьому?

Ні. Це залежало від навантаження, платформи і покоління. Сенс у тому, що Athlon зробив твердження «залежить від випадку» неминучими — і це похитнуло наратив про автоматичну перевагу Intel.

2) Чому SRE мають цікавитися суперечкою CPU 1999 року?

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

3) Який сучасний еквівалент «не довіряти MHz»?

Не довіряйте позначкам типу інстансу, кількості vCPU або одиничним синтетичним показникам. Довіряйте p99 латентності під репрезентативним навантаженням, плюс метрики черг (I/O, мережа, блокування).

4) Якщо мої CPU на 40%, чи можу я просто збільшити конкуренцію?

Тільки якщо ви підтвердите, що не обмежені I/O, блокуваннями або пам’яттю. «Незайнятий CPU» часто означає, що CPU ввічливо чекає, поки справжнє вузьке місце працює.

5) Яка метрика найшвидше виявляє правду?

Для stateful систем — латентність I/O і тиск (iowait + iostat await + PSI IO); для безстанних сервісів — втрати пакетів і повторні передачі часто є «невидимими» причинами.

6) Як довести, що це сховище, а не код додатка?

Показати кореляцію: зростання await, зростання IO pressure, зростання p99 додатка й підвищення часу в uninterruptible sleep. Потім показати покращення після зменшення I/O навантаження або додавання ємності.

7) Яка найпростіша безпечна практика продуктивності, яку команди пропускають?

Перезапускний набір базових тестів із записаними системними метриками. Нудні, повторювані виміри перемагають героїчне дебагування щоразу.

8) Як припинити «театр бенчмарків» у вашій організації?

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

9) Який надійний сигнал, що «апгрейд апаратури» — насправді регресія платформи?

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

Висновок: наступні кроки, які можна реально виконати

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

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

• Виберіть один критичний сервіс і зафіксуйте базову лінію: p50/p95/p99, CPU, I/O латентність і мережеві втрати під репрезентативним навантаженням.
• Додайте PSI (CPU/пам’ять/I/O pressure) до стандартного дашборду для усунення суперечок.
• Напишіть односторінковий «runbook швидкої діагностики» для вашої команди за наведеним планом і прорепетируйте його раз.
• Коли хтось пропонує «більше потоків» або «більші CPU», вимагайте доказів, що вузьке місце дійсно в CPU.