Дешеві БЖ: як економія $20 перетворюється на феєрверк

Чому дешеві БЖ виходять із ладу саме так, що це боляче

Блок живлення — це перекладач між кіптявим світом (ваша мережа в стіні, вихід UPS, генератор, кондиціонер сусіда)
і вибагливим світом (CPU VRM, лінії пам’яті, контролери SSD). «Він перетворює AC у DC» — це як описати лікарню як «будівлю з ліжками».

Дешеві БЖ — це не просто «менше ефективні». Вони часто позбавлені захисних функцій, зібрані на конденсаторах нижчої якості, з недостатніми радіаторами,
оптимістичними маркуваннями та контурами керування, які стають нестабільними під реальними перехідними процесами. Пристрій може працювати на десктопі в спокійний полудень.
Потім ви запускаєте компіляцію, ZFS scrub, GPU-джоб або шторм віртуальних машин і він перетворюється на електричний еквівалент дитини за кермом навантажувача.

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

• Тиху корупцію: операції запису з «успіхом», які зберігають неправильні дані.
• Гейзенбаги: kernel panic і випадкові segfault, що зникають, коли ви змінюєте щось не пов’язане.
• Старіння компонентів: ви скорочуєте строк служби дисків, VRM материнської плати та NIC через ripple і перегрів.
• Відмови «тільки під навантаженням»: стабільно в простій, нестабільно під навантаженням — саме тоді, коли це важливо.

Ті $20, що ви «зекономили», порівнюються не з кращим БЖ. Вони порівнюються з вашим часом, бюджетом простою, репутацією SLA і даними, які
ви не зможете відтворити. Якщо ви керуєте продукцією, найдешевший БЖ — це той, про який вам ніколи не доведеться говорити.

Одна коротка жартівлива ремарка для очищення смаку: Дешевий БЖ — як мотиваційний плакат — виглядає підтримуючим, але розвалюється під справжнім тиском.

Що роблять хороші БЖ, чого дешеві часто не роблять

Якісні БЖ мають нудну, передбачувану поведінку:

• Щільна регуляція напруги по діапазону навантажень, а не лише в одній «зручній для огляду» точці.
• Низький ripple і шум, щоб downstream VRM не фільтрували тонни сміття.
• Швидка реакція на перехідні процеси, коли навантаження CPU/GPU зростає з 20% до 90% за мілісекунди.
• Реальні захисні ланцюги: OCP, OVP, UVP, OTP, SCP і бажано добре налаштований «бездрамний» режим вимкнення.
• Час утримання, що переживає короткі просідання вхідної напруги без brownout-перезавантажень.
• Консервативні номінали: 750W, який справді може дати 750W при реальній температурі.

Ви не зможете «RAID’ом» вибратись із БЖ, що опускає шини або розпилює ripple саме в момент, коли контролер SSD фіксує оновлення таблиці відображення.
Резервування допомагає. Воно не скасовує фізику.

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

Ось конкретні факти і контекст, які пояснюють, чому ринок БЖ такий повний пасток. Це не дрібниці; це причина, чому ті самі відмови повторюються в компаніях і хомлабах.

1. 80 PLUS починався як програма ефективності, а не як печатка якості.
   Сертифікація в основному вимірює ефективність у кількох точках навантаження; вона не гарантує низького ripple, хороших захистів або безпечної поведінки під час вимкнення.
2. Маркування «пікова потужність» зловживають десятиліттями.
   Деякі дешеві пристрої рекламують число, яке можуть дати коротко, а не постійно, і іноді лише при нереально низьких внутрішніх температурах.
3. Стандарти ATX еволюціонували через те, що нестабільні шини спричиняли реальні збої.
   Сучасні системи сильно залежать від шини 12V, з CPU/GPU VRM, що понижують її; старіші конструкції більше дбали про розподіл 3.3V/5V.
4. Час утримання — прихована функція надійності.
   Це здатність БЖ утримувати DC стабільним кілька мілісекунд після падіння AC. Короткий час утримання перетворює нешкідливі просідання в перезавантаження й скидання дисків.
5. Електролітичні конденсатори старіють швидше при теплі і струмі ripple.
   Дешевші конденсатори і гарячі конструкції втрачають ємність, збільшуючи ripple з часом, що прискорює відмову — жахливе петлеутворення.
6. Груповорегульовані дизайни можуть відчувати труднощі з сучасними схемами перерозподілу навантаження.
   Якщо ваше навантаження здебільшого на 12V (поширено сьогодні), груповорегульований БЖ може погано регулювати другорядні шини і гірше реагувати на транзієнти.
7. «Захисти» можуть бути в специфікації, але погано налаштовані.
   OCP із занадто високими порогами — фактично декоративний; UVP із занадто низькими порогами означає, що система страждає перед тригером.
