Celeron: як урізаний чип став легендою апгрейда

Що мав означати Celeron

Celeron починав як бюджетна лінійка Intel: спосіб зайняти нижчі цінові позиції без канібалізації бренду Pentium. На практиці це був набір компромісів — зазвичай менше кешу, іноді повільніша фронтальна шина, іноді відсутні певні функції, іноді нижчі частоти, часто все разом.

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

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

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

Як сформувалася легенда про апгрейд

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

Канонічна історія — ера Celeron 300A: дешевий чип, який за правильної материнської плати та охолодження міг працювати на вищій швидкості шини і давати продуктивність, порівнянну з набагато дорожчими моделями. Це був ідеальний збіг архітектури, бінінгу та вільної культури збірки ПК кінця 90-х.

Але глибша причина, чому легенда трималася й у пізніших поколіннях, більш приземлена: для багатьох користувачів вузьким місцем не було ядро CPU. Це був диск, обсяг оперативної пам’яті, GPU або просто роздутий софт. Вставте «достатньо хороший» CPU — і система здається «виправленою». Люди приписують покращення CPU, бо це найпомітніше оновлення. Тим часом стек зберігання тихо робить 400 випадкових IOPS і псує всім настрій.

Жарт №1 (коротко й болісно правдивий): Оновлювати CPU, щоб виправити повільний ноутбук — це як купувати гоночні шини для машини з затягнутим ручним гальмом. Здається активним кроком, аж доки не відчуєш запаху диму.

У серверному середовищі легенда Celeron набула іншої форми: низьке енергоспоживання, невисоке тепло, «достатньо для дрібних сервісів». Іноді це правда. Це також спосіб опинитися з TLS-реверс-проксі на процесорі, який виглядає нормальним у середньому по CPU, але розвалюється під піковими показниками рукопотискань.

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

Це не тривіальні відомості заради цікавості; вони пояснюють, чому деякі Celeron були улюбленцями, а інші — сміттям.

• Celeron запущений у 1998 році як реакція Intel на тиск цінового сегмента, особливо з боку агресивно ціноутворених чипів AMD.
• Перші “Covington” Celeron виходили без L2 кешу (так, зовсім без), що робило їх продуктивно слабкими, незважаючи на пристойні частоти для того часу.
• Mendocino Celeron додав інтегрований L2 кеш, великий стрибок у реальній продуктивності завдяки значному зменшенню латентності кешу.
• Celeron 300A (1998) здобув популярність через оверклокінг — його часто запускали з FSB 66 MHz на 100 MHz, якщо материнська плата і RAM витримували.
• Intel використовував важелі сегментації як швидкість FSB і розмір кешу, щоб відділити Celeron від Pentium, часто на тій самій конструкції ядра.
• Пізніші Celeron перейшли в ролі енергоефективних мобільних і вбудованих рішень, включно з багатьма двоядерними моделями для нетбуків і малих десктопів.
• Деякі сучасні моделі під брендом “Celeron” базуються на ядрах, похідних від Atom, а не від великих десктопних ядер, що змінює поведінку продуктивності (особливо в однониткових завданнях).
• Підтримка віртуалізації варіюється за поколіннями; деякі Celeron не мають VT-x або мають обмежені можливості в порівнянні з сусідніми SKU.
• Бренд пережив кілька архітектурних епох (P6, NetBurst, Core та сімейства Atom), через що узагальнення про «продуктивність Celeron» зазвичай помилкові.

Технічна суть: кеш, шина, частоти та вирізи

Кеш: виріз, що найчастіше мав значення (поки не перестає)

Більшість сегментацій Celeron була зосереджена на кеші. Це не випадково; кеш дорого обходиться в площі кристалу й енергії, і він критично важливий, коли робочий набір поміщається в нього. Зменшивши кеш, ви змушуєте частіше звертатися до оперативної пам’яті, де латентність переважає час виконання в ядрі.

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

