AMD Opteron: як сервери відкрили VIP‑двері для AMD

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

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

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

Opteron переміг не тому, що він був милий. Він переміг тому, що змусив систему поводитися прогнозовано: затримки пам’яті зменшилися, масштабування
в багатосокетних системах перестало бути науковим проєктом, а 64‑бітний режим з’явився без необхідності підривати весь стек програмного забезпечення.

VIP‑двері: чому сервери — єдина кімната, яка має значення

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

На початку 2000‑х Intel диктував порядок у серверах. «Xeon» означав безпеку. «Itanium» позиціювали як майбутнє. AMD був напористою альтернативою —
часто відмінною, іноді проігнорованою, рідко запрошуваною до великого столу. Opteron змінив соціальну геометрію.

Суть у тому, що Opteron не намагався лише переграти Intel у чистій швидкості CPU. Він атакував системну продуктивність там, де справжні робочі навантаження
страждають: пропускна здатність пам’яті, затримки пам’яті, узгодженість у багатосокетних системах і сумісність оновлень. Результат був не просто «швидший».
Результат — менше огидних сюрпризів о 2‑й ночі.

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

Opteron запущено у 2003 році, і він приніс x86‑64 (AMD64) у сервери, зберігаючи роботу 32‑бітного ПЗ.
Intel спочатку поставив на Itanium (EPIC/IA‑64) як на шлях для 64‑бітного корпоративного обчислення, очікуючи, що x86 зникне з високих серверів.
Інтегрований контролер пам’яті від AMD перемістив доступ до пам’яті з північного мосту, зменшивши затримки і підвищивши пропускну здатність у реальних навантаженнях.
HyperTransport замінив стару модель front‑side bus у зв’язках CPU‑to‑CPU і CPU‑to‑chipset, допомігши масштабуванню в багатосокетних системах.
Дистрибутиви Linux рано прийняли AMD64, і це мало значення: команди ops могли тестувати й розгортати без очікування на закриті екосистеми.
Великі OEMи випускали сервери на Opteron — сигнал для закупівель, що «це не шкільний проєкт».
Віртуалізація отримала практичний майданчик: навіть до成熟ня апаратних розширень для віртуалізації, AMD64 спростив роботу з адресним простором і консолідацією.
NUMA перестала бути теоретичною: багатосокетні x86‑сервери стали явно NUMA, і програмному забезпеченню довелося з цим рахуватися.
Intel пізніше прийняв ту саму 64‑бітну модель (Intel 64/EM64T), що підтвердило стратегію AMD: розвивати x86, а не замінювати його.

Що технічно змінив Opteron — і чому це було важливо для операторів

1) Інтегрований контролер пам’яті: менше брехні між вами і RAM

У старому світі спільного front‑side bus (FSB) процесори були як сусіди, що ділять один вузький коридор до кухні. Усі могли готувати.
Просто не одночасно. Opteron помістив кухню всередину кожного пакету CPU, інтегрувавши контролер пам’яті. Кожний сокет отримав свій прямий шлях до ОЗП.

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

Менші затримки пам’яті під навантаженням — менше дивних хвостових затримок у базах даних і JVM‑робочих навантаженнях.
Більш передбачуване масштабування при додаванні сокетів, бо пропускна здатність пам’яті зростала більш лінійно (з зауваженнями, оскільки NUMA).
Краще «реальне» виконання у навантаженнях, які виглядають скромно за завантаженням CPU, але насправді обмежені пам’яттю.

Інтегрований контролер пам’яті також вимагав культурної зміни: вже не можна було вдавати, що пам’ять «однорідна». Якщо потік на сокеті 0 б’є по пам’яті,
прив’язаній до сокета 1, це не «просто RAM». Це штраф віддаленого доступу, і він проявляється як затримка.

2) HyperTransport: масштабування без молитви

HyperTransport дав Opteron високо‑швидкісний точка‑до‑точки інтерконект. Замість того, щоб усі CPU боролися за один спільний шинний канал,
сокети могли спілкуватися більш безпосередньо, а трафік узгодженості мав куди йти, окрім «голосного крику по FSB».