8. Серверні БЖ популяризували hot-swap резервування не випадково.
   Дата-центри вивчили на власному досвіді, що живлення — провідна причина інцидентів, а hot-swap БЖ дозволяють виправити це без простою.

Одна цитата, щоб тримати вас чесними. Парофраза з W. Edwards Deming: Якість закладають у процес; пізніше її не перевірити.
Це БЖ в одному реченні. Ви не «протестуєте» поганий дизайн так, щоб він став добрим.

Що реально ламається: режими відмов простою мовою

1) Ripple і шум: повільний отруйник

Ripple — це AC-шум, що їде по DC-виходу. Downstream VRM і регулятори його фільтрують, але вони не безмежні сміттєзбирачі.
Надмірний ripple збільшує нагрів у VRM, може викликати маргінальну поведінку в RAM і PCIe, і змушує електроніку накопичувачів працювати важче.
Підпис відмов — божевільний: ви отримуєте «випадкові» помилки під навантаженням, особливо в теплі дні.

Уявіть, що марафонця годують енергетичними напоями і гравієм. Вони досі бігатимуть — деякий час.

2) Транзієнтна відповідь: коли навантаження змінюється швидше, ніж реагує БЖ

Сучасні CPU і GPU змінюють споживання дуже швидко. Хороший БЖ обробляє крок без просідання виходу нижче специфікації або без перегону.
Контур керування дешевого блоку може відставати або коливатися. Результат: короткі події недонавольтажу, що викликають:

• Миттєві перезавантаження (без коректного завершення)
• Скидання PCIe-з’єднань (NIC зникає, NVMe скидається)
• CPU machine check exceptions
• Таймаути скидання кешу диска при записі

3) Захисти, що не захищають

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

• OVP (Over Voltage Protection): запобігає «ой, 12V стало 14V», що вбиває плати.
• UVP (Under Voltage Protection): запобігає brownout-лімібо, коли система збивається на кілька секунд.
• OCP (Over Current Protection): запобігає тому, щоб кабель/шина стали нагрівальним елементом.
• OTP (Over Temperature Protection): запобігає приготуванню БЖ, після якого воно виходить із ладу непередбачувано.
• SCP (Short Circuit Protection): запобігає видовищному типу відмови.

4) Пусковий струм і дешеві компоненти: «працює, доки не перестане»

БЖ мають обмеження inrush і PFC-кола для обробки запуску. Дешеві конструкції можуть навантажувати компоненти при старті, особливо за деякими UPS.
З часом з’являються відмови при заведенні: система не запускається холодною, стартує після кількох спроб або лише якщо ви вимкнете/увімкнете вимикач БЖ.

5) Клеї та роз’єми: потускніння пластику — діагностичний інструмент, який ви не хотіли

Навіть якщо сам БЖ «в порядку», дешеві жгути, тонкий переріз дроту і погано обтиснуті конектори стають точки нагріву при великому струмі.
Симптом: переривчасті скидання GPU, SATA-диски відвалюються або система зависає, коли конкретний пристрій вмикається.
Ви відкриваєте корпус і знаходите потемнілі конектори. Це не «косметика». Це опір, тепло і наближення відмови.

Друга коротка жартівлива ремарка (і остання): запах від БЖ, що виходить із ладу — це спосіб природи сказати вам, що почалося вікно технічного обслуговування.

6) Чому фахівці зі сховищ так хвилюються

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

SSD особливо чутливі до подій зникнення живлення під час запису. Enterprise SSD часто мають конденсатори для захисту при втраті живлення; дешеві споживчі диски часто — ні.
Поставте це поруч із дешевим БЖ і ви отримаєте машину для корупції даних, яка працює лише в будні.

Три корпоративні міні-історії (анонімізовано, правдоподібно, технічно точно)

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

Середня SaaS-компанія розширила кластер обчислень для фонових задач. Вони купили партію «економічних» 1U вузлів у вторинного вендора.
Специфікація виглядала добре: достатня потужність, знак 80 PLUS, і вендор обіцяв «серверний клас живлення».

Хибне припущення було тонким: вони вважали, що «серверний клас» означає стабільну поведінку з їхньою топологією UPS. Вузли були підключені до line-interactive UPS,
який зрідка переключав режими під час незначних вхідних флуктуацій. Більшість серверів на це не реагували. Ця партія — реагувала.

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

Черга накопичилась. Таймаути зросли. Автоскейл додавав більше вузлів — ще з тим крихким БЖ. Це перетворило проблему з «деякі перезавантаження»
у «платформа нестабільна». Інцидент закінчився, коли хтось фізично перемістив два підозрілі вузли на інший шлях PDU/UPS і перезавантаження припинились.

