Безкінечна ера 14 нм у Intel: коли затримки процесу перетворилися на мильну оперу

Чому 14 нм мало значення в продукції (не лише пресрелізи)

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

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

Для оператора продукції ера 14 нм перетворилася на три повторювані проблеми:

• Прогнозованість ємності погіршилася. Ви не могли припускати, що наступне оновлення прибуде вчасно або в обсягах.
• Однорідність флоту руйнувалася. Змішані stepping-и/мікрокод/набори функцій стали нормою, а ваші базові показники продуктивності зміщувалися.
• Запобіжні заходи з безпеки нашкодили більше. Повільний перехід вузла означав більше часу з старішими мікроархітектурами та типовими накладними витратами.

Ваше завдання — не судити внутрішні виробничі проблеми Intel. Ваше завдання — будувати системи, які виживуть у реальності постачальника. Сага про 14 нм — це кейс,
чому «дорожня карта постачальника» не є SLO.

Хронологія «мильної опери»: що означало «застрягли на 14 нм»

Класичний цикл Intel раніше підсумовували як «tick-tock»: зменшення норм («tick») за яким ішла нова мікроархітектура на новому вузлі («tock»).
На практиці це еволюціонувало, напружилося й зламалося — замінено варіантами на кшталт «process-architecture-optimization». Це було не маркетингом.
Це була спроба компанії продовжувати постачати, поки виробництво наздоганяло амбіції.

Що бачив світ

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

Через що проходили оператори

На місцях «14 нм назавжди» означало:

• Ви стандартизувалися на серверному SKU — потім виявили, що замінник SKU рідкісний або коштує як викрадення.
• Ви налаштували ядро та гіпервізор під одну мікроархітектуру — потім отримали новий stepping або оновлення мікрокоду з тонально відмінною поведінкою.
• Ви будували вузли з великим обсягом зберігання, розраховуючи на запас CPU у наступному оновленні — потім CPU став обмежувачем для шифрування, стиснення, контрольних сум і мережевої роботи.

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

Незручна правда: затримки поширюються

Коли перехід вузла зсувається, це затримує не лише «наступний чіп». Це затримує:
валідацію, зрілість прошивки платформи, наявність материнських плат, контракти в ланцюгу постачання та весь конвеєр закупівель, від якого залежать підприємства.
Для SRE це перетворюється на «масштабуємо до Q3», а потім «масштабуємо до… пізніше», а потім «чи можна витиснути ще рік з цього флоту?»

Цікаві факти та історичний контекст (практичний)

Ось конкретні пункти, які варто пам’ятати, коли хтось зводить історію до «Intel провалила 10 нм».

1. 14 нм Intel увійшов у масове виробництво близько 2014 року і залишався основним вузлом обсягів роками в кількох продуктових лініях.
2. «14nm+ / ++ / +++» — це не просто маркетинг. Це відображало ітеративні оптимізації процесу та дизайну — вищі частоти, кращі виходи й інші компроміси.
3. Цілі щодо 10 нм були амбітні. Вузол мав на меті поліпшення щільності, що було складно реалізувати з прийнятними виходами.
4. Виходи придатних кристалів — бізнес-проблема до технологічної. Кристал, який працює в лабораторії, але не дає прибуткового виходу в масштабі, не є продуктом.
5. Серверні частини підсилюють біль від поганих виходів. Великі кристали означають менше чіпів з пластини та більшу чутливість до дефектів; економіка карає швидше.
6. Каденс Intel змінився на «process-architecture-optimization» як публічне визнання того, що регулярні зменшення не відбуваються за графіком.
7. Водночас з’явилися накладні витрати на безпеку (клас Spectre/Meltdown), що додало витрат продуктивності і ускладнило порівняння поколінь.
8. Зовнішні ознаки дефіциту постачання стали помітні. OEMи й підприємства повідомляли про тісну доступність певних CPU Intel, що рідко трапляється для зрілого лідера.
9. Конкуренти користувалися перевагами фаундрі. Відродження AMD опиралося на партнерства з виробництвом, що давали сильні покращення щільності й ефективності.

