Забута захисна плівка на кулері: найкумедніша причина перегріву

November 29, 2025 • February 3, 2026 • Читання: 4 хв • Views: 0

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

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

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

Чому захисна плівка на кулері може зупинити продакшн

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

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

Кристал (Die) → IHS (внутрішній шлях пакета CPU, поза вашим контролем).
IHS → термопаста (ваш контроль; тонко, рівномірно, без художніх експериментів).
Термопаста → холодна пластина (ваш контроль; чистий металевий контакт).
Холодна пластина → теплові трубки/радіатор (дизайн кулера).
Радіатор/ребра → повітряний потік (корпус або шасі, криві вентиляторів, перешкоди).

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

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

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

Жарт №1 (коротко, по темі): Захисна плівка на кулері — єдина захисна плівка, яка успішно блокує тепло замість хакерів.

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

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

Перший: підтвердіть, що це термальне, а не «просто повільно»

Шукайте тротлінг: частота CPU падає під навантаженням, незважаючи на високе завантаження.
Перевірте температури: температура пакета CPU близько або біля TjMax; також високі температури GPU/NVMe, якщо релевантно.
Шукайте термальні події: логи ядра, IPMI SEL, сигнали сенсорів BMC.

Другий: визначте обсяг та радіус ураження

Один вузол чи багато? Якщо багато — підозрюйте навколишній повітряний потік, політику керування вентиляторами, розгортання прошивки або забиті фільтри.
Специфічне навантаження? Лише під AVX-важкими обчисленнями, тривалим компактуванням, відновленням або шифруванням?
Часова кореляція? Те ж саме кожного дня може бути пакетними завданнями, але також може бути розклад повітряного обігріву або звички закривати двері стійки.

Третій: оберіть найбезпечніший шлях пом’якшення

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

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

Цікаві факти та трохи історії

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

Термальний тротлінг — не сучасний винахід. CPU мають форми термозахисту десятиліттями; сучасні чіпи просто роблять його динамічнішим і менш помітним.
Захисні плівки стали більш поширеними з ростом преміум-кулерів. Холодні пластини з дзеркальним фінішем і попередньо нанесена паста постачаються з плівками, щоб уникнути забруднень і подряпин.
Паста — не клей. Її завдання — заповнювати мікроскопічні порожнини; метал-до-металу контакт залишається основним шляхом теплопередачі.
Керування вентиляторами змінилося від простого напруження до інтелектуальних кривих. PWM-керування і політики BMC можуть приховувати поганий контакт, «врятувавши» вас в режимі простою й зазнавати невдач при тривалому навантаженні.
Дата-центри все частіше працюють при вищих температурах на вході. Мета ефективності тисне на тепліший повітряний простір; запас для «малих» помилок зменшується.
NVMe приніс нові термальні вузькі місця. Сучасні SSD тротлять за температурою і можуть виглядати як «затримка сховища», а не як «теплова проблема».
AVX та схожі набори інструкцій можуть змінювати тепловий профіль. Той самий CPU при однаковому завантаженні може працювати значно гарячіше залежно від набору інструкцій.
Віддалене керування зробило «ручну» операцію рідшою. IPMI/BMC-інструменти спростили роботу без рук, але деякі відмови вимагають очей та викрутки.
Термопрокладки на VRM і пам’яті існують не просто так. Неправильне вирівнювання при збірці може перегріти підсистеми живлення, тоді як CPU здається в нормі, викликаючи дивні перезавантаження та WHEA-помилки.

Як це виглядає в логах, метриках та у відгуках користувачів

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

Поширені поверхневі симптоми