Тут міф розгалужується:

• Якщо ваше навантаження поміщається в кеш (або є стрімінговим і передбачуваним), чип з урізаним кешем може виглядати дуже добре.
• Якщо ваше навантаження — «переслідування вказівників» (бази даних, деякі key-value сховища, певні схеми стиснення, деякі рантайми мов), вирізи кешу шкодять непропорційно сильно.

Фронт-сайд шина і підсистема пам’яті: невидимий обмежувач

Старі Celeron часто мали повільніші FSB. Це важливо, коли ви обмежені пам’яттю або коли чіпсет + RAM уже на межі. Ви можете мати CPU, готовий працювати, і підсистему пам’яті, що не поспішає.

Сучасні платформи відійшли від класичної моделі FSB, але принцип залишається: підсистема пам’яті (частота, канали, латентність, якість контролера) часто є реальним обмежувачем продуктивності.

Відрізані функції: віртуалізація, інструкції та «вмикається, але сумно»

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

Інакше кажучи: «Celeron» — це не специфікація. Це попереджувальна етикетка, щоб читати дрібний шрифт.

Терміни та енергоспоживання: тиха причина їх привабливості

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

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

Де Celeron перемагає (і чому)

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

1) Простні сервіси з передбачуваною конкурентністю

DNS-резидери, невеликі Nginx реверс-проксі (без інтенсивного TLS), внутрішні дашборди, збирачі метрик, відправники логів — зазвичай ці сервіси нормально працюють на помірних CPU, якщо є достатньо RAM і пристойне сховище. Ключова фраза — «передбачувана конкурентність».

2) NAS і домашні сервери, де домінує сховище

Файловий сервіс, бекапи та медіа-стрімінг часто обмежуються пропускною здатністю дисків, мережею або протокольною накладною. Якщо ви насичуєте 1 GbE, CPU може не бути вашою проблемою. Додайте шифрування, стиснення, дедуплікацію або інтенсивні контрольні суми — і ситуація швидко зміниться.

3) Підвищення відчуття responsiveness на старих машинах

Бюджетний CPU у парі з SSD і достатнім обсягом RAM може виглядати як диво в порівнянні зі старою системою на жорсткому диску. Але диво часто роблять SSD і RAM, а не CPU. Не переплутайте, куди треба приписувати заслугу; це та причина, через яку бюджети на оновлення витрачаються невірно.

4) Середовища з обмеженням по шуму та енергії

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

Де Celeron підводить (і як саме)

1) Все, що потребує серйозної латентності на ядро

Коли важлива хвостова затримка, важлива однониткова продуктивність. Не завжди, але часто. Багато Celeron мають менше ядер, нижчі частоти, менший кеш і іноді слабші мікроархітектури (особливо лінії, похідні від Atom). Режим відмови тонкий: середній час відповіді може виглядати прийнятним; p99 і p999 стають жахливими під навантаженням.

2) Навантаження з інтенсивним шифруванням

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

3) Віртуалізація та мрії про «малий хмарний хост»

Людям подобається ідея маленького домашнього сервера, що крутить купу віртуальних машин. Реальність: перевірте підтримку VT-x, обсяг пам’яті та I/O. Celeron може запускати гіпервізор, але він також може загнати вас у повільні шляхи емульованої роботи або в тісноту пам’яті, що зробить кожного гостя нещасним.

4) Стовпи зберігання, що виконують реальну роботу

ZFS з стисненням, дедуплікацією (не робіть цього), контрольними сумами, scrub-процедурами та снапшотами можуть навантажувати CPU. Те ж саме стосується програмних RAID-паритетів, ерейзур-кодування та сучасних файлових систем, які виконують роботу цілісності. Режим відмови: зайнятість дисків виглядає низькою, але пропуск гальмує; вузьким місцем є CPU, а не накопичувачі.