Практичний висновок: не будуйте план ємності, що припускає «зменшення вузла відбудеться вчасно» або «наступне покоління означає 20% кращу продуктивність на ват».
Це може статися; це не гарантія.

Одна цитата, яку варто «витатуювати» в рунбуках, приписується Вернеру Фогелсу: «Everything fails, all the time.» Це грубо, але водночас звільняє.
Будуйте так, ніби виробничі графіки теж підводять.

Що ламалося для SRE: режими відмов, що можна простежити до затримок процесу

1) Планування продуктивності стало голоснішим

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

• Більша кількість ядер в тому ж енергетичному «конверті» може означати нижчий all-core turbo під тривалим навантаженням.
• Вищі частоти можуть означати гірші теплові характеристики, більшу чутливість до тротлінгу та складніше планування енергоспоживання в стійці.
• Запобіжні заходи безпеки та зміни мікрокоду можуть створювати «регресії продуктивності, визначені програмним забезпеченням».

2) Гетерогенність флоту стала оперативним боргом

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

3) Зберігання і мережі «виглядали повільно», але CPU був вузьким місцем

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

4) Моделі витрат зміщувалися

У стабільному світі ви можете моделювати вартість за запит як функцію ціни сервера, споживання енергії та використаності. В еру 14 нм:

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

5) Надійність переплелася з мікрокодом і прошивками

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

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

Коротка історія 1: Аутедж через хибне припущення

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

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

Режим відмову прийшов тихо. Під піковим навантаженням деякі хости показували підвищену хвостову латентність у сервісі, чутливому до latency, який багато використовував системні виклики і мережевий I/O.
Команда шукала «погані NIC», «галасливих сусідів» та «регресії ядра». Вони перезавантажувалися. Змінювали кабелі. Навіть переміщували навантаження в інші стійки.
Проблема переслідувала нові хости.

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

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

Коротка історія 2: Оптимізація, що дала відкат

Аналітична платформа зі значним навантаженням на зберігання працювала під Linux з NVMe SSD і використовувала агресивне стиснення та шифрування для відповідності та скорочення витрат.
Під час періоду, коли постачання нових CPU були обмежені, вони спробували вичавити більше пропускної здатності зі старих 14 нм хостів, підвищивши рівні стиснення
і ввімкнувши додаткові перевірки цілісності на рівні застосунку.

Бенчмарки у стенді виглядали добре за середньою пропускною здатністю. Команда поступово розгортала зміни, спостерігаючи загальний MB/s та використання диска. Здавалося, виграш.
Але через тиждень кількість запитів у службу підтримки зросла: «запити таймаутяться», «інжест відстає», «дашборди застаріли».

Відкату не було в дисках. Це була насиченість CPU у сплесках, що блокувала черги надсилання IO і викликала вибух хвостової латентності. У реальній продукції потоки стиснення конкурували за CPU з мережею і файловою системою.
Система стала CPU-зв’язана, хоча всі дивились на графіки NVMe.

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

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

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

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

Оскільки правило вимагало канарі-прогон, проблему виявили до повномасштабного розгортання. Вони відкоригували налаштування BIOS, вирівняли мікрокод і повторили тест.
Лише після цього розширили розгортання. Ніяких аутеджів, ніяких «war room», ніяких повідомлень керівництву.

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

Практичні завдання: команди, виводи та рішення (12+ реальних перевірок)

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

Завдання 1: Ідентифікувати модель CPU, stepping і мікрокод

cr0x@server:~$ lscpu | egrep 'Model name|Stepping|CPU\(s\)|Thread|Core|MHz'
CPU(s):                          32
Model name:                      Intel(R) Xeon(R) CPU E5-2680 v4 @ 2.40GHz
Thread(s) per core:              2
Core(s) per socket:              14
Stepping:                        1
CPU MHz:                         2394.000

