Історія повернення Ryzen: чому здавалося раптовим (але не було)

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

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

Чому Ryzen здався раптовим

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

Якщо ви купували CPU у до-Ryzen епоху, ви, по суті, оптимізували під передбачуваність: послідовну поведінку платформи, передбачувані прапорці компілятора, налаштовані постачальником BIOS за замовчуванням і «ту дивність, яку ми вже знаємо». Потім з’явився Zen і запропонував іншу ціннісну пропозицію: багато ядер, конкурентний IPC та продуктивність за долар, яка змушувала команди закупівель посміхатися, наче вони знайшли баг у біллінгу.

Ось це відчуття «раптовості»: раніше консервативний простір рішень перевернувся. Не тому, що фізика змінилася, а тому, що зсунулась шкала компромісів. І тому, що тодішній темп Intel дав AMD широке вікно. Коли один гравець загальмовує, іншому не потрібно бути ідеальним — треба просто невпинно випускати компетентні частини.

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

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

Що фактично змінилося під капотом (і чому це мало значення)

Zen був скиданням, а не ітерацією

Zen — це не «потрібно підкрутити Bulldozer». Це була перебудова підходу AMD: вищий IPC, краща передбачуваність переходів розгалужень, поліпшена ієрархія кешів і сучасне ядро, що могло добре працювати в розрахунку на потік і масштабуватися на багато потоків. Мета була не просто перемогти в бенчмарку; це було створити платформу, яка могла одночасно підтримувати споживчі Ryzen і серверні EPYC без перетворення на інженерний науковий проєкт.

З погляду SRE, Zen зробив можливим ще одне: передбачуване масштабування продуктивності. Не ідеальне — нічого не ідеальне — але достатнє для того, щоб планування ємності знову могло використовувати «ядер × частот × профілю навантаження» без нервового сміху.

Чіплети змінили економіку, а потім і флот

Підхід AMD з чіплетами — рішення, яке здається очевидним після того, як ви побачили, як воно працює. Відокремити обчислювальні дієси від IO-die(ів). Виробляти гарячі щільні обчислювальні дієси на передовому технічному вузлі. Розміщувати контролери пам’яті й IO на більш зрілому вузлі. Відсоток придатних чіпів зростає, бінування продуктів розширюється, і компанія може випускати більше SKU без тотальної ставки на монолітний кристал.

На практиці це зробило два речі:

• Покращило постачання і співвідношення ціна/продуктивність: кращі виходи і гнучке бінування означають «більше ядер за ту саму ціну».
• Створило топологічну реальність: відстань між ядром і контролером пам’яті або між ядрами в різних чіплетах має значення. Затримка вже не дрібниця.

Ось чому Ryzen (а особливо EPYC) може бути одночасно мрією і пасткою. Якщо ваше навантаження орієнтоване на пропускну здатність, ви отримуєте велику вигоду. Якщо ви чутливі до затримок і халатні щодо локальності пам’яті, ви можете програти «повільнішому» CPU, бо випадково побудували лотерею віддаленої пам’яті.

Infinity Fabric: інтерконект, якого ви ігноруєте, поки він не виставить рахунок

Infinity Fabric — це внутрішній шлях AMD, що з’єднує чіплети й IO-die. Це не просто маркетинг; це практичне обмеження. Частота Fabric і налаштування пам’яті взаємодіють. BIOS за замовчуванням часто «безпечні», що з точки зору продуктивності означає «підходить для середнього десктопа, але неоптимально для вашої production бази даних».

Що робити: Стандартизувати версії BIOS і профілі пам’яті по флоту і розглядати налаштування, пов’язані з Fabric, як частину платформи, а не «тривіальне тонке налаштування».

Екосистема платформи дозріла (тихо)

Коли люди кажуть «Ryzen став кращим», часто вони мають на увазі «драйвери, BIOS, мікрокод, планування ядра і прошивка перестали бути вибуховими». Рання ера Zen мала справжнє дозрівання платформи з часом. Це невидимо для споживачів, які оновлюються раз у кілька років, але болісно видно SRE, які керують 400 однаковими вузлами і потребують їхньої ідентичної поведінки.