Випадкові перезавантаження під навантаженням (термальне вимкнення або захист VRM).
Раптові сплески затримки (CPU тротлить; черги зростають).
Непослідовні результати бенчмарків (термальний баланс змінює результати з прогону в прогін).
«Сховище стало повільним» (NVMe тротлить — латентність IO стрибкоподібна, а часи компактування/відновлення зростають у рази).
Частота CPU застрягла низько незважаючи на достатній запас на папері.
Повідомлення ядра про термальні зони або підказки на кшталт «CPU throttled».
Аларми сенсорів IPMI (CPU Temp, VRM Temp, System Temp) або записи в SEL.

Що насправді відбувається

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

У продакшні тротлінг особливо підступний, бо він нелінійний. Можна бути в нормі при 55% навантаженні, а потім
вдаритися в «коліно» і впасти з урвища при 70%. Ваше планування ємності виглядає правильним — поки раптом ні.

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

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

Завдання 1: Перевірка поточних частот CPU (підказка на тротлінг)

cr0x@server:~$ lscpu | egrep 'Model name|CPU\(s\)|Thread|MHz'
Model name:                           Intel(R) Xeon(R) CPU
CPU(s):                               32
Thread(s) per core:                   2
CPU MHz:                              1197.843

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

Завдання 2: Спостерігати частоту під навантаженням в реальному часі

cr0x@server:~$ sudo apt-get -y install linux-tools-common linux-tools-generic >/dev/null
cr0x@server:~$ sudo turbostat --Summary --interval 2
turbostat version 2024.01
Summary: 2 sec
Avg_MHz   Busy%   Bzy_MHz  TSC_MHz  PkgTmp  PkgWatt
1680      92.15   1822     2300     97      182.4

Значення: Температура пакета 97°C з зайнятими ядрами і нижчою, ніж очікується, Bzy_MHz — крик про термальне обмеження.
Рішення: Підтвердіть температури через sensors/IPMI і плануйте негайні заходи (злив/зниження навантаження).

Завдання 3: Прочитати термальні сенсори локально (lm-sensors)

cr0x@server:~$ sudo apt-get -y install lm-sensors >/dev/null
cr0x@server:~$ sudo sensors
coretemp-isa-0000
Adapter: ISA adapter
Package id 0:  +98.0°C  (high = +84.0°C, crit = +100.0°C)
Core 0:        +96.0°C  (high = +84.0°C, crit = +100.0°C)
Core 1:        +97.0°C  (high = +84.0°C, crit = +100.0°C)

Значення: Ви ковзаєте по критиці. Перевищення «high» означає, що ймовірно відбувається тривале тротлінг.
Рішення: Якщо це нова або нещодавно обслугована система — пріоритет фізичної інспекції (монтаж/паста/плівка).

Завдання 4: Перевірити ядро на термальні події

cr0x@server:~$ sudo dmesg -T | egrep -i 'thermal|thrott|critical|overheat' | tail -n 8
[Mon Jan 22 10:41:12 2026] CPU0: Package temperature above threshold, cpu clock throttled
[Mon Jan 22 10:41:12 2026] CPU2: Package temperature above threshold, cpu clock throttled
[Mon Jan 22 10:41:15 2026] CPU0: Core temperature/speed normal

Значення: Ядро каже, що воно тротлило. Це не «можливо».
Рішення: Трактуйте це як причину інциденту, а не як випадковий рядок у логах; відрегулюйте ємність і виправте охолодження.

Завдання 5: Підтвердити RPM вентиляторів і системні температури через IPMI

cr0x@server:~$ sudo apt-get -y install ipmitool >/dev/null
cr0x@server:~$ sudo ipmitool sdr type Temperature
CPU Temp         | 98 degrees C      | critical
System Temp      | 36 degrees C      | ok
VRM Temp         | 92 degrees C      | non-critical

Значення: Температура на вході/системи в порядку; CPU/VRM гарячі. Це відводить від «в кімнаті жарко» до «контакт/повітряний потік всередині».
Рішення: Якщо вентилятори вже на максимумі — підозрюйте заблокований радіатор, поганий монтаж, плівку або збій помпи (AIO).

Завдання 6: Перевірити сенсори вентиляторів через IPMI