Постмортемний фікс був нудним: замінити БЖ на відомо хороші моделі і кваліфікувати енергетичне обладнання тестом переходу UPS-mode.
Урок не в «UPS поганий». Урок: не робіть припущень, що наклейка означає сумісність з вашим середовищем.

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

Фінтех-команда намагалася знизити споживання і тепло в стійці. Вони поміняли набір старих, трохи завищених БЖ на менші, «точно підібрані» блоки,
які обіцяли кращу ефективність при типовому навантаженні. На папері виглядало розумно: менше марнованої потужності, вищий КПД, менші рахунки.

Бумеранг виник через реальні робочі навантаження. Системи мали різкі транзієнти: спалахи CPU, NVMe-активності, іноді GPU-ускорення.
Менші БЖ працювали ближче до своїх меж і мали гірший транзієнтний резерв. Коли навантаження підскакувало, 12V просідав ненабагато — але достатньо, щоб викликати PCIe-скидання.

Симптом не видавався «проблемою з живленням». Це була нестабільність сховища: NVMe зникали і з’являлись, починались rebuild RAID, і база логувала помилки IO. Оскільки коробки залишались увімкненими, люди підозрювали firmware, диски, ядро і бекплейни. Команда поміняла диски. Потім ще диски.

Переломним моментом стало корелювання подій: логи скидань NVMe зв’язались із короткими попередженнями BMC про мінімальні значення 12V. Нічого катастрофічного — просто достатньо.
Відкат до кращих БЖ з кращою транзієнтною відповіддю усунув скидання. Рахунок за електроенергію трохи виріс; кількість інцидентів сильно зменшилась.

Урок: «точно підібраний» не те саме, що «правильно спроектований». Резерв — це не витрата, це запас стабільності.

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

Група корпоративних ІТ керувала приватним кластером віртуалізації. Нічого модного. Вони були дисципліновані у двох речах: резервування БЖ і квартальне обслуговування.
Кожен хост мав подвійні hot-swap БЖ, підключені до окремих PDU, а команда регулярно тестувала фейловер, витягуючи один БЖ під навантаженням у планових вікнах.

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

Тут це стало тикетом. Сервери залишились живими на альтернативному БЖ-фіді. Моніторинг згенерував алерти «PSU redundancy lost» і «input voltage events»,
але VM цього не помітили. Немає корупції сховища. Немає split-brain. Ніякого героїчного відкату опівночі.

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

Урок: надійність часто складається з нудних звичок, виконаних послідовно.

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

Коли ви підозрюєте БЖ, потрібні швидкість і план. Не потрапляйте в пастку витратити шість годин на доведення гіпотези, яку можна перевірити за двадцять хвилин.
Цей план розрахований на реалії on-call.

Перший: класифікуйте відмову і захистіть дані

• Система жорстко перезавантажується? Якщо так, ставте це як нестабільне живлення. Вимкніть write caches там, де потрібно, призупиніть ризикові операції (scrub, rebuild), і зробіть снапшоти, що можете.
• Є запах/тепло/шум? Якщо відчувається електричний запах, чути іскри або видно пошкодження — вимикайте живлення безпечно і припиніть «тестувати».
• Чи ізольовано це чи системне? Один хост проти кількох хостів на тому самому PDU/UPS вказує на різні виправлення.

Другий: корелюйте логи з сенсорами і навантаженням

• Перевірте kernel-логи на machine checks, NVMe скидання, SATA link resets і ACPI power events.
• Перегляньте BMC/IPMI історію сенсорів по 12V/5V мін/макс та стан БЖ.
• Перевірте, чи збігаються відмови з CPU/GPU спайками, scrub-ами або підвищенням обертів вентиляторів (тепло).

Третій: зменшіть змінні рішучою заміною або ізоляцією

• Якщо у вас є відомо робочий БЖ, поміняйте його. Не «спостерігайте» дні.
• Якщо подвійний БЖ, тягніть по одному під навантаженням і дивіться зміни поведінки.
• Перемістіть хост на інший ланцюг/PDU тимчасово, щоб виключити upstream енергію.

Вузьке місце діагностики БЖ — зазвичай людська вага. Міняйте, ізолюйте і вимірюйте. Ви не займаєтесь філософією; ви керуєте операціями.

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

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

Завдання 1: Перевірте на різкі перезавантаження (без коректного завершення)

cr0x@server:~$ last -x | head -n 12
reboot   system boot  6.8.0-41-generic Mon Jan 22 09:14   still running
shutdown system down  6.8.0-41-generic Mon Jan 22 08:57 - 09:13  (00:16)
reboot   system boot  6.8.0-41-generic Mon Jan 22 08:12 - 08:57  (00:45)
reboot   system boot  6.8.0-41-generic Mon Jan 22 07:38 - 08:12  (00:34)
shutdown system down  6.8.0-41-generic Mon Jan 22 07:35 - 07:38  (00:02)