Одна з менш гламурних перемог: планувальники Linux і поведінка NUMA balancing покращилися для топології AMD. Це не заголовок новин, але це причина, чому розгортання Ryzen/EPYC 2023 року відчувається плавніше, ніж у 2017-му.

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

Факти та контекст, що роблять часову шкалу зрозумілою

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

1. Zen (2017) був першим по-справжньому конкурентним дизайном ядра AMD за роки і відновив очікування по IPC після епохи Bulldozer/Piledriver.
2. Перше покоління EPYC (Naples, 2017) винесло на стіл кількість ядер у спосіб, який змусив покупців серверів переглянути «Intel за замовчуванням».
3. Дизайн з чіплетами масштабувався швидше, ніж монолітні кристали, бо виходи і бінування полегшують послідовну постачання частин з великою кількістю ядер.
4. Infinity Fabric зв’язав поведінку пам’яті та інтерконекту, зробивши конфігурацію пам’яті більш релевантною для продуктивності CPU, ніж багато команд звикли.
5. Zen 2 (2019) перемістив обчислення на менший вузол, використовуючи окремий IO-die, покращивши ефективність і часто продуктивність на ват у реальних флотах.
6. Zen 3 (2020) покращив відносини ядро‑к‑кешу і зменшив штрафи за комунікацію між ядрами, що допомогло чутливим до затримок і змішаним навантаженням.
7. Міри безпеки вносилися нерівномірно між вендорами і поколіннями; іноді «регресії» продуктивності були більше пов’язані з міграціями, ніж з кремнієм.
8. Хмарні провайдери підтвердили AMD у масштабі, що змінило сприйняття ризику в підприємствах: «якщо вони це запускають, ми теж можемо».
9. Інструменти та планування ядра наздогнали: екосистема Linux вивчила нові топологічні шаблони і покращила значення за замовчуванням.

Погляд SRE: продуктивність — це характеристика надійності

У продакшні продуктивність — це не розкіш. Це маржа, яка рятує вас від викликів о 3-й ранку. Коли головний резерв CPU зменшується, все інше виглядає гірше: затримка запитів, глибина черг, паузи GC, відставання реплікації, беклоги компактації, TLS‑хендшейки і навіть «таємничі» втрати пакетів через перевантажені softirq.

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

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

• NUMA знову має значення: доступ до віддаленої пам’яті стає помітним податковим пунктом.
• Поведінка планувальника має значення: розміщення потоків може вирішувати між стабільним p99 і хронічним джитером.
• Швидкість пам’яті та таймінги мають значення: «вмикається» не є планом продуктивності.

Цитата, яка має висіти на стіні кожної опс-команди, бо вона груба й точна:

«Усе ламається, постійно.» — Werner Vogels

Ryzen цього не змінив. Він просто змінив де ви відчуєте відмову найперше: у припущеннях, що ви приносите з попередньої платформи.

Жарт №1: CPU не став «повільнішим після апгрейду». Ваш моніторинг просто почав казати правду з вищою роздільною здатністю.

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

Міні-історія 1: Інцидент через хибне припущення (NUMA як післядумова)

Компанія A мігрувала чутливий до затримок API‑шар з старих двопроцесорних серверів на нові високоядерні хости AMD. Міграція була «проста»: запекти новий образ, запустити ту саму версію Kubernetes, поступово перемикати трафік. Дашборди виглядали добре — аж поки ні. p95 був прийнятний, p99 почав хитатися, і раз на годину рівень помилок підскакував як серцебиття.

Інженер on-call обстежив звичні підозри: мережеві повторні передавання, шумні сусіди, дискові IO, збір сміття. Нічого очевидного. Завантаження CPU ніколи не перевищувало 55%, що робило інцидент образливим. Користувачі таймаутили, поки CPU «відпочивали».

Корінна причина була у хибному припущенні: що «один великий CPU — це один великий пул». Додаток мав модель thread-per-core і великий кеш в пам’яті. Kubernetes рівномірно розкидав поди і потоки по NUMA‑вузлах, а виділення пам’яті падали туди, куди щастило аллокатору. Результат: спайки віддалених доступів до пам’яті. Не постійні, але корельовані з оновленням кешу та періодичними фоновими задачами. Класичний p99 джитер.