cr0x@server:~$ sudo ipmitool sdr type Fan
FAN1             | 17600 RPM         | ok
FAN2             | 17400 RPM         | ok
FAN3             | 17100 RPM         | ok
FAN4             | 0 RPM             | critical

Значення: Один вентилятор мертвий або відключений. У деяких шасі відсутній вентилятор руйнує шаблон тиску.
Рішення: Спочатку замініть/пересіть вентилятор. Якщо всі вентилятори в порядку, а температури все ще стрибали — переходьте до інтерфейсу холодної пластини.

Завдання 7: Прочитати System Event Log IPMI для причин вимкнення

cr0x@server:~$ sudo ipmitool sel elist | tail -n 6
1a2 | 01/22/2026 | 10:42:01 | Temperature CPU Temp | Upper Critical going high
1a3 | 01/22/2026 | 10:42:05 | Processor #0 | Thermal Trip
1a4 | 01/22/2026 | 10:42:06 | System Boot Initiated | Initiated by power reset

Значення: Thermal trip передував ресету. BMC це зафіксував.
Рішення: Перестаньте звинувачувати гіпервізор. Виправляйте охолодження. Збережіть логи для постмортему.

Завдання 8: Підтвердити споживання енергії та поведінку лімітів потужності (RAPL / turbostat)

cr0x@server:~$ sudo turbostat --Summary --interval 2 | head -n 4
turbostat version 2024.01
Summary: 2 sec
Avg_MHz   Busy%   Bzy_MHz  PkgTmp  PkgWatt
1450      88.40   1601     99      205.7

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

Завдання 9: Застосувати тимчасове обмеження потужності CPU (безпечна міра)

cr0x@server:~$ sudo apt-get -y install linux-tools-common linux-tools-generic >/dev/null
cr0x@server:~$ sudo powercap-info -p intel-rapl:0
Zone intel-rapl:0
  enabled: 1
  constraint_0_power_limit_uw: 220000000
  constraint_1_power_limit_uw: 250000000
cr0x@server:~$ echo 160000000 | sudo tee /sys/class/powercap/intel-rapl:0/constraint_0_power_limit_uw
160000000

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

Завдання 10: Коротко навантажити для відтворення без ризику пошкодження

cr0x@server:~$ sudo apt-get -y install stress-ng >/dev/null
cr0x@server:~$ sudo stress-ng --cpu 0 --cpu-method matrixprod --timeout 30s --metrics-brief
stress-ng: info:  [21432] dispatching hogs: 32 cpu
stress-ng: info:  [21432] successful run completed in 30.01s
stress-ng: info:  [21432] cpu: 960.00 bogo ops/s

Значення: Ви створили відтворюване термальне навантаження. Поєднайте це з sensors/turbostat, щоб побачити швидкість наростання температури.
Рішення: Якщо температура підскакує до високих 90°C за секунди і вентилятори на максимумі — зупиніться і інспектуйте монтаж/плівку/помпу.

Завдання 11: Перевірити термальне тротлінг NVMe («таємна повільність» сховища)

cr0x@server:~$ sudo apt-get -y install nvme-cli >/dev/null
cr0x@server:~$ sudo nvme smart-log /dev/nvme0 | egrep 'temperature|warning|critical'
temperature                             : 78 C
warning_temp_time                       : 134
critical_comp_time                      : 0

Значення: NVMe гарячий і вже проводив час вище порогу попередження. Воно може вже тротлити.
Рішення: Додайте потік повітря над NVMe, перевірте радіатори, і перестаньте вважати диск «повільним». Можливо він «гарячий».

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

cr0x@server:~$ sudo dmesg -T | egrep -i 'aer|pcie|corrected|whea' | tail -n 6
[Mon Jan 22 10:39:44 2026] pcieport 0000:00:1c.0: AER: Corrected error received: id=00e0
[Mon Jan 22 10:39:44 2026] AER: PCIe Bus Error: severity=Corrected, type=Physical Layer

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