Що це означає: записи «reboot» без попереднього «shutdown» в потрібний час вказують на жорсткий ресет/втрату живлення.

Рішення: Розглядайте як потенційну нестабільність живлення. Пріоритезуйте перевірки PSU/UPS/PDU над відлагодженням додатку.

Завдання 2: Шукайте події ядра, пов’язані з живленням та machine checks

cr0x@server:~$ journalctl -k -b -1 | egrep -i "mce|machine check|watchdog|reset|nvme|ata|pcie|EDAC" | tail -n 30
Jan 22 08:11:58 server kernel: mce: [Hardware Error]: CPU 0: Machine Check: 0 Bank 5: b200000000070005
Jan 22 08:11:58 server kernel: mce: [Hardware Error]: TSC 0 ADDR fef1c140 MISC d012000100000000
Jan 22 08:11:59 server kernel: nvme nvme0: controller is down; will reset: CSTS=0x1, PCI_STATUS=0x10
Jan 22 08:12:00 server kernel: nvme nvme0: reset controller
Jan 22 08:12:03 server kernel: ata3: SATA link down (SStatus 0 SControl 300)

Що це означає: MCE разом з скиданнями лінків сховища — класична «живлення або плата» територія, особливо якщо з’являються під навантаженням.

Рішення: Перевірте шини БЖ через BMC-сенсори; розгляньте негайну заміну, якщо корелюється з перезавантаженнями.

Завдання 3: Перевірте BMC-сенсори на мін/макс напруги та стан БЖ

cr0x@server:~$ ipmitool sdr type Voltage
12V         | 11.71 Volts      | ok
5V          | 4.92 Volts       | ok
3.3V        | 3.28 Volts       | ok
VBAT        | 3.02 Volts       | ok

Що це означає: «ok» — це не вся історія; потрібна історія мін/макс, якщо доступна. Все ж, читання 12V близько до нижнього порогу підозріле.

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

Завдання 4: Отримайте детальні пороги сенсорів (якщо BMC їх дає)

cr0x@server:~$ ipmitool sensor get 12V
Locating sensor record...
Sensor ID              : 12V (0x30)
Entity ID             : 7.1
Sensor Type (Voltage) : Voltage
Sensor Reading        : 11.71 (+/- 0.00) Volts
Lower Non-Recoverable : 10.80
Lower Critical        : 11.00
Lower Non-Critical    : 11.20
Upper Non-Critical    : 12.80
Upper Critical        : 13.00
Upper Non-Recoverable : 13.20

Що це означає: 11.71V вище LNC, але не з розкішним запасом. Під транзієнтним навантаженням може коротко опуститись нижче 11.2V.

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

Завдання 5: Ідентифікуйте модель БЖ і резервування (де підтримується)

cr0x@server:~$ ipmitool fru | egrep -i "Power Supply|PSU|Part Number|Product"
Product Name          : Power Supply 1
Part Number           : PWS-920P-SQ
Product Name          : Power Supply 2
Part Number           : PWS-920P-SQ

Що це означає: Підтверджує, яке апаратне забезпечення у вас насправді, а не що відділ закупівель думає.

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

Завдання 6: Знайдіть події, пов’язані з БЖ, у SEL

cr0x@server:~$ ipmitool sel list | tail -n 10
1a3c | 01/22/2026 | 08:11:57 | Power Supply PS1 | Power Supply AC lost | Asserted
1a3d | 01/22/2026 | 08:11:58 | Power Supply PS1 | Failure detected | Asserted
1a3e | 01/22/2026 | 08:12:04 | Power Supply PS1 | Power Supply AC lost | Deasserted
1a3f | 01/22/2026 | 08:12:05 | Power Supply PS1 | Failure detected | Deasserted

Що це означає: BMC зафіксував втрату AC на БЖ або помилку. Це близько до «димлячого пістолета».

Рішення: Замініть PS1 і огляньте upstream-фід (кабель, розетка PDU, автомат).

Завдання 7: Перевірте сигнали якості мережі від UPS (якщо підключено через USB/NUT)

cr0x@server:~$ upsc myups@localhost | egrep "input\.voltage|input\.frequency|ups\.status|ups\.load|battery\.charge"
input.voltage: 228.0
input.frequency: 50.0
ups.status: OL
ups.load: 41
battery.charge: 100

Що це означає: OL означає «on line». Якщо ви бачите часті переходи OL/OB, ваш БЖ може погано реагувати на події перемикання.

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

Завдання 8: Перевірте скидання PCIe-пристроїв (поширено при недонавольтажних транзієнтах)