Виправлення не було героїчним. Воно було нудним: прив’язати поди до NUMA‑вузлів, використовувати політики CPU і пам’яті affinity, і перевірити простим мікробенчмарком латентності під навантаженням. Також стандартизували налаштування BIOS і відключили кілька «енергозберігаючих» функцій, які були класними для десктопів, але посередні для хвостової латентності.

Висновок, що змінює рішення: Якщо ви припускаєте, що «NUMA не має значення», Ryzen рано чи пізно пришле вам рахунок з відсотками.

Міні-історія 2: Оптимізація, що шкідливо повернулась (надмірне налаштування пам’яті і Fabric)

Компанія B керувала аналітичним кластером з великими обсягами зберігання. Вони прочитали, що швидкість пам’яті і тонке налаштування Infinity Fabric можуть відкрити продуктивність. Тож інженери зробили те, що вони завжди роблять, коли захоплені: агресивно налаштували і швидко викотили зміни.

Вони підняли частоти пам’яті, відрегулювали таймінги, ввімкнули «оптимізований» профіль BIOS і святкували перші бенчмарк‑перемоги. Потім у продакшні почалися спорадичні machine check errors і рідкісні перезавантаження. Не достатньо, щоб відтворити на замовлення. Достатньо, щоб отруїти довіру до всього флоту.

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

Вони відкотилися до консервативного профілю пам’яті JEDEC, перекваліфікували DIMM і ввели правило: ніякого BIOS‑тюнінгу без burn-in, який включає тиск пам’яті, IO і термічне витримування. Бенчмарки — не продакшн. Продакшн мстивий.

Висновок, що змінює рішення: «Стабільно в бенчмарку» ≠ «стабільно у флоті». Розглядайте тюнінг BIOS як деплой коду: поетапний реліз, canary, план відкату.

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

Компанія C мала змішаний флот: частина Intel, частина AMD, кілька виробників материнських плат, кілька версій BIOS. На початку вони вирішили, що це неприйнятно. Вони створили базову платформу: короткий список затверджених версій BIOS, пакунків мікрокоду, версій ядра і невеликий набір налаштувань живлення/продуктивності. Також вони підтримували «відомо‑добрий» перелік апаратних компонентів для DIMM і NIC.

Людей це дратувало. Базлайни виглядали повільними. «Чому я не можу просто оновити BIOS в одному кластері?» Бо «мій один кластер» стає «наш весь інцидент», коли влучає рідкісна помилка. Вони виконували застосування базлайну за допомогою перевірок при провізії і періодичних аудитів.

Потім прийшло оновлення мікрокоду, що змінило характеристики продуктивності для частини криптографічних навантажень. Інші команди в їхній індустрії бачили регресії латентності і тижнями біскетували версії ядра. Компанія C помітила зміну швидко, бо вони мали canary, закріплені за базлайном, і відтворюваний набір бенчмарків для кожного оновлення прошивки/ядра.

Вони призупинили реліз, відкоригували планування ємності і лише потім розширили розгортання. Без аварій. Без драми. Просто трохи самозадоволений постмортем: «Ми помітили проблему раніше, ніж вона помітила наших клієнтів».

Висновок, що змінює рішення: Дисципліна прошивок нудна так само, як і ремені безпеки — але вона рятує.

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

Ви не «відчуваєте» продуктивність Ryzen. Ви її вимірюєте. Нижче — практичні завдання, які можна виконати на Linux‑хостах (bare metal або VM, де застосовано). Кожне містить, що означає вивід і яке рішення ухвалити.

Завдання 1: Визначити модель CPU, сокети та базову топологію

cr0x@server:~$ lscpu
Architecture:             x86_64
CPU(s):                   64
Thread(s) per core:       2
Core(s) per socket:       32
Socket(s):                1
NUMA node(s):             2
Model name:               AMD EPYC 7543 32-Core Processor
L3 cache:                 256 MiB
NUMA node0 CPU(s):        0-31
NUMA node1 CPU(s):        32-63