Завдання 13: Перевірити режим/політику BMC вентиляторів (неправильна налаштування може маскувати апаратний збій)

cr0x@server:~$ sudo ipmitool raw 0x30 0x45 0x00
01

Значення: Залежить від постачальника, але часто повертає поточний режим вентиляторів (наприклад, «standard» vs «full»).
Рішення: Якщо політика занадто тиха для вашого термального профілю — тимчасово перемкніть на вищий режим; потім перегляньте повітряні потоки.

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

cr0x@server:~$ kubectl get nodes
NAME           STATUS     ROLES    AGE   VERSION
worker-07      NotReady   <none>   18d   v1.29.2
worker-08      Ready      <none>   18d   v1.29.2
cr0x@server:~$ kubectl describe node worker-07 | egrep -i 'Ready|KubeletNotReady|reboot|pressure' | tail -n 8
Ready                False   Mon, 22 Jan 2026 10:42:15 +0000   KubeletNotReady   runtime network not ready
Ready                True    Mon, 22 Jan 2026 10:30:02 +0000   KubeletReady      kubelet is posting ready status

Значення: Флапи вузла. «Runtime network not ready» може бути побічним ефектом раптових ресетів.
Рішення: Перевірте BMC SEL і температури, перш ніж ганятися за привидами CNI три години.

Завдання 15: Підтвердити недавнє обслуговування (інциденти з плівкою корелюють зі «ми торкалися»)

cr0x@server:~$ last -x | head -n 8
reboot   system boot  6.8.0-40-generic Mon Jan 22 10:42   still running
shutdown system down  6.8.0-40-generic Mon Jan 22 10:41 - 10:42  (00:00)
reboot   system boot  6.8.0-40-generic Mon Jan 22 10:12 - 10:41  (00:29)

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

Завдання 16: Якщо потрібно відкрити корпус — документуйте й перевіряйте візерунок контакту

cr0x@server:~$ sudo mkdir -p /var/tmp/thermal-incident && sudo date | sudo tee /var/tmp/thermal-incident/notes.txt
Mon Jan 22 10:55:03 UTC 2026

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

Жарт №2 (коротко, по темі): Якщо ваш CPU досягає 100°C при повністю працюючих вентиляторах, це не «турбо-режим» — це «будь ласка, зніміть пластик».

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

Міні-історія 1: Інцидент через неправильне припущення

Середня компанія розгорнула нову партію обчислювальних вузлів для CI та ефемерних середовищ. Залізо постачали змонтованим постачальники, образували в локальній мережі, а потім приєднували до кластера. Два дні все виглядало гаразд — бо робочі навантаження були спайковими і короткими.

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

Неправильне припущення було тонким: «Якщо воно завантажується і проходить 10-хвилинний smoke test — термічні умови в нормі». Це не було в нормі.
Smoke test ніколи не досягав стаціонарного стану. Під тривалим навантаженням CPU досягали термальних порогів, обмежували частоту і потім спрацьовували тріпи. Деякі вузли відновлювалися; інші потрапляли в цикли перезавантажень, які виглядали як проблеми провізування.

Кінцева підказка прийшла від однієї людини, яка перестала читати софт-логи і витягла дані IPMI. Критичні події температури CPU збіглися з тайм-аутами задач. Технік відкрив один корпус. На холодній пластині досі була захисна плівка.

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

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

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

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

Оптимізація повернулася бумерангом, бо звузила запас. При менших оборотах вентилятора будь-яка додаткова термальна опірність — пил, старіша паста, трохи перекошене притискання радіатора або, так, забута плівка після заміни CPU — виводила систему за межі. Те саме залізо, що витримувало помилки на «повних вентиляторах», не витримувало на «еко».

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

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

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

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

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

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

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

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

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