Жарт №2 (коротко): Дедуплікація на крихітному CPU — це як влаштовувати фуршет у телефонній будці. Технічно можливо; соціально й термічно катастрофічно.

Один цитат, бо це досі правда

Парафразована ідея від Gene Kim: «Покращення потоку і зворотного зв’язку краще за героїчні вчинки; зробіть роботу видимою, зменшіть розміри пакетів, і проблеми простіше виправляти.»

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

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

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

Спочатку: вирішіть, чи це насичення CPU або очікування CPU

• Перевірте середнє навантаження vs. використання CPU. Високе навантаження з низьким використанням CPU часто означає очікування I/O або блокування.
• Подивіться на чергу виконання та iowait. Якщо iowait високий, не купуйте CPU.
• Перевірте троттлінг. «Повільний» CPU може бути гарячим.

По-друге: визначте домен вузького місця (CPU / пам’ять / диск / мережа)

• Диск: високий await, низька пропускна здатність, насичена черга пристрою → вузьке місце в сховищі або погана латентність.
• Пам’ять: свапінг, високі major faults, мало вільної пам’яті, висока рекламація → пам’ять.
• Мережа: ретрансляції, втрати, насичення NIC → мережне вузьке місце.
• CPU: високий user/system час, велика кількість runnable threads, низький iowait → CPU.

По-третє: знайдіть конкретний обмежувач

• Якщо CPU: однонитковий піковий потік? блокування? крипто? збірка сміття? час ядра?
• Якщо диск: випадковий I/O? fsync-шторм? дрібні записи? write amplification? деградований RAID?
• Якщо пам’ять: витік? неправильно налаштовані кеші? невідповідний розмір JVM? ліміти контейнерів?
• Якщо мережа: невідповідний MTU? втрати через кільця буферів? поганий offload?

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

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

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

Завдання 1: Визначити точну модель CPU та можливості

cr0x@server:~$ lscpu
Architecture:             x86_64
CPU op-mode(s):           32-bit, 64-bit
Vendor ID:                GenuineIntel
Model name:               Intel(R) Celeron(R) CPU J4125 @ 2.00GHz
CPU(s):                   4
Thread(s) per core:       1
Core(s) per socket:       4
Socket(s):                1
Flags:                    fpu vme de pse tsc msr pae mce cx8 apic sep mtrr ... aes ... vmx

Значення: Ви тепер знаєте SKU, кількість ядер і чи є такі можливості, як aes (AES-NI) і vmx (VT-x).

Рішення: Якщо vmx відсутній, припиніть обіцяти «кучу VM». Якщо aes відсутній, будьте обережні з TLS-термінацією та інтенсивним шифруванням.

Завдання 2: Підтвердити підтримку віртуалізації (готовність до KVM)

cr0x@server:~$ egrep -o 'vmx|svm' /proc/cpuinfo | head
vmx
vmx
vmx
vmx

Значення: vmx вказує на Intel VT-x. Якщо нічого не виводиться, апаратної віртуалізації немає.

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

Завдання 3: Перевірити, чи CPU троттлиться (теплові або енергетичні обмеження)

cr0x@server:~$ sudo dmesg | egrep -i 'thrott|thermal|powercap' | tail -n 5
[ 8921.113421] thermal thermal_zone0: critical temperature reached, shutting down
[ 9120.221044] CPU0: Core temperature above threshold, cpu clock throttled

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

Рішення: Виправте охолодження, пил, повітряний потік, термопасту, криву вентилятора, BIOS-параметри. Оновлення CPU без виправлення термального режиму — це самосаботаж.

Завдання 4: Подивитись поточні частоти, щоб зафіксувати постійне заниження

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

Значення: CPU сидить на 800 MHz. Це може бути стан простою (нормально) або застрягання через політику живлення (погано).

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

Завдання 5: Загальна знімка CPU та iowait

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