Значення: Навіть на одиночному сокеті у вас 2 NUMA‑вузли. Це нормально для багатьох EPYC-дизайнів. Ваше навантаження може бути крос‑вузловим, навіть якщо ви цього не усвідомлюєте.

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

Завдання 2: Перевірити версії ядра й мікрокоду (забезпечення базлайну)

cr0x@server:~$ uname -r
6.1.0-18-amd64
cr0x@server:~$ dmesg | grep -i microcode | tail -n 3
[    0.412345] microcode: CPU0: patch_level=0x0a20120a
[    0.412346] microcode: CPU1: patch_level=0x0a20120a
[    0.412347] microcode: Microcode Update Driver: v2.2.

Значення: Версія ядра впливає на планувальник і поведінку NUMA; мікрокод може впливати на стабільність і продуктивність.

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

Завдання 3: Переглянути відстані NUMA (видимість штрафу віддалених доступів)

cr0x@server:~$ numactl --hardware
available: 2 nodes (0-1)
node 0 cpus: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31
node 0 size: 257751 MB
node 0 free: 241120 MB
node 1 cpus: 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63
node 1 size: 257751 MB
node 1 free: 239998 MB
node distances:
node   0   1
  0:  10  21
  1:  21  10

Значення: Відстань 21 проти 10 означає матеріальний стрибок затримки, коли потоки на вузлі 0 звертаються до пам’яті, виділеної на вузлі 1.

Рішення: Якщо навантаження чутливе, забезпечте локальність (прив’язка процесів, cpuset, політика NUMA пам’яті).

Завдання 4: Перевірити поточний governor частоти CPU (щоб уникнути випадкового енергозбереження)

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

Значення: Governor визначає, як швидко ядра піднімають частоту під навантаженням. Деякі governor‑и можуть додавати джитер по затримці.

Рішення: Для послуг, критичних до затримки, розгляньте консистентні налаштування продуктивності (часто «performance») після валідації термалів і енергетичного бюджету.

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

cr0x@server:~$ journalctl -k | grep -iE 'throttle|thermal|hwmon' | tail -n 5
Jan 10 09:12:41 server kernel: CPU0: Core temperature above threshold, cpu clock throttled
Jan 10 09:12:41 server kernel: CPU0: Package temperature/speed normal

Значення: Тротлінг може зробити «швидкий CPU» схожим на посередній, особливо під тривалим навантаженням.

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

Завдання 6: Підтвердити швидкість пам’яті і заповнення каналів (перевірка Fabric/пам’яті)

cr0x@server:~$ sudo dmidecode -t memory | egrep -i 'Locator|Speed|Configured Memory Speed' | head -n 12
Locator: DIMM_A1
Speed: 3200 MT/s
Configured Memory Speed: 3200 MT/s
Locator: DIMM_B1
Speed: 3200 MT/s
Configured Memory Speed: 2933 MT/s
Locator: DIMM_C1
Speed: 3200 MT/s
Configured Memory Speed: 2933 MT/s

Значення: DIMM можуть підтримувати 3200 MT/s, але платформа працює на 2933 MT/s (часто через правила заповнення слотів або за замовчуванням BIOS).

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

Завдання 7: Підтвердити, що ECC увімкнений, і перевірити кількість виправлених помилок

cr0x@server:~$ sudo edac-util -v
edac-util: EDAC drivers are loaded.
mc0: 0 CE, 0 UE
mc1: 12 CE, 0 UE

Значення: Виправлені помилки (CE) — це не дармовина; вони вказують на зменшення маржі. Невиправлені (UE) — це тривога пожежної сигналізації.

Рішення: Якщо CE ростуть, плануйте заміну DIMM і подумайте про пом’якшення налаштувань пам’яті. Не чекайте, поки UE «становить урок».

Завдання 8: Визначити, чи ви CPU‑bound або блокуєтесь на IO

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 241120  18244 981232    0    0     3    12  540 1020 12  3 84  1  0
 8  0      0 241100  18244 981240    0    0     0     0 1240 5900 58  8 33  1  0
 9  0      0 241090  18244 981260    0    0     0     4 1320 6100 61  9 28  2  0