Це мало значення для двох класичних корпоративних проблем:

Масштабування в багатосокетних системах без миттєвого удару об стіну спільної шини.
I/O‑шляхи, які не падали під змішаними навантаженнями (мережа + сховище + тиск пам’яті) так швидко, як у попередніх дизайнів.

3) x86‑64 як стратегія сумісності, а не тест чистоти

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

Це не маркетинговий преферанс. Це операційна математика. Підприємства не оновлюють просто натисканням кнопки. Вони роблять пілоти, валідацію,
міграцію і тримають плани відкату. AMD64 відповідав цій реальності.

4) NUMA стає податком, який треба сплатити

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

Якщо ви засвоїли одну звичку від Opteron, то це має бути ця: завжди питайте «Де знаходиться пам’ять щодо CPU, який виконує роботу?»

AMD64 проти Itanium: роздоріжжя

Itanium був шляхом «нової архітектури»: чистий розрив, велика обіцянка і велика вимога — портувати ваше ПЗ. AMD64 був шляхом «рухаймося далі»:
розширити x86, зберегти сумісність, добратися до 64‑біт без підриву екосистеми.

Якщо ви керуєте продукційними системами, ви знаєте, як ця історія закінчується. Платформа, яка просить мінімум перезапису, виграє, за умови, що продуктивність
достатня і інструменти не катастрофічні. AMD64 потрапив у цю «солодку точку».

Тут є й аспект надійності. Нові архітектури вводять нові поведінки компіляторів, нові крайові випадки бібліотек, нові різкі падіння продуктивності
і нові «це працювало на старій платформі» баги. Частина цього неминуча. Але масштабування цього по всьому флоту — це як створити кар’єру в incident response.

Один жарт, бо ми це заслужили: Itanium був тим «майбутнім», яке завжди прибувало відразу після наступного вікна обслуговування.

NUMA: функція, яка оплачувала рахунки і викликала суперечки

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

Opteron зробив NUMA мейнстримом у x86‑серверних кімнатах. Він змусив розробників і операторів серйозно ставитися до affinity: прив’язки CPU,
політики розподілу пам’яті, розміщення IRQ і розподілу переривань.

Фокус не в тому, щоб «налаштувати все». Фокус у тому, щоб налаштувати одну‑дві речі, які реально вас обмежують: локальність пам’яті, I/O‑переривання
і поведінку планувальника під конкуренцією.

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

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

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

Середнє підприємство експлуатувало латентно‑чутливу білінгову систему на двосокетних серверах. Команда мігрувала з старішої платформи Xeon на машини на Opteron,
бо співвідношення ціна/продуктивність виглядало фантастично, і вендор обіцяв «легке підключення».

Міграція пройшла гладко до закриття місяця. Раптом затримки API подвоїлися, а база даних почала логувати періодичні стаки. Завантаження CPU трималося близько 40–50%.
Графіки сховища виглядали спокійними. Усі звинуватили додаток.

Хибне припущення: «Пам’ять — це пам’ять; якщо її достатньо, не має значення, де вона живе». На Opteron це абсолютно мало значення.
Процес БД мав потоки, що стрибали між сокетами, тоді як його найгарячіші сторінки пам’яті були виділені здебільшого на одному вузлі. Трафік віддаленого доступу
до пам’яті зріс, затримка підвищилася, і навантаження впало в поганий зворотний цикл: повільніші запити довше тримали блокування, збільшуючи конкуренцію,
що збільшувало ping‑pong кеш‑ліній.

Виправлення не було екзотичним. Вони закріпили робітничі потоки БД до ядер, забезпечили NUMA‑усвідомлене виділення пам’яті (або хоча б інтерлевінг для цього навантаження),
і перемістили NIC IRQ з зайнятого вузла. Затримка повернулася до норми, і «регресія додатка» зникла, ніби її ніколи не було.

Урок: Для NUMA «достатньо пам’яті» ≠ «швидка пам’ять». Розглядайте локальність як метрику першого порядку.

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

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