cr0x@server:~$ grep -m1 microcode /proc/cpuinfo
microcode	: 0xb00003a

Значення: «Той самий SKU» все ще може означати різний мікрокод у різних батчах; відмінності stepping-а можуть впливати на запобіжні заходи й поведінку turbo.

Рішення: Записуйте мікрокод і stepping у вашому інвентарі; вважайте відмінності новим класом продуктивності, поки не пропрофілюєте.

Завдання 2: Перевірити, які запобіжні заходи активні (і чи змінились)

cr0x@server:~$ grep . /sys/devices/system/cpu/vulnerabilities/* | head
/sys/devices/system/cpu/vulnerabilities/meltdown: Mitigation: PTI
/sys/devices/system/cpu/vulnerabilities/spectre_v1: Mitigation: usercopy/swapgs barriers and __user pointer sanitization
/sys/devices/system/cpu/vulnerabilities/spectre_v2: Mitigation: Retpolines; IBPB: conditional; IBRS_FW

Значення: Ядро + мікрокод можуть вмикати/вимикати запобіжні заходи; навантаження, що багато викликає syscall-и, відчувають вплив PTI/IBRS.

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

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

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

cr0x@server:~$ grep -H . /sys/devices/system/cpu/cpu*/cpufreq/scaling_cur_freq | head
/sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq:2394000
/sys/devices/system/cpu/cpu1/cpufreq/scaling_cur_freq:2394000

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

Рішення: Стандартизувати governor-и для вузлів, критичних до латентності; якщо енергія обмежена — явно задокументуйте компроміс.

Завдання 4: Виявити тротлінг CPU через термічні або енергетичні ліміти

cr0x@server:~$ sudo turbostat --Summary --quiet --show Busy%,Bzy_MHz,PkgWatt,PkgTmp | head -n 5
Busy%   Bzy_MHz  PkgWatt PkgTmp
62.15   2748     145.32  82
63.02   2689     148.10  84

Значення: Високий Busy% з меншим ніж очікувалося Bzy_MHz плюс високі температури вказують на тротлінг; PkgWatt близько до лімітів — на обмеження потужності.

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

Завдання 5: Швидкий огляд насиченості CPU (черга виконання і steal)

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
 8  0      0 241320  80204 912340    0    0     2    18 1820 3210 55 12 29  2  2
12  0      0 240980  80204 912520    0    0     0     0 1905 3520 63 14 19  2  2

Значення: Високий r відносно кількості CPU сигналізує про конкуренцію; st ненульовий у ВМ вказує на hypervisor steal.

Рішення: Якщо st високий, перестаньте звинувачувати гостьову ОС; вирішіть конкуренцію на хості або перемістіть VM. Якщо r високий — профілюйте CPU-гарячі місця.

Завдання 6: Знайти найгарячіші функції CPU швидко

cr0x@server:~$ sudo perf top -n --stdio | head -n 12
Samples:  12K of event 'cycles', Event count (approx.): 1054321658
Overhead  Shared Object        Symbol
  18.32%  [kernel]             [k] tcp_recvmsg
  11.47%  [kernel]             [k] copy_user_enhanced_fast_string
   7.88%  libc-2.31.so         [.] __memmove_avx_unaligned_erms
   6.10%  [kernel]             [k] aesni_intel_enc

Значення: Мережевий стек ядра, копіювання й криптографія можуть домінувати; «швидкість зберігання повільна» іноді означає «CPU зайнятий AES та memcpy».

Рішення: Якщо криптографія домінує, перевірте використання апаратного прискорення та чи відповідають вибрані шифри/стиснення вашим CPU.

Завдання 7: Підтвердити тиск пропускної здатності пам’яті проти CPU