Значення: Високе r при низькому idle (id) вказує на конкуренцію CPU. Високе wa вказує на очікування IO. Висока кількість контекстних переключень (cs) може означати тиск планувальника.

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

Завдання 9: Знайти використання по ядрах і тиск softirq (для мережево‑важких сервісів)

cr0x@server:~$ mpstat -P ALL 1 3 | tail -n 8
Average:     CPU    %usr   %nice    %sys %iowait    %irq   %soft  %steal  %guest  %gnice   %idle
Average:      0    72.00    0.00   12.00    0.00    0.00    6.00    0.00    0.00    0.00   10.00
Average:      1     8.00    0.00    3.00    0.00    0.00   65.00    0.00    0.00    0.00   24.00
Average:     31     5.00    0.00    2.00    0.00    0.00    1.00    0.00    0.00    0.00   92.00

Значення: CPU1 домінує softirq, часто мережевою обробкою. Одне «гаряче» ядро може обмежувати пропускну здатність, поки «загальний CPU» виглядає добре.

Рішення: Обстежте IRQ‑affinity, налаштування RPS/XPS, кількість черг NIC і чи випадково ви не прив’язали всі переривання до одного NUMA‑вузла.

Завдання 10: Виміряти затримку черги планувальника і контекстні переключення за допомогою perf

cr0x@server:~$ sudo perf stat -e context-switches,cpu-migrations,cycles,instructions,cache-misses -a -- sleep 10
 Performance counter stats for 'system wide':

     18,240,112      context-switches
        420,331      cpu-migrations
  42,901,112,004      cycles
  61,221,990,113      instructions              #    1.43  insn per cycle
   1,220,991,220      cache-misses

      10.001234567 seconds time elapsed

Значення: Високі міграції можуть означати, що планувальник переміщує потоки між ядрами/NUMA‑вузлами, погіршуючи локальність кешу. IPC дає грубе уявлення про здоров’я; cache misses натякають на тиск пам’яті.

Рішення: Якщо міграції високі і латентність нестабільна, впровадьте affinity або дослідіть обмеження контейнерів/COS‑політик CPU.

Завдання 11: Перевірити резидентність C‑станів (джитер латентності і витрати на пробудження)

cr0x@server:~$ sudo powertop --time=1 --html=/tmp/powertop.html >/dev/null 2>&1
cr0x@server:~$ ls -lh /tmp/powertop.html
-rw-r--r-- 1 root root 188K Jan 10 09:44 /tmp/powertop.html

Значення: Звіт показує, скільки часу CPU витрачають у глибоких C‑станах. Глибокий сон зберігає енергію, але додає латентність пробудження.

Рішення: Для сервісів з критичною хвостовою латентністю розгляньте обмеження глибоких C‑станів у BIOS або параметрах ядра — після вимірювання енергоспоживання і термального впливу.

Завдання 12: Перевірити transparent huge pages і ризик фрагментації пам’яті

cr0x@server:~$ cat /sys/kernel/mm/transparent_hugepage/enabled
[always] madvise never

Значення: THP «always» може допомогти деяким навантаженням і зашкодити іншим (стрибки латентності при дефрагментації/компактації). Ryzen тут не особливий, але більша кількість ядер може посилити конкуренцію аллокатора.

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

Завдання 13: Підтвердити, що NUMA balancing робить те, що ви думаєте

cr0x@server:~$ cat /proc/sys/kernel/numa_balancing
1

Значення: Автоматичне NUMA balancing може покращувати локальність для деяких навантажень або вводити сканування і джитер для інших.

Рішення: Якщо ви бачите періодичні стрибки латентності і високі міграції, протестуйте відключення на canary і порівняйте p99/p999.

Завдання 14: Перевірити сигнали пропускної здатності і затримки пам’яті (швидка перевірка)

cr0x@server:~$ grep -E 'MemTotal|MemFree|MemAvailable' /proc/meminfo
MemTotal:       528898032 kB
MemFree:        241120000 kB
MemAvailable:   410552000 kB