12:01:10 PM  CPU   %usr %nice %sys %iowait %irq %soft %steal %idle
12:01:11 PM  all   12.00  0.00  4.00   0.00 0.00  1.00   0.00 83.00
12:01:12 PM  all   10.75  0.00  3.50  18.25 0.00  0.50   0.00 67.00
12:01:13 PM  all   11.50  0.00  3.25  22.75 0.00  0.75   0.00 61.75

Значення: CPU не насичений, але iowait зростає. Ваш «повільний сервер» ймовірно чекає на диск.

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

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

cr0x@server:~$ uptime
 12:02:01 up 34 days,  4:20,  2 users,  load average: 6.21, 5.88, 5.43

Значення: На 4‑ядерному CPU стійке середнє навантаження близько 6 свідчить про черги. Але це може бути runnable tasks або непереривне I/O wait.

Рішення: Негайно поєднайте з vmstat, щоб відрізнити чергу виконання CPU від i/o wait.

Завдання 7: Відрізнити тиск CPU від I/O wait і свапінгу

cr0x@server:~$ vmstat 1 5
procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st
 6  0      0 412000  21000 512000    0    0    12   150  320  780 12  4 82  2  0
 7  0      0 410800  21000 512500    0    0     8  1200  340  820 14  5 70 11  0
 5  1      0 410500  21000 512100    0    0     0  2400  360  900 10  4 55 31  0
 3  2      0 409900  21000 511900    0    0     0  1800  310  860  8  3 50 39  0
 4  1      0 410200  21000 512200    0    0     0   900  300  830  9  3 62 26  0

Значення: r — runnable, b — blocked. Тут заблоковані процеси зростають і wa підскакує: біль — в I/O.

Рішення: Сфокусуйтеся на сховищі: який пристрій, який процес і який шаблон доступу. Апгрейд CPU не ваш перший крок.

Завдання 8: Знайти топ-споживачів CPU і чи це одна «гаряча» нитка

cr0x@server:~$ top -b -n 1 | head -n 15
top - 12:03:10 up 34 days,  4:21,  1 user,  load average: 5.92, 5.80, 5.41
Tasks: 212 total,   3 running, 209 sleeping,   0 stopped,   0 zombie
%Cpu(s): 28.1 us,  6.3 sy,  0.0 ni, 40.0 id, 25.6 wa,  0.0 hi,  0.0 si,  0.0 st
MiB Mem :   7865.2 total,   612.4 free,  1021.8 used,  6231.0 buff/cache
PID USER      PR  NI    VIRT    RES    SHR S  %CPU  %MEM     TIME+ COMMAND
2113 postgres  20   0 1894328 412560  17892 R  98.7   5.3  12:08.33 postgres
1452 root      20   0  612280  38400  12300 D  35.2   0.5   2:12.04 rsync

Значення: Один процес postgres практично споживає повне ядро; також високий i/o wait і rsync застряг у непереривному сні (D).

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

Завдання 9: Перевірити затримки та черги по дисках

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

Device            r/s     w/s   rkB/s   wkB/s  await  svctm  %util
sda              1.20   60.30    80.1  4200.7  45.20   1.90  98.30
nvme0n1         10.00    5.00  1200.0   300.0   1.10   0.20   2.00

Значення: sda зайнятий на ~98% з високим await. Це ваш вузький місце, а не CPU.

Рішення: Перенесіть гаряче навантаження на NVMe/SSD, виправте структуру RAID, зменшіть синхронні записи або змініть шаблон доступу. Вибір CPU другорядний, поки латентність диска не зменшиться.

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

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

Значення: Ви бачите файлову систему та опції монтовання. Це не обов’язково «погано», але допомагає підтвердити припущення (наприклад, чи ми випадково на шпинделях? чи використовуються дивні опції?).

Рішення: Якщо ви очікували SSD/NVMe, а бачите /dev/sda2, ви щойно знайшли помилку міграції.