cr0x@server:~$ journalctl -k | egrep -i "pcie.*error|AER|link down|link reset|Surprise Down" | tail -n 25
Jan 22 08:11:59 server kernel: pcieport 0000:00:1c.0: AER: Corrected error received: 0000:00:1c.0
Jan 22 08:11:59 server kernel: pcieport 0000:00:1c.0: PCIe Bus Error: severity=Corrected, type=Physical Layer
Jan 22 08:12:00 server kernel: pcieport 0000:00:1c.0: device [8086:a110] error status/mask=00000001/00002000

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

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

Завдання 9: Перевірте стабільність SATA/NVMe-лінків

cr0x@server:~$ dmesg -T | egrep -i "ata[0-9]|link down|hard resetting link|nvme.*reset" | tail -n 30
[Mon Jan 22 08:12:03 2026] ata3: SATA link down (SStatus 0 SControl 300)
[Mon Jan 22 08:12:03 2026] ata3: hard resetting link
[Mon Jan 22 08:12:05 2026] ata3: SATA link up 6.0 Gbps (SStatus 133 SControl 300)
[Mon Jan 22 08:12:06 2026] nvme nvme0: controller is down; will reset: CSTS=0x1

Що це означає: Лінки сховища не повинні флапати в здоровому сервері. Просідання живлення може викликати скидання контролерів.

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

Завдання 10: Навантажте CPU, щоб відтворити транзієнтні проблеми (контрольований тест)

cr0x@server:~$ sudo apt-get update -qq && sudo apt-get install -y stress-ng
Reading package lists... Done
Building dependency tree... Done
The following NEW packages will be installed:
  stress-ng
0 upgraded, 1 newly installed, 0 to remove and 0 not upgraded.
Setting up stress-ng (0.17.12-1ubuntu0.1) ...

cr0x@server:~$ sudo stress-ng --cpu 0 --cpu-method matrixprod --timeout 120s --metrics-brief
stress-ng: info:  [21412] dispatching hogs: 32 cpu
stress-ng: metrc: [21412] stressor       bogo ops real time  usr time  sys time   bogo ops/s
stress-ng: metrc: [21412] cpu               5231    120.00  3790.11     0.31        43.59
stress-ng: info:  [21412] successful run completed in 120.02s

Що це означає: Якщо це послідовно викликає перезавантаження або скидання пристроїв — у вас проблема з доставкою живлення, терміками або VRM плати.

Рішення: Якщо відмови з’являються під цим тестом, поміняйте БЖ і повторіть тест, перш ніж звинувачувати kernel/app.

Завдання 11: Моніторинг напруг і температур під навантаженням (lm-sensors)

cr0x@server:~$ sudo apt-get install -y lm-sensors
Reading package lists... Done
Building dependency tree... Done
The following NEW packages will be installed:
  lm-sensors
Setting up lm-sensors (1:3.6.0-7.1ubuntu1) ...

cr0x@server:~$ sensors
coretemp-isa-0000
Adapter: ISA adapter
Package id 0:  +71.0°C  (high = +90.0°C, crit = +100.0°C)
Core 0:        +67.0°C  (high = +90.0°C, crit = +100.0°C)

nct6798-isa-0a20
Adapter: ISA adapter
in0:          +1.02 V
in1:          +1.81 V
in2:          +12.00 V
in3:          +5.02 V
in4:          +3.33 V
fan1:        1200 RPM

Що це означає: Ці показники можуть бути приблизними, але ви шукаєте дрейф або раптові падіння під навантаженням.

Рішення: Якщо 12V/5V сильно падають під стресом — зупиніться: шлях PSU/VRM нестабільний.

Завдання 12: Перевірка помилок пам’яті (жива може маскуватися як проблеми з RAM)

cr0x@server:~$ journalctl -k | egrep -i "EDAC|ecc|memory error" | tail -n 20
Jan 22 08:11:58 server kernel: EDAC MC0: 1 CE memory read error on CPU_SrcID#0_Ha#0_Chan#1_DIMM#0
Jan 22 08:11:58 server kernel: EDAC sbridge MC0: HANDLING MCE MEMORY ERROR

Що це означає: Correctable errors (CE) можуть бути реальним деградуючим DIMM, але спалахи, що збігаються з подіями живлення, підозрілі.

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

Завдання 13: Перевірте файлову систему і блок-слой на I/O-помилки після подій

cr0x@server:~$ journalctl -p err..alert -b | egrep -i "I/O error|EXT4-fs error|XFS.*CORRUPT|blk_update_request|Buffer I/O" | tail -n 30
Jan 22 08:12:01 server kernel: blk_update_request: I/O error, dev nvme0n1, sector 428032, op 0x1:(WRITE) flags 0x800 phys_seg 1 prio class 0
Jan 22 08:12:01 server kernel: Buffer I/O error on dev nvme0n1p2, logical block 53504, lost async page write

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

Рішення: Не починайте міняти диски навмання. Стабілізуйте живлення, потім запустіть SMART/self-tests.