Значення: Це не тест пропускної здатності, а саніті‑чек. Якщо MemAvailable низький, система під тиском пам’яті і може виконувати звільнення/компактацію, що імітує «повільність CPU».

Рішення: Якщо тиск пам’яті високий — виправте це спочатку (розмір кешу, розміщення навантажень), перш ніж звинувачувати покоління CPU.

Завдання 15: Підтвердити, що диск і файлові системи не є реальним вузьким місцем (рефлекс інженера збереження)

cr0x@server:~$ iostat -xz 1 3
Device            r/s     w/s   rKB/s   wKB/s  avgrq-sz  avgqu-sz   await  r_await  w_await  svctm  %util
nvme0n1         12.00   90.00   384.0  9216.0     184.0      3.20   28.10    5.20   31.10   0.45  46.80

Значення: await і avgqu-sz натякають на чергування. Якщо сховище чергує, ваш CPU очікує на IO, а не «повільний».

Рішення: Якщо %util високий і await зростає під навантаженням, займайтеся роботою по зберіганню: глибина черг, IO‑планувальник, опції файлової системи або стан NVMe.

Завдання 16: Перевірити віртуалізаційні особливості і чи ви всередині VM (не бенчмаркуйте неправильну річ)

cr0x@server:~$ systemd-detect-virt
none
cr0x@server:~$ lscpu | grep -i hypervisor

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

Рішення: Бенчмаркуйте на bare metal або переконайтесь, що гіпервізор коректно відкриває топологію і пінування; інакше результати — вигадки продуктивності.

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

Швидкий план діагностики (перший/другий/третій)

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

Перший: класифікуйте вузьке місце (CPU vs пам’ять vs IO vs планувальник)

• Перевірте насиченість CPU і очікування: vmstat 1 і mpstat. Якщо id низький і r високий — CPU‑bound. Якщо wa високий — найчастіше IO‑bound. Якщо одне ядро забите softirq — часто це мережа/IRQ‑affinity.
• Перевірте черги диска: iostat -xz 1. Високе await з ростом avgqu-sz означає, що сховище вшитові в шлях.
• Перевірте тиск пам’яті: grep MemAvailable /proc/meminfo і dmesg на предмет OOM/попереджень reclaim. Тиск пам’яті часто маскується під «CPU став повільнішим».

Другий: підтвердити топологію і розміщення (NUMA + пінг)

• Топологія: lscpu і numactl --hardware. Якщо у вас кілька NUMA‑вузлів — припускайте можливість віддаленої пам’яті.
• Міграції: perf stat з cpu-migrations. Високі міграції вказують на поганий affinity або обмеження cgroup, що викликають стрибки.
• Розміщення контейнерів: Перевірте cpuset і політику пам’яті, якщо ви використовуєте Kubernetes або systemd‑слайси. Не здогадуйтеся — інспектуйте.

Третій: перевірте «тихих вбивць» (прошивка, тротлінг, пом’якшення)

• Тротлінг: логи ядра на предмет теплових подій. Виправте охолодження і ліміти потужності перед тюнінгом.
• Дрейф прошивки: версії ядра + мікрокод. Змішаний BIOS‑флот робить продуктивність непередбачуваною.
• Міри та параметри ядра: Якщо нещодавнє оновлення змінило продуктивність, порівняйте boot‑параметри і базлайни мікрокоду. Не відключайте пом’якшення легковажно; виміряйте вплив і залучіть безпеку до рішення.

Правило: Не тюніть те, що не виміряли. Не вимірюйте те, що не можете відтворити. Не відтворюйте на системі, яку не можете описати.

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

Ось місця, де «Ryzen здався раптовим» кусав команди: вони застосовують стару ментальну модель на новій платформі.

1) Симптом: джитер p99 після міграції на Ryzen/EPYC

Корінна причина: віддалені NUMA‑доступи до пам’яті через розміщення планувальника і поведінку аллокатора між вузлами/чіплетами.

Виправлення: Прив’язуйте процеси/поди по NUMA‑вузлах; використовуйте cpusets; перевіряйте numastat і perf; налаштуйте або відключіть авто NUMA balancing, якщо він додає джитер.

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