cr0x@server:~$ sudo perf stat -a -e cycles,instructions,cache-misses -I 1000 sleep 3
#           time             counts unit events
     1.000251117    6,213,442,101      cycles
     1.000251117    8,120,334,221      instructions
     1.000251117      132,552,120      cache-misses
     2.000442308    6,190,113,992      cycles
     2.000442308    8,005,112,990      instructions
     2.000442308      140,201,300      cache-misses

Значення: Зниження інструкцій на цикл при високих cache-misses вказує на прив’язку до пам’яті; зменшення вузла могло б допомогти, але застій на 14 нм означає — треба налаштовувати ПО.

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

Завдання 8: Перевірити 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
node 0 size: 128624 MB
node 1 cpus: 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31
node 1 size: 128622 MB

cr0x@server:~$ ps -o pid,psr,comm -p 1234
  PID PSR COMMAND
 1234  27 myservice

Значення: Процес, що «стрибає» між NUMA-вузлами, може підсилювати латентність, особливо при I/O та буферах мережі.

Рішення: Якщо ефекти NUMA корелюють з хвостовою латентністю — закріпіть навантаження або налаштуйте планувальник/cgroups для збереження локальності.

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

cr0x@server:~$ iostat -x 1 3
Device            r/s     w/s   r_await   w_await  aqu-sz  %util
nvme0n1         120.0   310.0     0.45      0.62    0.22  28.10
nvme1n1         118.0   305.0     0.47      0.60    0.21  27.55

Значення: Низький await і помірне %util означає, що зберігання, ймовірно, в порядку; не «оновлюйте диски», щоб вирішити CPU-зв’язаний хост.

Рішення: Якщо await низький, а латентність додатку висока — переходьте до планування CPU, замків, мережі або GC.

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

cr0x@server:~$ mount | grep ' /data '
/dev/nvme0n1p1 on /data type xfs (rw,relatime,attr2,inode64,logbufs=8,logbsize=32k)

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

Значення: Вибір планувальника і файлової системи впливає на накладні витрати CPU; «none» на NVMe може зменшити накладні витрати, але шкодити справедливості під змішаними навантаженнями.

Рішення: Якщо хвостова латентність спайкова при конкуренції — протестуйте mq-deadline; якщо CPU щільно зайнятий, тримайте наклад мінімальним і ізолюйте шумні I/O.

Завдання 11: Перевірити тиск мережевого стека (softirqs і дропи)

cr0x@server:~$ cat /proc/softirqs | head -n 6
                    CPU0       CPU1       CPU2       CPU3
NET_RX:          1823451    1722109    1901122    1859920
NET_TX:           654321     632110     701223     689001

cr0x@server:~$ ip -s link show dev eth0 | sed -n '1,12p'
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP mode DEFAULT group default qlen 1000
    RX:  bytes  packets  errors  dropped  missed  mcast
    9812334432  11233221 0       12       0       0
    TX:  bytes  packets  errors  dropped  carrier collsns
    8821132211  10222110 0       0        0       0

Значення: Навантаження softirq може відбирати CPU в додатків; дропи — реальна проблема, а не «можливо».

Рішення: Якщо NET_RX гарячий і дропи зростають — розгляньте RSS/RPS налаштування, прив’язку IRQ або переміщення на швидші ядра для вузлів з інтенсивною мережею.

Завдання 12: Підтвердити розподіл IRQ (класичне джерело «одне ядро завантажене»)

cr0x@server:~$ grep -E 'eth0|nvme' /proc/interrupts | head
  52:   12233123          0          0          0  IR-PCI-MSI  eth0-TxRx-0
  53:          0   11899221          0          0  IR-PCI-MSI  eth0-TxRx-1
  54:          0          0   12011222          0  IR-PCI-MSI  eth0-TxRx-2
  55:          0          0          0   11999211  IR-PCI-MSI  eth0-TxRx-3

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