Завдання 14: Перевірте SMART і логи помилок (щоб відокремити «поганий диск» від «поганого живлення»)

cr0x@server:~$ sudo smartctl -a /dev/sda | egrep -i "Reallocated_Sector_Ct|Current_Pending_Sector|UDMA_CRC_Error_Count|Power_Cycle_Count|Power-Off_Retract_Count"
Reallocated_Sector_Ct     0
Current_Pending_Sector    0
UDMA_CRC_Error_Count      19
Power_Cycle_Count         142
Power-Off_Retract_Count   27

Що це означає: UDMA CRC помилки часто вказують на кабель або сигнал. Зростаючий «Power-Off Retract» рахує вказує на різку втрату живлення.

Рішення: Якщо CRC-помилки ростуть — огляньте/замініть SATA-кабелі і жгут живлення; якщо лічильники вимкнень ростуть — полагодьте шлях PSU/UPS.

Завдання 15: Перевірте частоти CPU на тротлінг (взаємодія живлення/терміки)

cr0x@server:~$ sudo apt-get install -y linux-tools-common linux-tools-generic
Reading package lists... Done
Building dependency tree... Done
The following NEW packages will be installed:
  linux-tools-common linux-tools-6.8.0-41-generic linux-tools-generic
Setting up linux-tools-common (6.8.0-41.41) ...
Setting up linux-tools-generic (6.8.0-41.41) ...

cr0x@server:~$ sudo turbostat --Summary --quiet --show Busy%,Bzy_MHz,TSC_MHz,PkgTmp --interval 1 --num_iterations 5
Busy%   Bzy_MHz  TSC_MHz  PkgTmp
12.34   2101     2200     74
89.02   3298     2200     89
91.11   2980     2200     94
88.50   2750     2200     96
90.20   2605     2200     97

Що це означає: Зниження Bzy_MHz при високому Busy% і зростаюча температура пакета вказують на тротлінг. Тротлінг змінює патерни навантаження і може виставити слабкі місця PSU.

Рішення: Виправте охолодження, якщо ви близькі до теплових лімітів; потім оцініть стабільність БЖ в очікуваних температурних умовах.

Завдання 16: Якщо подвійний БЖ, протестуйте резервування під навантаженням (контрольовано)

cr0x@server:~$ sudo stress-ng --cpu 0 --timeout 60s --metrics-brief
stress-ng: info:  [21901] dispatching hogs: 32 cpu
stress-ng: info:  [21901] successful run completed in 60.01s

cr0x@server:~$ ipmitool sel clear
Clearing SEL.  Please allow a few seconds to erase.

cr0x@server:~$ ipmitool sel list
SEL has no entries

Що це означає: Очищення SEL дозволяє побачити нові події резервування під час контрольованого тесту (коли фізично витягуєте один БЖ).

Рішення: Якщо витягнення PSU A викликає нестабільність, а витягнення PSU B — ні, підозрюйте PSU A (або його фід/кабель).

Примітка: ваші руки — не команда. Але вони частина діагностичного набору. Якщо ви робите фізичні тести — робіть їх у вікні обслуговування, під наглядом,
і з чітким планом відкату.

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

1) «Випадкові перезавантаження, немає логів» → brownout/проблеми з часом утримання → тест і заміна

Симптом: Система перезапускається без коректного завершення; логи показують розрив.

Корінь проблеми: Вихід БЖ опускається нижче допуску під час транзієнту або просідання AC; час утримання занадто короткий.

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

2) «NVMe зникає, потім повертається» → транзієнтний недонавольтаж → покращити транзієнтну відповідь БЖ

Симптом: Цикли скидання NVMe, IO-помилки, тригерні rebuild RAID.

Корінь проблеми: Скидання PCIe-пристроїв спричинене короткими просіданнями 12V або шумною шиною.

Виправлення: Замініть БЖ на той, що має кращу транзієнтну віддачу; зменшіть пікові навантаження; перевірте кабелі та живлення бекплейна.

3) «SATA CRC помилки ростуть» → поганий кабель або слабкий жгут живлення → замініть потрібний кабель

Симптом: SMART показує зростання UDMA_CRC_Error_Count; диски відвалюються під навантаженням.

Корінь проблеми: Проблема сигналу кабелю (SATA, бекплейн), іноді посилюється ripple і нагрівом конекторів.

Виправлення: Замініть SATA-кабелі/бекплейн-конектори; огляньте потемнілі силові конектори; забезпечте щільні, чисті з’єднання.

4) «ECC correctable errors стрибають лише під важким IO» → шум в живленні → спочатку виправити живлення

Симптом: Вибухи коригованих помилок пам’яті під scrub/backups.

Корінь проблеми: Шум у доставці живлення спричиняє маргінальні таймінги; може здаватися проблемою RAM.