Спочатку графіки виглядали чудово. Менші затримки. Вища пропускна здатність. Відзначали перемогу. Потім прийшло літо, разом із серією подій термального троттлінгу
і відмов вентиляторів. Бюджет охолодження дата‑центру не був безмежним, і стійки вже були щільні.

Під тривалим нагрівом деякі вузли почали непередбачувано знижувати тактову частоту. Ця непередбачуваність важила більше за середній приріст продуктивності.
Планувальник віртуалізації ганяв навантаження по вузлах, VМи мігрували в невідповідні моменти, і кластер отримав нову особистість: іноді швидкий, часто дратівливий.

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

Урок: оптимізація, що ігнорує енергетику й тепло, — це технічний борг із кривою вентилятора.

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

Команда фінансових послуг експлуатувала сервери Opteron роками. Нічого гламурного. Переважно бази даних і черги повідомлень. Їхньою секретною зброєю не був
екзотичний патч ядра чи героїчне налаштування. Це була дисциплінована базова лінія.

Щокварталу вони робили «відомо‑добрий» сніпет телеметрії обладнання та ОС: розклад NUMA, розподіл IRQ, пропускну здатність пам’яті під стандартним тестом,
затримку сховища під контрольованим навантаженням і профіль продуктивності топ‑сервісів. Вони зберігали це з такою ж відповідальністю, як бекапи.

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

Виправлення було простим: налаштувати параметри прошивки для відновлення старої поведінки і валідувати тими ж базовими тестами. Жодного інциденту.
Жодної воєнної кімнати. Просто нудний тикет і чистий журнал змін.

Урок: нудні практики перемагають захоплюючі героїчні дії. Базові лінії перетворюють «таємничі регресії» на «відомі дельти».

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

Це порядок, який я використовую, коли сервер «виглядає повільним» і звинувачення передаються, як гарячий картопля. План налаштований під реалії епохи Opteron
(NUMA, контролери пам’яті на сокет, багатосокетне масштабування), але він і досі застосовний до сучасних систем.

По‑перше: підтвердьте, який саме тип уповільнення у вас

Стрибок затримки? Шукайте затримки планування, віддалену пам’ять, конкуренцію за блокування, бурі IRQ.
Зниження пропускної здатності? Шукайте насичення пропускної здатності пам’яті, глибину черг I/O, троттлінг або «гаряче» одне ядро.
Тільки під конкуренцією? Підозрюйте розміщення NUMA, bounce кеш‑ліній або конкуренцію за спільні ресурси.

По‑друге: CPU vs пам’ять vs I/O за 10 хвилин

Тиск планування CPU: запустіть vmstat 1 і перевірте run queue, context switches та steal time.
Локальність пам’яті: перевірте статистику NUMA за допомогою numastat і розклад CPU/вузлів за допомогою lscpu.
Час очікування I/O і затримки: запустіть iostat -x 1 і подивіться на await, svctm (якщо є) і завантаження.
Мережа: перевірте втрачені пакети і переповнення за допомогою ip -s link і розподіл переривань.

По‑третє: валідуйте «очевидний» графік інструментом істини

Счетчики продуктивності: perf stat і perf top для CPI, промахів кешу і «гарячих» функцій.
Погляд ядра: pidstat, sar, dmesg на предмет троттлінгу і скарг драйверів.
Розміщення: taskset, numactl, /proc/interrupts, щоб побачити, чи ви випадково не створили міжсокетний податок.

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

Це перевірки, які я дійсно запускаю. Кожне завдання містить: запускаємий командний рядок, приклад виводу, що це означає і яке рішення слідує.
Припустіть Linux на bare metal або VM з достатньою видимістю.

Завдання 1: Визначити модель CPU і топологію ядер

cr0x@server:~$ lscpu
Architecture:        x86_64
CPU(s):              16
Thread(s) per core:  1
Core(s) per socket:  8
Socket(s):           2
NUMA node(s):        2
Vendor ID:           AuthenticAMD
Model name:          AMD Opteron(tm) Processor 285
NUMA node0 CPU(s):   0-7
NUMA node1 CPU(s):   8-15