Рішення: Якщо розподіл нерівний — налаштуйте IRQ affinity і перевірте латентність до/після змін.

Завдання 13: Перевірити CPU-тротлінг через cgroup (Kubernetes та ін.)

cr0x@server:~$ cat /sys/fs/cgroup/cpu.stat
nr_periods 41234
nr_throttled 2211
throttled_time 183421234567

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

Рішення: Якщо тротлінг високий на критичних навантаженнях — підніміть ліміти або відрегулюйте стратегію requests/limits; не купуйте апарат, щоб виправити політику.

Завдання 14: Бенчмарк швидко і послідовно

cr0x@server:~$ sysbench cpu --cpu-max-prime=20000 run | egrep 'events per second|total time'
events per second:                        612.34
total time:                               10.0012s

Значення: Не повний робочий бенчмарк, але хороший для швидкого виявлення «ця партія повільніша» патернів.

Рішення: Якщо нова партія істотно відрізняється — карантинуйте її для глибшого тестування (мікрокод, BIOS, запобіжні заходи, turbo, ліміти потужності).

Жарт №2: Якщо вас ще не вкусив неправильний IRQ affinity, вітаю — або у вас ідеальні дефолти, або ви просто ще не придивлялися уважно.

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

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

Перший крок: доведіть, чи це планування CPU, чи очікування на I/O

1. Перевірте чергу виконання, steal і wait. Використовуйте vmstat 1 і дивіться на r, wa і st.
   Якщо r залишається високим, а wa низьким — ви CPU-загружені, а не I/O-зв’язані.
2. Перевірте iostat await/util. Якщо диски показують низький await і низьку чергу, сьогодні зберігання не є вузьким місцем.
3. Перевірте тротлінг (cgroup і апаратний). Тротлінг cgroup і тротлінг turbo/потужності виглядають як «CPU повільний».

Другий крок: визначте, що споживає цикли

1. Використайте perf top. Якщо ядро домінує (мережа, копії, крипто) — зосередьтесь на конфігурації системи й формі навантаження.
2. Перевірте softirqs і переривання. Якщо одне CPU тоне в NET_RX — ваше налаштування додатку не врятує ситуацію.
3. Перевірте стан запобіжних заходів. Якщо щось змінилося — корелюйте це з подіями розгортання (ядро, мікрокод, BIOS).

Третій крок: перевірте топологію та розміщення

1. Вирівнювання NUMA. Якщо ваші гарячі потоки та розподіли пам’яті перетинають вузли — виправте локальність і повторіть тест.
2. Функції гіпервізора й закріплення. Забезпечте однакові CPU-фічі в пулі; припиніть live-migrate latency-критичні навантаження між різними хостами.
3. Відтворюваний мікробенчмарк + реальний канарі. Якщо ви не можете відтворити в контрольованому канарі — ви вгадуєте.

Пріоритет плану: вимірюйте конкуренцію та дрейф конфігурації в першу чергу. У довгій ері 14 нм «дрейф» — це базовий стан світу.

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

1) Симптом: «Нові вузли повільніші за старі»

Корінна причина: Різні мікрокод/налаштування запобіжних заходів; ліміти turbo/потужності; BIOS за замовчуванням не вирівняні.

Виправлення: Записуйте й порівнюйте /proc/cpuinfo microcode, /sys/devices/system/cpu/vulnerabilities і turbostat. Стандартизуйте профілі BIOS; обов’язково канарі перед розгортанням.

2) Симптом: «Латентність зберігання зросла після ввімкнення шифрування»

Корінна причина: Шлях крипто став CPU-зв’язаним (AES, контрольні суми), а не диском. Припущення про запас 14 нм не виправдалися.

Виправлення: Профілюйте з perf top. Підтвердіть використання AES-NI; відкоригуйте вибір шифрів; закріпіть крипто-потоки; розгляньте офлоад тільки якщо виміряли виграш E2E.