Корінна причина: Одне ядро насичене softirq/IRQ‑обробкою; погані налаштування черг NIC/affinity; однопотокова гаряча точка.

Виправлення: Перевірте mpstat на домінування softirq; розподіліть IRQ по ядрах/NUMA; збільшіть кількість черг NIC; виправте гарячу точку або розпаралельте цю ділянку.

3) Симптом: бенчмарки чудові, але продакшн нестабільний (рідкі перезавантаження/MCE)

Корінна причина: Надмірне тюнінгування пам’яті/fabric без достатнього термального витримування і валідації для змішаних навантажень.

Виправлення: Відкотитися до JEDEC‑стабільних профілів; валідувати тривалими стрес‑тестами; моніторити EDAC виправлені помилки; замінювати маргінальні DIMM.

4) Симптом: «той самий SKU», різна продуктивність на хостах

Корінна причина: Дрейф прошивки (BIOS/мікрокод), різне заповнення DIMM, різні ліміти потужності або термічні відмінності.

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

5) Симптом: частота CPU не піднімається, сервіс відчуває лаг під спалахами

Корінна причина: Консервативний governor, глибокі C‑стани або політика живлення, зорієнтована на ефективність замість латентності.

Виправлення: Розгляньте зміну governor; обмежте глибокі C‑стани; виміряйте вплив на хвостову латентність до/після.

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

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

Виправлення: Профілюйте: вимірюйте cache misses, run queue, IO wait; шардуйте роботу; зменшуйте контенцію блокувань; покращуйте локальність; масштабируйте фактичний вузький елемент (канали пам’яті, NVMe, мережа).

7) Симптом: збільшення відставання реплікації бази даних на нових хостах

Корінна причина: Змішане NUMA‑розміщення, поведінка THP або чергування зберігання під іншим IO‑патерном.

Виправлення: Прив’язуйте процеси БД; встановіть THP політику, доречну для БД; налаштуйте IO‑планувальник і глибини черг; перевірте за допомогою iostat і метрик БД.

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

Це операційні кроки, що перетворюють «Ryzen виглядає чудово на папері» в «Ryzen поводиться в продакшні». Вони навмисно не романтичні.

Чекліст 1: Перед покупкою і вибором платформи (не купуйте сюрпризи)

1. Виберіть 2–3 репрезентативні навантаження (латентний API, пакетна аналітика, робота, інтенсивна по зберіганню).
2. Визначте критерії успіху в продукційних термінах: p99, пропускна здатність на ват, вартість одиниці роботи, вплив на бюджет помилок.
3. Вимагайте BOM апаратного забезпечення, що включає точну модель DIMM і план заповнення слотів; уникайте «еквівалентних» частин, якщо не протестовано.
4. Вирішіть, чи ваше навантаження залежить від NUMA. Якщо так — закладіть час інженерів для affinity і розміщення.
5. Підтвердьте, що вибір NIC і сховища узгоджується з NUMA‑топологією (наприклад, NIC на тому ж вузлі, що й найгарячіші ядра).

Чекліст 2: Bring‑up і базлайн (зробіть хости порівнюваними)

1. Встановіть затверджену версію BIOS і застосуйте її до кожного хоста перед бенчмарком.
2. Зафіксуйте версію ядра і пакет мікрокоду; документуйте їх як API‑контракт.
3. Запишіть виходи lscpu і numactl --hardware для кожного класу обладнання.
4. Перевірте швидкість пам’яті і здоров’я ECC (dmidecode + edac).
5. Запустіть burn‑in, що включає CPU, тиск пам’яті, IO і термічне витримування; зберігайте логи.

Чекліст 3: Стратегія розгортання (уникайте «загального загадкового регресу»)