Значення: Два сокети, два NUMA‑вузли. Будь‑яке «випадкове» планування може створити віддалений доступ до пам’яті.

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

Завдання 2: Підтвердити відстані NUMA (наскільки дорого «віддалено»)

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

Значення: Доступ до віддаленого вузла коштує ≈2× відносної відстані. Це не тонкість.

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

Завдання 3: Перевірити, чи ядро використовує NUMA balancing (і чи варто вам хвилюватися)

cr0x@server:~$ sysctl kernel.numa_balancing
kernel.numa_balancing = 1

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

Рішення: Для стабільних баз даних тестуйте вкл/викл у стейджингу. Якщо бачите міграції і джиттер — розгляньте відключення і застосування pinning.

Завдання 4: Виявити тиск черги виконання і активність swap швидко

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 122100  81200 945000    0    0     1     5  310  540 18  4 76  2  0
 8  0      0 121880  81200 945120    0    0     0     0  900 1800 55 10 33  2  0
 9  0      0 121700  81200 945200    0    0     0    16  920 1900 58 12 28  2  0
 3  1      0 121500  81200 945210    0    0   120     0  600 1200 20  6 68  6  0
 2  0      0 121480  81200 945240    0    0     0     0  330  560 16  4 78  2  0

Значення: Стовпець r іноді підскакує (8–9) — означає, що runnable‑задач більше, ніж CPU може обробити. wa низький, swap = 0.

Рішення: Це тиск планування CPU, а не диск. Дослідіть «гарячі» потоки, affinity або конкуренцію за блокування.

Завдання 5: Визначити, чи ви CPU‑bound або memory‑bound (швидко і грубо)

cr0x@server:~$ perf stat -a -- sleep 5
 Performance counter stats for 'system wide':

       18,245.12 msec task-clock                #    3.649 CPUs utilized
   12,345,678,901      cycles                    #    0.677 GHz
    9,876,543,210      instructions              #    0.80  insn per cycle
    1,234,567,890      cache-references
      456,789,012      cache-misses              #   36.99% of all cache refs

       5.001234567 seconds time elapsed

Значення: IPC ≈ 0.8 і високий відсоток промахів кешу вказують на стагнацію — часто це латентність/пропускна здатність пам’яті, а не чистий обчислювальний брак.

Рішення: Перевірте NUMA‑локальність і тиск на пропускну здатність пам’яті перед тим, як купувати «ще CPU».

Завдання 6: Перевірити віддалені vs локальні виділення пам’яті по процесу (реальність NUMA)

cr0x@server:~$ numastat -p 1234
Per-node process memory usage (in MBs) for PID 1234 (postgres)
         Node 0  Node 1   Total
Private    8200     900    9100
Heap        600    4200    4800
Stack        20      18      38
Huge         0       0       0
Total     8820    5118   13938

Значення: Пам’ять розподілена нерівномірно; якщо CPU‑потоки в основному на вузлі 0, а heap важкий на вузлі 1, очікуйте віддалені штрафи.

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

Завдання 7: Переглянути affinity CPU процесу (чи даєте ви планувальнику вільно користуватися ресурсами?)

cr0x@server:~$ taskset -pc 1234
pid 1234's current affinity list: 0-15

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

Рішення: Для сервісів з хвостовою затримкою обмежте їх одним NUMA‑вузлом (наприклад, CPU 0–7) і тримайте пам’ять локально.

Завдання 8: Перевірити затримки пристроїв зберігання і поведінку черг

cr0x@server:~$ iostat -x 1 3
Device            r/s     w/s   rkB/s   wkB/s  await  svctm  %util
sda              45.0    12.0   820.0   140.0   4.20   0.90  52.0
md0               0.0     0.0     0.0     0.0   0.00   0.00   0.0
nvme0n1         500.0   300.0 64000.0 32000.0   0.45   0.10  78.0