Виправлення: Перевірте шини БЖ і замініть БЖ перед заміною DIMM; потім повторно протестуйте.

5) «Лише коли жарко» → старіння конденсаторів і термодеградація → повітрообмін і якісний БЖ

Симптом: Стабільно взимку або при відкритому корпусі; відмови при літній температурі або високих обертах вентиляторів.

Корінь проблеми: Внутрішні температури дешевого БЖ зростають; конденсатори втрачають ємність; регуляція погіршується.

Виправлення: Покращіть потік повітря в корпусі, прочистіть пил і замініть БЖ на модель з вищим температурним рейтингом; уникайте роботи біля максимального навантаження.

6) «Вентилятор БЖ вояє, потім зупиняється, і сервер помирає» → збій вентилятора/некоректна OTP → негайно замінити

Симптом: Поведінка вентилятора БЖ непередбачувана; переривчасті вимкнення.

Корінь проблеми: Вихід підшипника вентилятора або поганий тепловий контроль; OTP може спрацьовувати невчасно.

Виправлення: Замініть БЖ. Не «лише міняйте вентилятор» у продакшні, якщо ви не любите ризики з кавою.

7) «Ми помінили диски і все ще відбувається» → ганяєте жертву, а не нападника → зупиніться і перевізьміть базу

Симптом: Кілька замін компонентів не вирішують перезавантаження і IO-помилки.

Корінь проблеми: БЖ або upstream-живлення спричиняє каскадні помилки по пристроях.

Виправлення: Перебазуйте: корелюйте скидання з сенсорами живлення; зробіть заміну на відомо робочий БЖ; перевірте поведінку PDU/UPS.

8) «Бренд означає безпеку» → варіації моделі/платформи → кваліфікуйте конкретний блок

Симптом: «Але це від відомого бренду» — а проблеми тривають.

Корінь проблеми: Бренди аутсорсять; якість залежить від платформи, ревізії і OEM.

Виправлення: Обирайте БЖ за підтвердженою електричною продуктивністю і захистами, а не за логотипом; стандартизуйте на відомо добрих моделях.

Контрольні списки / покроковий план

Чекліст закупівлі: як не купити проблеми

• Купуйте за електричною поведінкою, а не за ватажем. Шукайте незалежну валідацію ripple, транзієнтної відповіді, захистів і часу утримання.
• Плануйте запас. Ціль — типовий рівень навантаження близько 40–60% від рейтингу БЖ для ефективності і запасу по транзієнтах (точні числа залежать від платформи, але «біля максимуму» — це запрошення проблем).
• Віддавайте перевагу сучасним DC-DC дизайнам для другорядних шин в ATX-системах і надійним серверним БЖ для рейкового обладнання.
• Перевіряйте якість конекторів і перерізи жгутів. Особливо для GPU і вузлів з великою кількістю дисків.
• Стандартизуйте моделі. Менше SKU БЖ — менше невідомих і швидші заміни.
• Вирішіть стратегію резервування заздалегідь. Dual-PSU з окремими фідами, якщо важлива доступність; single PSU плюс холодна запаска — якщо ні.

Чекліст складання: деталі установки, що запобігають відмовам

• Використовуйте окремі PDU/лінії для резервних БЖ. «Два БЖ в одну і ту ж розетку» — це театральність.
• Маркуйте відповідність PSU→PDU. Люди відлагоджують швидше, коли фізичний світ задокументований.
• Не перевантажуйте один жгут кабелів. Уникайте різких вигинів і натягу на конекторах.
• Для серверів зі сховищем перевірте розподіл живлення по дисках. Затримуйте старт обертання, якщо можливо.
• Налаштуйте моніторинг на втрачене резервування БЖ, події напруги (якщо доступно) і несподівані перезавантаження.

Операційний чекліст: коли хост починає поводитись ніби з привидом

1. Заморозьте ризикові записи: призупиніть scrub/rebuild/backfill, якщо система флапає.
2. Класифікуйте відмову: жорсткий ресет проти коректного рестарту проти скидань пристроїв.
3. Зберіть логи: last -x, journalctl -k, SMART, BMC SEL.
4. Корелюйте з навантаженням: чи був спайк задачі, бекап або компіляційний шторм?
5. Перевірте upstream: переходи UPS, алерти PDU, спрацьовування автоматів.
6. Поміняйте на відомо робочий БЖ (або поміняйте позиції з БЖ у шасі з двома блоками).
7. Повторіть контрольований стрес і підтвердіть стабільність перед закриттям інциденту.
8. Напишіть коротку замітку інциденту: що бачили, що змінили і що замінили.

Чекліст проєктування: специфіки для сховищ і віртуалізації