Завдання 11: Перевірити тиск пам’яті та свапінг

cr0x@server:~$ free -h
               total        used        free      shared  buff/cache   available
Mem:           7.7Gi       1.0Gi       620Mi       120Mi       6.1Gi       6.3Gi
Swap:          2.0Gi         0B       2.0Gi

Значення: Достатньо доступної пам’яті; свапінг наразі не проблема.

Рішення: Не додавайте RAM «просто так». Якщо продуктивність все ще погана, дивіться на латентність I/O або конкуренцію за CPU.

Завдання 12: Виявити підозру на латентність пам’яті або пропуски кешу (швидкий проксі через perf)

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

        6,210.45 msec task-clock                #    1.242 CPUs utilized
       12,112,040      context-switches          #    1.952 M/sec
          102,400      cpu-migrations            #   16.489 K/sec
     18,220,000,000      cycles                  #    2.936 GHz
     10,440,000,000      instructions            #    0.57  insn per cycle
        1,220,000,000      cache-misses          #   30.1% of all cache refs

       5.000812445 seconds time elapsed

Значення: IPC низький, а пропуски кешу високі. Це часто вказує на поведінку, залежну від пам’яті — саме там, де виріз кешу та слабка пам’ять шкодять.

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

Завдання 13: Перевірити втрати пакетів і ретрансляції (не звинувачуйте CPU за втрачені пакети)

cr0x@server:~$ ip -s link show dev eth0
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP mode DEFAULT group default qlen 1000
    link/ether 52:54:00:12:34:56 brd ff:ff:ff:ff:ff:ff
    RX:  bytes packets errors dropped  missed   mcast
      987654321  1234567      0     184       0      12
    TX:  bytes packets errors dropped carrier collsns
      876543210  1122334      0      96       0       0

Значення: Є дропи. Не обов’язково катастрофа, але достатньо, щоб створити «випадкову повільність» під навантаженням.

Рішення: Розслідуйте кільця буферів NIC, драйвер, порт комутатора, кабель, MTU і перевантаження хоста. Не приносьте CPU як ритуальну жертву.

Завдання 14: Підтвердити наявність крипто-прискорення (реальність TLS та шифрування)

cr0x@server:~$ grep -m1 -o 'aes' /proc/cpuinfo
aes

Значення: AES-NI доступний. Це добре для популярних TLS шифрів і накладних витрат при шифруванні дисків.

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

Завдання 15: Виміряти латентність сховища з точки зору застосунку (fsync-інтенсивність)

cr0x@server:~$ sudo fio --name=fsync-test --directory=/var/lib/postgresql --rw=write --bs=4k --size=256m --fsync=1 --numjobs=1 --iodepth=1 --runtime=20 --time_based --direct=1
fsync-test: (g=0): rw=write, bs=4K-4K/4K-4K/4K-4K, ioengine=psync, iodepth=1
fio-3.33
fsync-test: (groupid=0, jobs=1): err= 0: pid=3312: Thu Jan  9 12:04:10 2026
  write: IOPS=210, BW=840KiB/s (860kB/s)(16.4MiB/20001msec); 0 zone resets
    clat (usec): min=900, max=250000, avg=4600.12, stdev=12000.55

Значення: 4k синхронні записи ~210 IOPS з мілісекундними й сотнями мс піками латентності. Це вб’є хвостову латентність бази даних незалежно від CPU.

Рішення: Виправте сховище спочатку (SSD/NVMe, правильне кешування, контролер, захист від втрати живлення). Апгрейд CPU не поверне fsync-латентність.

Завдання 16: Визначити, чи CPU — обмежувач під реальним навантаженням (швидкий стрес)

cr0x@server:~$ stress-ng --cpu 4 --timeout 15s --metrics-brief
stress-ng: info:  [4102] setting to a 15 second run per stressor
stress-ng: info:  [4102] dispatching hogs: 4 cpu
stress-ng: metrc: [4102] stressor       bogo ops real time  usr time  sys time   bogo ops/s
stress-ng: metrc: [4102] cpu              4200     15.01     59.80      0.02       279.8