Значення: await — це затримка, яку бачить запит. Високе %util разом із зростанням await вказує на насичення.

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

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

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

12:00:01 PM   UID       PID   kB_rd/s   kB_wr/s kB_ccwr/s iodelay  Command
12:00:02 PM  1001      1234      0.00   4200.00      0.00      18  postgres
12:00:03 PM  1001      1234      0.00   3900.00      0.00      22  postgres
12:00:04 PM  1001      1234      0.00   4100.00      0.00      20  postgres

Значення: Зростання iodelay вказує на час, заблокований на I/O (облік ядра). Це явний доказ, коли CPU виглядає простим.

Рішення: Дослідіть write amplification, частоту fsync, кешування RAID або насичення бекенду сховища.

Завдання 10: Перевірити мережеві втрачені пакети і помилки (бо «CPU нормальний» може бути все ще мережею)

cr0x@server:~$ ip -s link show dev eth0
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP mode DEFAULT group default qlen 1000
    link/ether 00:11:22:33:44:55 brd ff:ff:ff:ff:ff:ff
    RX:  bytes packets errors dropped  missed   mcast
      987654321  1234567      0     842       0       0
    TX:  bytes packets errors dropped carrier collsns
      876543210  1122334      0       9       0       0

Значення: RX‑втрати (842) — це не «косметика». Вони можуть викликати ретрансмісії і стрибки затримки.

Рішення: Перевірте розміри ring buffer, affinity переривань і перевантаження; розгляньте налаштування RSS, відповідні для вашого NIC.

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

cr0x@server:~$ cat /proc/interrupts | head -n 12
           CPU0       CPU1       CPU2       CPU3       CPU4       CPU5       CPU6       CPU7
  24:   9876543          0          0          0          0          0          0          0  IO-APIC   24-fasteoi   eth0
  25:      1200       1100       1150       1080       1120       1090       1110       1070  IO-APIC   25-fasteoi   nvme0q0
NMI:        120        118        121        119        117        120        122        118  Non-maskable interrupts

Значення: Переривання eth0 прив’язані тільки до CPU0. Це може створити пляшкове горло для мережі і відбирати цикли не з того місця.

Рішення: Перерозподіліть IRQ (irqbalance або ручний smp_affinity) і тримайте мережеві переривання на тому ж NUMA‑вузлі, що й навантаження.

Завдання 12: Виявити троттлінг частоти CPU / термальні проблеми

cr0x@server:~$ dmesg -T | egrep -i "thrott|thermal|clock"
[Thu Jan  9 11:58:12 2026] CPU0: Core temperature above threshold, cpu clock throttled
[Thu Jan  9 11:58:15 2026] CPU0: Core temperature/speed normal

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

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

Завдання 13: Підтвердити використання huge pages (добрий слуга, але поганий пан)

cr0x@server:~$ grep -i huge /proc/meminfo
AnonHugePages:    1048576 kB
HugePages_Total:     2048
HugePages_Free:       512
HugePages_Rsvd:       128
Hugepagesize:       2048 kB

Значення: Huge pages використовуються. Це може покращити поведінку TLB, але ускладнити розподіл пам’яті і NUMA‑розміщення.

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

Завдання 14: Перевірити тиск на пропускну здатність пам’яті (практичний проксі)

cr0x@server:~$ sar -B 1 3
Linux 5.15.0 (server)  01/09/2026  _x86_64_  (16 CPU)

12:01:01 PM  pgpgin/s pgpgout/s   fault/s  majflt/s  pgfree/s pgscank/s pgscand/s pgsteal/s    %vmeff
12:01:02 PM      0.00    850.00  22000.00      0.00  48000.00      0.00      0.00      0.00      0.00
12:01:03 PM      0.00    920.00  24000.00      0.00  49000.00      0.00      0.00      0.00      0.00
12:01:04 PM      0.00    870.00  23000.00      0.00  47500.00      0.00      0.00      0.00      0.00

Значення: Багато дрібних page faults з відсутністю великих підказує на чищення пам’яті, але не обов’язково сторінковування на диск. Це може корелювати з тиском на пропускну здатність пам’яті.