• ZFS/RAID масиви: віддавайте перевагу стабільному живленню і UPS; уникайте нестабільного brownout-поведінки, що викликає повторні скидання пристроїв.
• Ноди з великою кількістю SSD: розгляньте диски з захистом від втрати живлення; дешеві БЖ плюс споживчі SSD — поганий тандем.
• GPU-ноді: пріоритезуйте кабелі, якість конекторів і транзієнтну відповідь; GPU дають пік-струми.
• Хости віртуалізації: подвійні БЖ, окремі фіди і алерти про втрату резервування — обов’язкові, якщо вам важлива доступність.

FAQ

1) Чи достатньо 80 PLUS Gold, щоб гарантувати хороший БЖ?

Ні. Він переважно говорить про ефективність у конкретних точках навантаження. БЖ може бути ефективним і водночас мати посередній ripple, слабку транзієнтну відповідь
або погано налаштовані захисти. Сприймайте 80 PLUS як «одну точку даних», а не як сертифікат безпеки.

2) Який найпоширеніший реальний симптом поганого БЖ?

Жорсткі перезавантаження під навантаженням. Особливо у поєднанні зі скиданнями лінків сховища (SATA/NVMe) або PCIe AER помилками.

3) Чи може дешевий БЖ викликати корупцію даних без перезавантаження?

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

4) Якщо моя система запускає ігри, чому вона не витримає серверного навантаження?

Сервери часто працюють зі стабільним високим IO і тривалим навантаженням CPU годинами, плюс одночасні спалахи (scrub, backup, compaction).
Споживчі «вдома на столі» тести не покривають такі патерни або температурне середовище стійки.

5) Який запас варто залишати при підборі БЖ?

Достатній, щоб звичайна робота не була біля урвища. Практична ціль — тримати типовий рівень навантаження в межах 40–60% і забезпечити, щоб пікові спалахи
комфортно залишались нижче безперервного рейтингу БЖ. Точний запас залежить від транзієнтів (GPU-ноди потребують більше).

6) Чи сумісні модульні кабелі між брендами БЖ?

Зазвичай ні, і «зазвичай» — не стратегія ризику. Розводки контактів різняться навіть у межах одного бренду між лінійками.
Змішування кабелів може миттєво вбити диски і материнські плати. Використовуйте лише кабелі, призначені для конкретної моделі БЖ.

7) Чи робить UPS дешеві БЖ безпечними?

UPS допомагає при відключеннях і деяких аномаліях живлення, але не виправляє погану транзієнтну відповідь або високий ripple.
Також деякі БЖ поводяться погано під час подій перемикання UPS. Тестуйте саме вашу комбінацію.

8) А що з резервними БЖ — чи можна поставити два дешевих і бути в порядку?

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

9) Як відрізнити проблему БЖ від VRM материнської плати?

Часто чисто відрізнити не так просто без заміни. Але патерни допомагають: проблеми з БЖ корелюють з AC/SEL подіями, множинними скиданнями пристроїв одночасно,
і змінюються при перестановці ліній живлення. Проблеми VRM можуть корелювати з конкретним навантаженням CPU і температурою і зберігатись після заміни БЖ.
В.ops ви зазвичай міняєте дешевший/швидший компонент першим — часто це БЖ.

10) Який найбезпечніший шлях оновлення для хомлаб-коробки зі сховищем?

Купіть відомо хороший БЖ з сильними захистами і достатнім запасом, поставте систему на UPS і не змішуйте модульні кабелі.
Якщо у вас важливі дані — пріоритет надавайте стабільності більше, ніж естетиці та RGB-фічам.

Наступні кроки, які ви реально можете зробити цього тижня

Якщо ви керуєте продукційними системами, ставтеся до БЖ як до шин на флоті авто: ви не купуєте найдешевші і сподіваєтеся, що водії стануть кращими у фізиці.
Якість живлення — фундамент. Усе інше від нього залежить.

Практичні дії

• Інвентаризація БЖ (модель і part number) по флоту через BMC де доступно, і визначте невідомі/низької довіри одиниці.
• Обрати одну-дві стандартизовані, перевірені моделі БЖ для кожного класу шасі (сховище, обчислення, GPU) і припинити імпровізації при закупівлі.
• Впровадити алерти на несподівані перезавантаження, «PSU redundancy lost» і пороги напруги BMC.
• Запустити контрольований стрес-тест на новому обладнанні під час burn-in і слідкувати за сигналами БЖ/PCIe/сховища.
• Тримати холодні запаски стандартизованих моделей БЖ. Найшвидший інцидент — той, що ви закінчили заміною і записом.
• Для критичних сервісів, переходьте на dual-PSU з окремими фідами і тестуйте failover щоквартально — нудно, передбачувано, ефективно.

Якщо ви досі спокусилися купити БЖ із секції «bargain bin», задайте інше питання: «Яка моя погодинна ставка під час простою?»
Раптом ці $20 починають виглядати як кредит з агресивними відсотками.