3) Симптом: «NVMe на 30% util, але p99 аппа жахливий»

Корінна причина: Надсилання IO затримується через конкуренцію CPU; черги в просторі користувача; конкуренція за блокування; нерівномірність IRQ.

Виправлення: Перевірте чергу виконання (vmstat), переривання (/proc/interrupts) і hotspots perf. Налаштуйте IRQ affinity, ізолюйте шумних сусідів, відрегулюйте планувальник I/O за потреби.

4) Симптом: «Мережа дропає пакети тільки на певних хостах»

Корінна причина: Насичення softirq на конкретних CPU, часто через прив’язку IRQ або відмінні значення прошивки/драйвера NIC.

Виправлення: Порівняйте /proc/softirqs і ip -s link. Вирівняйте налаштування драйвера; тонко налаштуйте RSS-черги; розподіліть переривання; підтвердіть результат до/після.

5) Симптом: «Сервіс Kubernetes завантажений, але графік використання CPU виглядає нормальним»

Корінна причина: Тротлінг cgroup: контейнер обмежено і проводить час у стані throttled, а не «використовує CPU».

Виправлення: Перевірте /sys/fs/cgroup/cpu.stat. Відрегулюйте limits/requests; резервуйте CPU для latency-критичних подів; уникайте надмірного overcommit критичних вузлів.

6) Симптом: «Та сама робота, різні стійки — різна продуктивність»

Корінна причина: Обмеження потужності або термічні відмінності; різні політики живлення BIOS; різні криві вентиляторів; різна температура в приміщенні.

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

7) Симптом: «Після оновлення ядра p99 погіршився»

Корінна причина: Зміни дефолтів запобіжних заходів; зміни планувальника; зміни драйверів, що вплинули на поведінку переривань.

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

8) Симптом: «Ми купили швидші диски, але не отримали швидші пайплайни»

Корінна причина: Обмеження CPU або пропускної здатності пам’яті; пайплайн прив’язаний до послідовності; контрольні суми/стиснення домінують.

Виправлення: Виміряйте з perf stat (IPC/cache misses) і perf top. Перепроєктуйте пайплайн для пакетування, паралелізації та зменшення копіювань.

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

Чекліст закупівель і гігієни флоту (робіть це навіть якщо ненавидите зустрічі)

1. Визначте класи продуктивності. Не прикидайтеся, що існує один «тип інстансу», якщо у вас кілька stepping-ів/мікрокодів.
2. Записуйте незмінні ідентифікатори. Модель CPU, stepping, мікрокод, версія BIOS, прошивка NIC, версія ядра.
3. Вимагайте канарі-партію. Нова апаратура потрапляє в невеликий пул з репрезентативними навантаженнями щонайменше на один бізнес-цикл.
4. Вирівняйте BIOS і політику живлення. Документуйте й застосовуйте профілі (turbo, C-states, ліміти потужності) для кожного пулу.
5. Запустіть стандартний набір бенчмарків. Мікробенч (CPU/пам’ять) плюс як мінімум одне реалістичне відтворення навантаження.
6. Плануйте сценарії дефіциту. Майте хоча б один альтернативний погоджений SKU і перевірений шлях міграції.

Чекліст оперативного налаштування (коли «14 нм назавжди» зустрічає «нам потрібна більша пропускна здатність»)

1. Почніть з метрик конкуренції. черга виконання, тротлінг, softirqs, steal time.
2. Підтвердьте топологію. NUMA, розподіл IRQ і чи чутливий ваш гарячий шлях до локальності.
3. Вимірюйте хвостову латентність, а не середні значення. Оптимізації, що покращують середній показник, можуть зіпсувати p99.
4. Бюджетуйте CPU для «невидимої роботи». шифрування, стиснення, контрольні суми, контекстні переключення, обробка пакетів.
5. Уникайте дрейфу конфігурацій. Один вузол з іншим governor-ом може створити постійний інцидент, який виглядає як «рандомний джиттер».
6. Розгортайте зміни з kill switch. Запобіжні заходи, мікрокод і оновлення BIOS мають бути зворотними операційно.