Рішення: Якщо затримка корелює з піками тут, профілюйте виділення, зменшіть churn і перевірте NUMA‑локальність — особливо для JVM і кешів БД.

Другий жарт, бо нам усім потрібен: NUMA — як офісна розсадка: посадіть команду біля маркерної дошки, або насолоджуйтесь довгими нарадами про «затримку комунікації».

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

1) Симптом: CPU «не високий», але затримка жахлива

Корінна причина: Затримки пам’яті (віддалений NUMA‑доступ, промахи кешу) або конкуренція за блокування; завищення CPU вводить в оману.

Виправлення: Використайте perf stat для IPC/промахів, numastat для локальності, потім закріпіть потоки і застосуйте NUMA‑політики пам’яті.

2) Симптом: Додавання другого сокета не покращило пропускну здатність

Корінна причина: Навантаження однопотокове, сериалізовано блокуванням або обмежене пропускною здатністю пам’яті одного NUMA‑вузла.

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

3) Симптом: Пропускна здатність мережі нижча за швидкість лінка і з’являються втрати

Корінна причина: Переривання прив’язані до одного ядра, погана конфігурація RSS або драйверні дефолти, непридатні для високого PPS.

Виправлення: Розподіліть IRQ по ядрах на правильному NUMA‑вузлі; валідуйте за допомогою /proc/interrupts і лічильників втрат.

4) Симптом: Спайки затримки сховища під час «CPU‑важких» робіт

Корінна причина: Переривання завершення I/O і конкуренція ksoftirqd; шлях зберігання змагається з обчисленням на тих самих ядрах.

Виправлення: Виділіть окремі ядра для IRQ; ізолюйте CPU для рівнів затримки; підтвердіть за допомогою pidstat -d і iostat -x.

5) Симптом: Випадкові уповільнення після змін прошивки/BIOS

Корінна причина: Зміни в інтерлевінгу пам’яті, C‑станах або політиці живлення; NUMA‑поведінка зсунулася непомітно.

Виправлення: Порівняйте базові лінії (відстані NUMA, тести пропускної здатності пам’яті, лічильники perf). Відкотіть або стандартизуйте налаштування по флоту.

6) Симптом: Хост віртуалізації нестабільний, VМи «занадто часто» мігрують

Корінна причина: Overcommit + розміщення без урахування NUMA; VМи охоплюють вузли і несуть штраф віддаленого доступу до пам’яті.

Виправлення: Тримайте vCPU і пам’ять VM в межах одного вузла, коли можливо; використовуйте пулі по NUMA‑вузлах; перевіряйте метрики хоста і гостя.

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

Чек‑ліст A: При купівлі або успадкуванні серверів епохи Opteron (або будь‑якої NUMA‑машини)

Підтвердьте сокети/NUMA‑вузли за допомогою lscpu і numactl --hardware.
Уніфікуйте налаштування BIOS: політика інтерлевінгу пам’яті, політика живлення, налаштування віртуалізації і опції інтерконекту між вузлами.
Встановіть базову лінію: perf stat у спокої і під контрольованим навантаженням, плюс iostat -x і ip -s link.
Задокументуйте розподіл IRQ на відомому‑доброму хості (знімок /proc/interrupts).
Оберіть стратегію NUMA для кожного навантаження: «pin per socket», «interleave memory» або «дозвольте balancing» (тільки після тестування).

Чек‑ліст B: Коли сервіс уповільнився після міграції на нове обладнання

Підтвердьте тактові частоти/троттлінг за допомогою dmesg і інструментів частоти CPU (якщо є).
Перевірте run queue і I/O wait: vmstat 1, потім iostat -x 1.
Валідуйте NUMA‑локальність: numastat -p для процесу і affinity CPU за допомогою taskset -pc.
Перевірте «гарячі точки IRQ»: cat /proc/interrupts, потім корелюйте з втраченими пакетами і проблемами сховища.
Тільки після цього налаштовуйте додаток — бо неправильне розміщення апаратури імітує регресію програмного забезпечення дуже правдоподібно.