1. Canary: розгорніть на невеликому відсотку трафіку і тримайте довше, щоб побачити добові патерни.
2. Порівнюйте однакове з однаковим: та сама версія софту, те саме ядро, той самий BIOS, та сама політика живлення.
3. Спостерігайте p99/p999 і рівень помилок, а не середню латентність. Середнє — місце, куди йдуть інциденти ховатися.
4. Перевіряйте IRQ і CPU affinity для мережево‑важких навантажень; слідкуйте за «гарячими» ядрами softirq.
5. Автоматизуйте виявлення дрейфу BIOS/мікрокоду/ядра; розглядайте дрейф як передвісник інциденту.

Чекліст 4: NUMA‑свідома конфігурація (якщо вам потрібна хвостова латентність)

1. Прив’язуйте основні процеси сервісу до NUMA‑вузла (або набору ядер) і тримайте пам’ять локально.
2. Ко‑розміщайте найгарячіші переривання і найгарячіші потоки там, де можливо (той самий вузол).
3. Тестуйте з автоматичним NUMA balancing і без нього на canary; обирайте за стабільністю p99.
4. Документуйте політику, щоб майбутні інженери не «прибрали» її під час рефакторингу.

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

1) Чи «раптово» Ryzen обігнав Intel?

Ні. Це був багатопоколінний підйом: Zen встановив конкуренцію, Zen 2 покращив ефективність і масштабування, Zen 3 покращив поведінку для чутливих до затримок навантажень. Сприйняття ринку відставало від виконання.

2) Чому чіплети важливі для реальних розгортань?

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

3) Чи лише для багатопотокових навантажень підходить Ryzen?

Він блищить у роботах, орієнтованих на пропускну здатність, але сучасні ядра Zen також сильні на потік. Більше питання — чи ваше навантаження обмежене затримкою пам’яті, пропускною здатністю або IO.

4) Чому мої бенчмарки розходяться між схожими на вигляд серверами?

«Схожі на вигляд» часто не означає ідентичні: версії BIOS, мікрокод, заповнення DIMM, ліміти потужності і терміка відрізняються. Поставте платформу на базлайн перед тим, як вірити результатам.

5) Чи слід відключити міри безпеки, щоб повернути продуктивність?

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

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

Перевірте lscpu / numactl --hardware на наявність кількох вузлів, потім шукайте високі міграції (perf stat) і джитер p99 під навантаженням. Якщо пінгування покращує хвостову латентність — NUMA був частиною податку.

7) Чи допомагають «профілі продуктивності» BIOS?

Іноді. Вони також можуть шкодити через терміку, нестабільність або джитер від агресивного бусту. Розглядайте налаштування BIOS як поетапний реліз з burn‑in і планом відкату.

8) Чи EPYC — це просто «Ryzen для серверів»?

Вони мають спільну архітектурну ДНК, але серверні частини робочі орієнтовані на канали пам’яті, IO, функції надійності і валідацію платформи. Операційні наслідки (NUMA, розкладка PCIe, дисципліна прошивки) більш виражені.

9) Як планувати ємність при переході на Ryzen/EPYC?

Почніть з характеристики навантаження: CPU‑bound vs memory‑bound vs IO‑bound. Потім бенчмаркуйте на базлайновій платформі і будуйте цілі по запасу використовуючи p99, а не середні значення.

10) Яка найпоширеніша операційна помилка під час міграції?

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

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

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

Якщо ви оперуєте продакшном, мораль не в «купуйте Ryzen». Мораль — не переносити вчорашні припущення в сьогоднішню топологію.

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

1. Зафіксуйте базлайн платформи: виберіть BIOS, мікрокод, версії ядра; забезпечте їхнє дотримання.
2. Запустіть виявлення топології на кожному класі обладнання: зафіксуйте lscpu і numactl; задокументуйте NUMA‑макет для інженерів.
3. Зберіть мінімальний набір бенчмарків: один тест латентності, один тест пропускної здатності, один змішаний IO‑тест; запускайте на canary після кожної зміни прошивки/ядра.
4. Визначте, чи вам важлива хвостова латентність: якщо так — впровадьте affinity і NUMA‑політики; якщо ні — не витрачайте час на мікрооптимізації.
5. Слідкуйте за тими, хто тихо вбиває продуктивність: тротлінг, ECC‑виправлені помилки, «гарячі» ядра IRQ і дрейф прошивки.

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