План міграції: якщо ви все ще експлуатуєте великий флот 14 нм

1. Сегментуйте навантаження за чутливістю. latency-критичні, пропускні, пакетні, зберігання-важкі, крипто-важкі.
2. Виберіть бенчмарк для кожного класу. Один на клас краще, ніж «ми раз запускали загальний CPU-тест».
3. Встановіть критерії прийняття. p99, рівень помилок і вартість за запит. Не просто «виглядає нормально».
4. Побудуйте фазове розгортання. канарі → 10% → 50% → повне із автоматичними тригерами відкату.
5. Відмовтесь від припущень. Оновіть рунбуки, що покладаються на «наступне покоління буде економічніше». Ставте ефективність вимірюваною властивістю.

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

1) Чи була ера 14 нм у Intel «поганою», чи просто довгою?

Технічно 14 нм дав багато відмінних чіпів. Операційно — він був достатньо довгим, щоб зламати припущення планування. «Поганий» — невірна ярличок; краще підходить «дестабілізуючий».

2) Чому затримки процесу важливі для SRE?

Бо затримки виражаються як обмеження постачання, волатильність цін, гетерогенність флоту і повільні поліпшення perf-per-watt. Це перетворюється на пейджінг, а не на балачки експертів.

3) Якщо моє навантаження I/O-зв’язане, чи варто хвилюватися про зупинки CPU?

Так. I/O-стеки споживають CPU: переривання, копіювання, контрольні суми, шифрування, метадані й управління чергами. Багато «I/O-зв’язаних» систем насправді «обмежені CPU на межі I/O».

4) Як зрозуміти, чи повільне сховище, чи CPU не може його розкрутити?

Перевірте iostat -x на await/%util і порівняйте з чергою виконання і hotspots perf. Низький disk await при високій конкуренції CPU сильно вказує на CPU-ліміт.

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

Іноді. Навантаження, що багато викликають syscall-и, переключення контекстів або віртуалізацію, можуть відчувати накладні витрати запобіжних заходів. Ключ — кореляція: чи змінився мікрокод/ядро?

6) Чи варто стандартизувати мікрокод у флоті?

Стандартизуйте там, де можете, але будьте реалістичні: постачальники відвантажують різні базові версії. Щонайменше записуйте їх і уникайте змішування рівнів мікрокоду в одному latency-критичному пулі.

7) Яка найбільша помилка планування з ери 14 нм?

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

8) Чи означає це «завжди купувати новіший вузол»?

Ні. Купуйте те, що відповідає вашим SLO з прийнятним ризиком. Нові вузли можуть приносити баги раннього життя в прошивці; старі вузли — неефективність і обмежений запас.
Потрібен виміряний, кваліфікований прогрес, а не новизна.

9) Що робити, якщо procurement нав’язує іншу модель CPU під час оновлення?

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

10) Як це стосується інженерії зберігання конкретно?

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

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

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

Наступні кроки, що дійсно приносять результат:

1. Зробіть інвентар правди. Збирайте модель CPU/stepping/мікрокод, BIOS, ядро, прошивку NIC. Зробіть це доступним для запитів.
2. Визначте класи продуктивності та пули. Перестаньте ставити latency-критичні навантаження на «невідомі́» партії апаратури.
3. Прийміть швидкий план діагностики. Навчіть організацію виключати конкуренцію та дрейф перед тим, як звинувачувати підсистеми.
4. Тестуйте апарат як програмне забезпечення. Нові сервери отримують тестову доріжку, критерії прийняття та плани відкату.
5. Інвестуйте в ефективність ПЗ. Це єдине оновлення, яке не підведе через проблеми фабрики в певному кварталі.

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