1) Вентилятори на 100%, CPU все одно досягає 95–100°C швидко → поганий інтерфейс холодної пластини → перемонтувати, зняти плівку, заново нанести пасту

Симптом: Швидке наростання температури; тротлінг у dmesg; вентилятори виють.
Корінь: Залишена захисна плівка, нерівномірний тиск монтажу або неправильне нанесення пасти (занадто багато, занадто мало або забруднено).
Виправлення: Вимкніть живлення, зніміть кулер, очистіть ізопропіловим спиртом, зніміть плівку, нанесіть пасту правильно, затягуйте по діагоналі до специфікації.

2) Температури CPU у нормі, але система перезавантажується під навантаженням → перегріваються VRM або чіпсет → відновити обдув і перевірити прокладки

Симптом: Температура пакета CPU виглядає безпечною, але SEL показує попередження VRM або події «power unit».
Корінь: Відсутній повітряний канал, мертвий вентилятор або неправильно вирівняна термопрокладка VRM після сервісу.
Виправлення: Замініть вентилятор, відновіть щитки/повітряні направлячі, перевірте радіатори та прокладки, переконайтеся в правильному тиску повітря в корпусі.

3) Затримки в роботі сховища, CPU здається нормальним → NVMe термальне тротлінг → встановіть радіатори/потік, перемістіть накопичувачі

Симптом: Рандомні стрибки IO-латентності; температури NVMe 70–85°C; warning_temp_time росте.
Корінь: Диски без обдуву, відсутні радіатори або розташовані за гарячими GPU.
Виправлення: Встановіть радіатори для NVMe, покращіть шлях повітря, використайте заповнювачі, розгляньте переміщення високонавантажених дисків у кращо охолоджувані відсіки.

4) Лише певні навантаження викликають проблеми → інструкційна суміш підвищує тепло → встановіть ліміти потужності або розклад робіт

Симптом: Нормально для більшості завдань; відмови під специфічними обчисленнями (векторна математика, стиснення, шифрування, важкі відновлення).
Корінь: Навантаження генерує вищу постійну потужність; запас охолодження недостатній.
Виправлення: Застосуйте ліміти потужності, налаштуйте турбо-поведінку, плануйте важкі роботи на прохолодніші вікна або оновіть охолодження/повітряний потік.

5) Після оновлення прошивки температури змінилися → змінилася політика керування вентиляторами → зафіксуйте політику або переналаштуйте криві

Симптом: «Минулого тижня було норм» без змін заліза, але вентилятори тепер працюють тихіше і піднімаються пізніше.
Корінь: Оновлення BMC/BIOS змінило криві вентиляторів або інтерпретацію сенсорів.
Виправлення: Перевірте налаштування режиму вентиляторів, порівняйте з базовим профілем, зафіксуйте відомо-робочу політику і оновіть автоматизацію перевірок.

6) Один вузол у стійці перегрівається більше, ніж сусіди → локальна перешкода повітряного потоку → виправте маршрути кабелів, заповнювачі, двері

Симптом: Ті самі моделі серверів, те саме навантаження; один працює гарячіше.
Корінь: Пучок кабелів блокує всмоктування, відсутні заповнювачі панелей, часткова перешкода або відмовив вентилятор.
Виправлення: Відновіть передньо-задній потік повітря, замініть вентилятор, перемаршрутіть кабелі, встановіть заглушки.

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

Коли підозрюєте перегрів у продакшні (чекліст операцій)

Стабілізувати сервіс: злити робочі навантаження, знизити паралелізм або переключити на інші вузли, якщо можливо.
Підтвердити термальні дані: sensors + BMC/IPMI + логи. Не довіряйте одному джерелу.
Виміряти тротлінг: частота під навантаженням, а не в режимі простою.
Визначити обсяг: одиночний вузол проти ферми чи стійки.
Пом’якшити безпечно: тимчасовий ліміт потужності, вищий режим вентиляторів або зниження навантаження.
Запланувати ручну перевірку: якщо нове/обслуговане залізо — припускайте фізичну причину і плануйте контрольоване відключення.
Захопити постмортемні дані: SEL, dmesg, знімки сенсорів, часові співвідношення навантаження.