Значення: Дає приблизну базу пропускної здатності CPU і допомагає виявити троттлінг при тривалому навантаженні в парі з перевіркою частот.

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

Три міні-історії з реальних кейсів

Міні-історія 1: Інцидент через неправильне припущення («апгрейд CPU», якого не потрібно було)

Середня SaaS-команда успадкувала сервіс звітності, що генерував PDF на вимогу. Сервіс жив на скромному боксі: низький CPU, помірна RAM і один SATA SSD. Під кінець місяця час відповіді зріс. Пішли тікети підтримки. Очевидний наратив виник швидко: «Нам потрібен швидший CPU».

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

Неправильне припущення було в тому, що навантаження було CPU-зв’язане. Ні. Пайплайн генерації PDF писав багато маленьких файлів, часто робив fsync, потім стискав і завантажував артефакти. Пристрій зберігання, хоч і SSD, насичувався write amplification і fsync-латентністю під конкуренцією. Використання CPU залишалося комфортно нижче 50%, тоді як iowait піднімався і черга виконання виглядала зайнятою.

Коли вони запустили простий iostat -x і fsync-орієнтований fio, історія змінилася. Вони перемістили scratch-каталог на швидший NVMe і зменшили частоту синхронних записів там, де коректність це дозволяла. Також обмежили конкурентність під кінець місяця. Інцидент, який пов’язували з CPU, зник без подальших змін CPU.

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

Міні-історія 2: Оптимізація, що відкотилася (щоб заощадити CPU, витратили його)

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

Перший симптом не був очевидним насиченням CPU. Це була періодична повільність. Завантаження іноді тривало довше. Аплоади іноді тайм-аутували. Система зберігання показувала нижчу сиро-пропускну здатність, але вищий системний час CPU. Мережа звинувачувалась, потім storage, потім розробник, який включив стиснення, — що є і культурною проблемою, і типовим сценариєм.

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

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

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

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

Команда, що вела невеликі локальні сервіси (CI-runner’и, внутрішній Git, стек метрик), стандартизувала скромний апарат, щоб тримати витрати низькими. Деякі бокси були класу Celeron, обрані за енергоефективність і доступність. Середовище працювало, бо вони ставилися до нього як до продакшену, а не як до хобі.

Нудна практика: кожен сервіс мав односторінкову «ноту про потужності та обмеження». Там були очікувані QPS, пікові події, необхідні CPU-фічі (AES-NI, віртуалізація), цільова латентність сховища і жорсткий «заборонений список» (ні дедупу, ні несподіваних VM, ні важкого стиснення на найслабших вузлах). Також після провізії записували базові виміри: fio-латентність, iperf-пропуск і простий CPU-стрес для перевірки троттлінгу.

Одного дня оновлення ядра збіглося з новим CI-навантаженням. Бідиші швидкості збірок. Усі вирішили, що нове навантаження важче. Але runbook змусив їх перевірити базовий стан: частоти CPU застрягли низько через зміну політики governor. Наратив «повільний хардвер» не встиг закріпитися, бо у них були відомі добрі числа для порівняння.

Вони відкотили політику governor, підтвердили терміни і система повернулась до норми. Ніхто не купував нового обладнання. Ніхто не витрачав тижні на суперечки в Slack, чий код «сповільнився».

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

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

Цей розділ навмисно конкретний. Якщо ви впізнаєте патерн симптомів, зазвичай можна уникнути дурного апгрейду або інциденту.

1) Симптом: високе середнє навантаження, CPU не залежений

Корінь: задачі застрягають у непереривному I/O wait (латентність диска, зависання NFS, деградований RAID) або блокування.