Чек‑ліст C: Розумний план налаштування (не налаштовуйте себе у глухий кут)

Виміряйте: захопіть 10 хвилин vmstat, iostat і perf stat навколо проблеми.
Робіть по одній зміні за раз (pinning, affinity IRQ, політика пам’яті) і повторно вимірюйте.
Віддавайте перевагу оборотним змінам (systemd overrides, обгортки сервісів) замість «мішаного sysctl‑супу».
Запишіть мотивацію. Майбутній ви — інша людина з меншою терплячістю.

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

1) Чи була головна перевага Opteron лише в «64‑бітах»?

Ні. 64‑біт мало значення, але системний дизайн Opteron — інтегрований контролер пам’яті і кращий багатосокетний інтерконект — дав відчутну
продуктивність і передбачуваність для реальних робочих навантажень.

2) Чому інтегровані контролери пам’яті так змінили серверну продуктивність?

Вони зменшили затримки пам’яті і прибрали спільне вузьке місце (northbridge/FSB). Для баз даних, проміжного ПЗ і хостів віртуалізації
поведінка пам’яті часто домінує у сприйманій продуктивності.

3) Який найпоширеніший режим відмов епохи Opteron серед операційників?

Ігнорування NUMA: навантаження працює на одному сокеті, а пам’ять виділена на іншому — що дає віддалені штрафи доступу і джиттер, що виглядає
як «випадкова повільність».

4) Чи завжди слід прив’язувати процеси до NUMA‑вузла?

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

5) Як зрозуміти, що я memory‑bound без дорогих інструментів?

Шукайте низький IPC у perf stat, високі показники промахів кешу і симптоми, коли завантаження CPU не високе, але пропускна здатність не зростає.
Потім перевірте NUMA‑локальність через numastat.

6) Чому AMD64 переміг Itanium на ринку?

Через сумісність. AMD64 дозволив підприємствам перейти на 64‑біти без переписування всього. Itanium вимагав портів і вводив тертя в екосистемі.
У корпоративному світі тертя — це центр витрат.

7) Чи має це значення на сучасних CPU?

Так. Сучасні платформи все ще мають NUMA, кілька каналів пам’яті, складні інтерконекти і проблеми локальності IRQ/CPU. Назви змінилися.
Фізика — ні.

8) Яка найшвидша перевірка «CPU чи I/O»?

vmstat 1 плюс iostat -x 1. Якщо wa і await зростають — підозрюйте сховище. Якщо черга виконання підскакує і wa низький — підозрюйте планування CPU, блокування або затримки пам’яті.

9) Чи може віртуалізація приховати NUMA‑проблеми?

Вона може приховати причину, одночасно посилюючи симптоми. Якщо VM охоплює вузли, віддалений доступ до пам’яті стає «загадковим джиттером».
Віддавайте перевагу NUMA‑вирівняним розмірам і розміщенню VM.

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

Opteron відкрив VIP‑двері для AMD, вирішивши проблеми, про які оператори вже отримували зарплату: масштабування, поведінка пам’яті, сумісність
і передбачувана продуктивність під навантаженням. Урок не в ностальгії. Урок — у архітектурній грамотності: якщо ви не розумієте, де живе вузьке місце,
ви з впевненістю оптимізуватимете не ту річ.

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

На одному хості, схожому на продукційний, зафіксуйте базову лінію: lscpu, numactl --hardware, vmstat, iostat -x, ip -s link, /proc/interrupts.
Виберіть один критичний сервіс і перевірте NUMA‑локальність за допомогою numastat -p та affinity CPU з taskset.
Виправте найбільше невідповідність спочатку (зазвичай розподіл IRQ або локальність пам’яті), потім знову виміряйте. Якщо графіки не змінилися — ви не виправили вузьке місце.
Запишіть, як виглядає «добре» для цього покоління обладнання. Той день, коли воно знадобиться, буде днем, коли ви не матимете часу відтворювати це з нуля.