Коли збираєте або обслуговуєте сервер (чекліст апаратури)

Зніміть плівку з холодної пластини перед тим, як паста торкнеться чого-небудь.
Очистіть поверхні (IHS і холодну пластину) відповідним розчинником і безворсовими серветками.
Наносьте пасту правильно: послідовний метод, невелика кількість, без бульбашок, не використовуйте стару пасту повторно.
Монтируйте з рівномірним тиском: по діагоналі, правильний момент затягування, без «один кут повністю першим».
Підтвердіть підключення вентиляторів/помп до правильних заголовків материнської плати.
Перевірте повітряні частини: щитки, кожухи, заглушки, направляючі.
Запустіть тривале тестування: принаймні 20–30 хвилин під реальним навантаженням з фіксацією температур.
Занотуйте базову лінію: температура в спокої, температура під навантаженням, RPM вентиляторів, температура навколишнього середовища, споживання CPU.

Дерево рішень «підозра на плівку» (швидко і рішуче)

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

Питання та відповіді (FAQ)

1) Чи поширена помилка з плівкою на кулері в корпоративному середовищі?

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

2) Хіба система не повинна не завантажуватися, якщо плівка залишена?

Зазвичай вона завантажується. Ось чому це небезпечно. В режимі простою CPU може пережити погану теплопередачу. Під тривалим навантаженням — ні.

3) Чи може термопаста «пропалити» плівку або компенсувати її?

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

4) Як відрізнити плівку від мертвої помпи в AIO?

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

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

Тому що тротлінг підвищує латентність скрізь: затримки планування CPU, затримки обробки переривань, затримки відправлення IO. Додайте NVMe тротлінг — і от вам ідеальне відволікання.

6) Який безпечний «burn-in», щоб виявити це без ризику для заліза?

Контрольоване 20–30 хвилинне стійке навантаження (CPU stress плюс реалістичний IO, якщо це вузол сховища) з моніторингом температур, RPM вентиляторів і прапорів тротлінгу. Зупиніть, якщо наближаєтесь до критичних порогів.

7) Чи захищають сервери себе надійно від перегріву?

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

8) Чи варто тримати вентилятори на максимум завжди, щоб уникнути цього?

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

9) Що слід моніторити, щоб ловити термальні проблеми на ранніх стадіях?

Температура пакета CPU, частота CPU під навантаженням, RPM вентиляторів, споживання потужності і записи BMC SEL. Для вузлів сховища додайте температуру NVMe і індикатори тротлінгу.

10) Який найкращий «людський процес» як виправлення?

Двоосібний фізичний контроль для будь-яких робіт з кулером/CPU, плюс короткий тривалий тест з логуванням температур перед тим, як вузол повернеться в продакшн.

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

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

Парафраз ідеї W. Edwards Deming: «Ви не можете керувати тим, що не вимірюєте». У термальних питаннях це означає температуру, частоти, RPM вентиляторів і потужність — прив’язані до змін і подій обслуговування.

Додайте стійкий термальний приймальний тест для нових або обслугованих вузлів (з фіксацією температур і перевіркою тротлінгу).
Інструментуйте BMC/IPMI у ваш моніторинг, щоб термальні алерти не губилися за входом у веб-інтерфейс.
Закодуйте фізичний чекліст (включно з «зняти плівку з холодної пластини») і вимагайте двоосібної перевірки.
Визначте runbook пом’якшення: злити навантаження, встановити тимчасові ліміти потужності, підвищити політику вентиляторів, а потім запланувати фізичний ремонт.
Аудитуйте базові аспекти обдуву: заглушки, дисципліна кабелів, фільтри від пилу і стан вентиляторів.

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