Виправлення: перевірте vmstat (b і wa), потім iostat -x для await і %util. Якщо це NFS, перевірте латентність сервера і мережеві втрати. Не купуйте CPU.

2) Симптом: сплески p99 під час бекапів або scrub-процедур

Корінь: фоновий I/O насичує диск; маленький CPU не може приховати латентність сховища; контенція планувальника.

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

3) Симптом: TLS-термінація «повільнішає» рандомно під сплесками

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

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

4) Симптом: база даних працює нормально до зростання конкурентності, потім падає

Корінь: пропуски кешу і латентність пам’яті, підсилені урізаним кешем CPU; латентність синку сховища; блокування.

Виправлення: виміряйте пропуски кешу (perf), проаналізуйте плани запитів/індекси, перевірте fsync-латентність. Якщо perf показує низький IPC і високу кількість cache-miss на низькокешовому CPU — CPU з більшим кешем може бути правильним рішенням.

5) Симптом: «апгрейд CPU» дає мінімальне покращення

Корінь: вузьке місце — сховище, пам’ять або мережа; CPU не був обмежувачем.

Виправлення: зробіть базову лінію перед змінами. Після зміни порівняйте iowait, disk await, retransmits та свап. Припиніть ставити CPU як дезодорант продуктивності.

6) Симптом: продуктивність VM жахлива, хоча хост виглядає вільним

Корінь: відсутній VT-x, погана I/O віртуалізація або недостатньо RAM, що призводить до трясіння кеша хосту.

Виправлення: підтвердіть vmx; перевірте завантаження модулів KVM; забезпечте достатній обсяг RAM; надавайте перевагу контейнерам на низькокласних чипах, якщо функції VM обмежені.

7) Симптом: вентилятори ревуть, продуктивність нестабільна

Корінь: термальне троттлінг в невеликому корпусі, пил, зламана турбіна або консервативні BIOS-настройки енергії.

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

8) Симптом: пропускна здатність сховища нижча за очікувану на «швидких» дисках

Корінь: CPU є обмежувачем для контрольних сум/стиснення/паритету; або навантаження — дрібний випадковий I/O.

Виправлення: запустіть fio для класифікації I/O; перевірте використання CPU і iowait; перегляньте стиснення, режим RAID та вирівнювання recordsize/volblocksize. Оновлюйте CPU тільки якщо після налаштувань CPU час — справжній ліміт.

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

Покроково: як вирішити, чи Celeron «достатній» для ролі

1. Назвіть навантаження. «NAS» — не навантаження. «SMB-файловий сервіс, 10 користувачів, періодичні великі копії файлів» — це навантаження.
2. Запишіть ціль продуктивності. Пропускна здатність? Латентність? p99? Час білду? Вікно бекапу?
3. Перерахуйте жорсткі вимоги. Потрібен VT-x? AES-NI? Максимум RAM? PCIe лінії для NVMe?
4. Виміряйте базову лінію. Стабільність CPU під стресом, fio-латентність на цільовій файловій системі, мережевий пропуск і простий бенчмарк на рівні застосунку.
5. Класифікуйте вузькі місця. Використайте швидкий план діагностики: CPU vs пам’ять vs диск vs мережа.
6. Вирішіть регулятори до купівлі обладнання. Ліміти конкурентності, стратегія кешування, політика стиснення/шифрування.
7. Тільки тоді обирайте клас CPU. Якщо ви обмежені латентністю пам’яті — важливіший більший кеш і сильніші ядра. Якщо ви обмежені сховищем — інвестуйте в сховище спочатку.
8. Документуйте обмеження. Запишіть «ні важкому стисненню на цьому вузлі». Майбутній ви все одно забуде.

Чекліст: безпечний шлях апгрейду для бюджетних систем

• Оновлюйте сховище першочергово, якщо бачите високий await або fsync-спайки латентності.
• Додавайте RAM, якщо бачите свапінг або major faults при нормальному навантаженні.
• Виправте терміни перед зміною кремнію.
• Підтвердіть прапори фіч (vmx, aes) перед тим, як зобов’язуватися до сценарію.
• Бенчмартьте під конкуренцією, а не в тесті з одним користувачем.
• Майте план відкату: налаштування BIOS, версії ядра, політики governor.

Чекліст: коли уникати CPU класу Celeron

• Точки TLS із високою частотою рукопотискань або важкі криптопайплайни без запасу потужності.
• Первинні вузли баз даних, де важлива p99 латентність і робочі набори перевищують кеш.
• Хости з багатьма VM, де потрібна стабільна однониткова продуктивність і повні функції віртуалізації.
• Ноди зберігання, що виконують паритет/ерейзур-код/стиснення на високих швидкостях.
• Усе, де ви не можете обмежити фонову роботу і вам потрібна стабільна латентність.

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

1) Чи був Celeron «просто гірший Pentium»?

Іноді. Але часто це була та сама підкладна архітектура з меншим кешем або повільнішою шиною. Різниця між «гірший» і «достатньо хороший» залежить повністю від навантаження і поведінки пам’яті.

2) Чому Celeron 300A став відомим?

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

3) Чи можу я запустити NAS на Celeron?

Так, якщо ваше навантаження здебільшого — сервірування файлів і ваші цілі пропускної здатності не екстремальні. Але функції як шифрування, стиснення і перевірки цілісності можуть перевести вас у стан «обмеження CPU». Виміряйте fsync-латентність і запас CPU.

4) Чому люди так кажуть, що «кеш має значення» для Celeron?

Бо вирізи кешу часто цілеспрямовано застосовувалися до Celeron, і кеш — це різниця між швидким локальним доступом і повільними зверненнями до основної пам’яті. Багато серверних робочих навантажень чутливі до латентності пам’яті, навіть коли завантаження CPU виглядає помірним.

5) Як визначити, що оновлювати: CPU чи сховище?

Якщо iowait високий і disk await підвищений — робіть сховище першим. Якщо CPU завантажений в user/system з низьким iowait і високою чергою runnable — CPU першим. Якщо обидва проблемні, виправте латентність сховища спочатку, щоб зробити виміри CPU осмисленими.

6) Чи всі Celeron підтримують віртуалізацію (VT-x)?

Ні. Це залежить від покоління і SKU. Перевірте прапори lscpu на vmx. Якщо його немає, не розраховуйте на прийнятний рівень продуктивності VM.

7) Чи сучасні Celeron завжди — низькопотужні ядра Atom-класу?

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

8) Чи актуальний оверклокінг для легенди Celeron сьогодні?

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

9) Який найбільший операційний ризик при низькокласних CPU?

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

10) Якщо я вже маю Celeron-бокс, як зробити його слухняним?

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

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

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

Кроки, які ви можете зробити цього тижня:

1. Виміряйте базову лінію вашої системи за допомогою наведених вище команд: прапори CPU, сигнали троттлінгу, iowait, disk await і цілеспрямований fio-тест.
2. Напишіть односторінкову ноту обмежень для кожного боксу: що він може запускати, чого ніколи не повинен запускати і як виглядають «нормальні» метрики.
3. Кидайте гроші туди, де живе вузьке місце: латентність сховища першочергово для баз даних і sync-важких навантажень; кеш/ядра CPU для сервісів, чутливих до латентності пам’яті; RAM для будь-чого, що свапає; мережа для втрат і ретрансляцій.
4. Якщо ви купуєте апгрейд CPU, купуйте його з доказами: perf-лічильники, числа латентності і бенчмарк до/після під конкуренцією.

Легенда не в тому, що Celeron був таємно преміальним. Легенда в тому, що розумні люди — іноді випадково — дізналися, що найдешевше рішення, яке працює, — це те, що відповідає реальному вузькому місцю.