Термопаста всюди: коли ентузіазм перемагає фізику

Фізика, з якою не домовишся

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

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

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

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

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

Одна цитата, яка має бути на стіні в кожній команді експлуатації, від Річарда Фейнмана:
Для успішної технології реальність має переважати над піаром, бо природу не обдуриш.
Коротко, грубо і правдиво.

Жарт №1: Термопаста як парфуми — якщо ви бачите її через всю кімнату, ви використали забагато.

Як виглядає правильно (і чому «горошина» не універсальна)

Інтернет любить «горошину». Це не помилка по суті, але не повна відповідь. Різні CPU мають різні розміри кристала під теплорозподільником.
Різні радіатори створюють різний розподіл тиску. Довгі прямокутні сокети (HEDT і серверні платформи) можуть залишати кути недозаповненими при «одній краплі».
Для великих IHS лінія або X можуть працювати краще.

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

Чому міф «більше пасти = краще охолодження» живе досі

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

У термінах серверів: паста — як кеш. Трохи — корисно. Уся пам’ять, що видає себе за кеш — це просто… пам’ять.

Факти й історичний контекст (без міфів)

• Факт 1: Рані електронні пристрої з великими потужностями десятиліттями використовували змазки й олії як інтерфейсні матеріали задовго до того, як «перепастинг» став хобі у ПК.
• Факт 2: «Термічний компаунд» став масовим у ПК із підвищенням щільності потужності CPU та коли блискучі поверхні перестали означати пласкі щодо тепла.
• Факт 3: Навіть полірувані метали мають мікроскопічні шорсткості; оптична гладкість — не те саме, що теплова гладкість.
• Факт 4: Типова теплопровідність пасти значно нижча за мідь; її цінність — у витісненні повітря, а не в обгоні металу.
• Факт 5: Існують фазові інтерфейсні матеріали (пади, що трохи розм’якшуються при робочій температурі) для спрощення консистентності складання у виробництві.
• Факт 6: «Pump-out» — реальне явище: термокерування й механічні напруження можуть з часом перемістити пасту від найгарячішої зони.
• Факт 7: Деякі пасти електропровідні (зокрема рідкі метали) і вимагають ізоляції, маскування та вищого рівня майстерності при монтажі.
• Факт 8: Багато серверних радіаторів інженерно розраховані на певний тиск кріплення та потік повітря; заміна на «післяринковий» варіант може порушити теплову модель.
• Факт 9: Термальне тротлінг у сучасних CPU став агресивнішим і дрібнішим; ви можете втратити продуктивність без аварій, і це робить помилку легко пропускаємою.

Що справді ламає «термопаста всюди»

Режим відмови 1: Збільшений тепловий опір через товстий TIM

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

Режим відмови 2: Поганий контакт через нерівномірний монтаж

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

Режим відмови 3: Паста в неправильних місцях

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

Режим відмови 4: Неправильна паста для профілю роботи

Десктопи і сервери живуть по-різному. Сервер може працювати під тривалим навантаженням, при підвищених вхідних температурах і постійному температурному циклюванні.
Деякі побутові пасти висихають, розшаровуються або «pump-out» швидше під такими умовами. Навпаки, деякі високопродуктивні суміші примхливі й вимагають досконалого монтажу
та підготовки поверхні.

Режим відмови 5: Полювання за пастою замість усунення проблем з потоком повітря

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

Жарт №2: Якщо ваше нанесення пасти виглядає як сучасне мистецтво, CPU відповість перформансом — в основному інтерпретативним тротлінгом.

План швидкої діагностики

Коли машина перегрівається після перепастингу — або починає тротлити під звичайними навантаженнями — не починайте знову відразу перепастувати.
Почніть з ізоляції вузького місця трьома проходами: (1) підтвердіть датчики і симптоми, (2) скореляйте з поведінкою живлення і частоти, (3) перевірте потік повітря і контакт.
Ви прагнете швидко відповісти на одне питання: обмежує чи фактор генерація тепла, передача тепла або видалення тепла?

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

• Перевірте температуру пакета CPU, дельти по ядрах/CCD і чи погоджується BMC з ОС.
• Шукайте прапорці термального тротлінгу і падіння частоти під навантаженням.
• Порівняйте з відомим робочим сусідом, якщо він у вас є.

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

• Чи викликано це навантаженням (тільки під AVX або стискуванням), часом (через 20 хвилин), чи навколишньою температурою (пік гарячого коридору)?
• Чи вентилятори розкручуються до максимуму? Якщо вентилятори низькі при гарячому CPU — підозрюйте політику управління вентиляторами/BMC.
• Чи є ви обмежені по потужності (пакетний power clamp), а не по теплу?

Третій крок: валідуйте потік повітря і механічний контакт

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

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

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

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

Завдання 1: Перевірка базових температур CPU і розкиду по ядрах

cr0x@server:~$ sensors
coretemp-isa-0000
Adapter: ISA adapter
Package id 0:  +86.0°C  (high = +90.0°C, crit = +100.0°C)
Core 0:        +85.0°C  (high = +90.0°C, crit = +100.0°C)
Core 1:        +86.0°C  (high = +90.0°C, crit = +100.0°C)
Core 2:        +68.0°C  (high = +90.0°C, crit = +100.0°C)
Core 3:        +69.0°C  (high = +90.0°C, crit = +100.0°C)

Значення: Два ядра приблизно на 17–18°C гарячіші за інші за схожих умов. Це не «потік корпусу»; це часто нерівномірний контакт або локальний гарячий
осередок.

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

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

cr0x@server:~$ watch -n 1 'sensors | egrep "Package id 0|Core 0|Core 2|fan"'
Every 1.0s: sensors | egrep Package id 0|Core 0|Core 2|fan

Package id 0:  +92.0°C
Core 0:        +91.0°C
Core 2:        +74.0°C
fan1:          8200 RPM
fan2:          8100 RPM

Значення: Вентилятори працюють на високих обертах; система намагається. Температури все ще високі з великим дельта. Видалення тепла працює;
підозра на передачу тепла (TIM/контакт).

Рішення: Перевірте прапорці тротлінгу; готуйтеся до переустановлення з правильним моментом затягування і кількістю пасти.

Завдання 3: Підтвердити частоту CPU і тротлінг під навантаженням

cr0x@server:~$ lscpu | egrep "Model name|CPU MHz|Thread|Socket"
Model name:                           Intel(R) Xeon(R) CPU
Thread(s) per core:                   2
Socket(s):                            2
CPU MHz:                              1199.992

Значення: Якщо під навантаженням ви бачите ~1.2 GHz на CPU, що має бути значно швидшим, ймовірно, відбувається тротлінг або обмеження по потужності.

Рішення: Перевірте журнали ядра на події термального тротлінгу і порівняйте з обмеженнями потужності.

Завдання 4: Шукати повідомлення про термальний тротлінг у логах ядра

cr0x@server:~$ sudo dmesg -T | egrep -i "thermal|throttl|PROCHOT|temperature" | tail -n 10
[Mon Jan 22 10:14:05 2026] CPU0: Package temperature above threshold, cpu clock throttled (total events = 37)
[Mon Jan 22 10:14:05 2026] CPU1: Package temperature above threshold, cpu clock throttled (total events = 37)

Значення: Це явний термальний тротлінг. Не «можливо». Не «користувач каже, що повільно».

Рішення: Визначте, чи це через потік повітря/вхідні умови, чи через поганий інтерфейс/монтаж, перевіривши вхід і управління вентиляторами.

Завдання 5: Зчитати дані сенсорів BMC/IPMI (температури, вентилятори, вхід)

cr0x@server:~$ sudo ipmitool sdr elist | egrep -i "inlet|ambient|cpu|fan" | head -n 12
Inlet Temp       | 24 degrees C      | ok
CPU1 Temp        | 91 degrees C      | ok
CPU2 Temp        | 89 degrees C      | ok
FAN1             | 8100 RPM          | ok
FAN2             | 8200 RPM          | ok
FAN3             | 7900 RPM          | ok

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

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

Завдання 6: Перевірити governor CPU і політику частоти (щоб уникнути самостійного тротлінгу)

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

Значення: Ви не випадково працюєте у «powersave». Добре. Якби був «powersave», ви могли б неправильно інтерпретувати низькі такти як тротлінг.

Рішення: Продовжуйте перевірки лімітів потужності/тепла, а не налаштування політики CPU.

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

cr0x@server:~$ sudo ipmitool dcmi power reading
    Instantaneous power reading:                   412 Watts
    Minimum during sampling period:                380 Watts
    Maximum during sampling period:                430 Watts
    Average power reading over sample period:      405 Watts
    IPMI timestamp:                           Mon Jan 22 10:20:10 2026
    Sampling period:                          00000010 Seconds.

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

Рішення: Якщо температури високі і такти низькі — це термальне питання. Якщо температури помірні і такти низькі — підозрюйте кап по потужності або BIOS-обмеження.

Завдання 8: Виявити, чи певний процес викликає сплеск тепла

cr0x@server:~$ top -b -n 1 | head -n 15
top - 10:22:31 up 18 days,  3:12,  1 user,  load average: 63.12, 58.77, 41.09
Tasks: 412 total,   2 running, 410 sleeping,   0 stopped,   0 zombie
%Cpu(s):  2.1 us,  0.3 sy,  0.0 ni, 97.4 id,  0.0 wa,  0.0 hi,  0.2 si,  0.0 st
MiB Mem : 257843.1 total,  98212.7 free,  40117.2 used, 119513.2 buff/cache
  PID USER      PR  NI    VIRT    RES    SHR S  %CPU  %MEM     TIME+ COMMAND
28412 app       20   0  12.3g  2.1g  112m R  780.0   0.8  12:31.44 compressor

Значення: Одне навантаження (стиснення/крипто/AVX-важке) може нагнітати теплове навантаження сильніше, ніж звичайні тести.

Рішення: Використовуйте відтворюване навантаження (той самий бінарник) при верифікації переустановлення; інакше будете ганятися за шумом.

Завдання 9: Стресс-тест у контрольованому режимі, щоб відтворити проблему

cr0x@server:~$ 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.

Значення: Тепер у вас є інструмент для формування стабільного навантаження.

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

cr0x@server:~$ sudo stress-ng --cpu 32 --timeout 60s --metrics-brief
stress-ng: info:  [31201] dispatching hogs: 32 cpu
stress-ng: metrc: [31201] cpu                60.00s  12345.67 bogo ops/s
stress-ng: info:  [31201] successful run completed in 60.02s

Значення: Відтворюване 60‑секундне навантаження дозволяє порівняння «до/після». Поєднуйте це з watch sensors.

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

Завдання 10: Перевірити виправлені апаратні помилки, що корелюють з теплом

cr0x@server:~$ sudo journalctl -k --since "1 hour ago" | egrep -i "mce|edac|hardware error" | tail -n 10
Jan 22 10:09:12 server kernel: mce: [Hardware Error]: Machine check events logged
Jan 22 10:09:12 server kernel: EDAC MC0: 1 CE memory read error on CPU_SrcID#0_Ha#0_Chan#1_DIMM#0

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

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

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

cr0x@server:~$ iostat -xz 1 3
Linux 6.5.0 (server) 	01/22/2026 	_x86_64_	(64 CPU)

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
          12.31    0.00    3.22    0.85    0.00   83.62

Device            r/s     w/s   rkB/s   wkB/s  rrqm/s wrqm/s  %util  r_await  w_await
nvme0n1         12.0   220.0   512.0  8192.0     0.0    0.0   68.5    2.10    9.80

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

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

Завдання 12: Перевірити, чи ZFS scrub/resilver не перетворює терміку на самонавмисний простій

cr0x@server:~$ zpool status
  pool: tank
 state: ONLINE
status: One or more devices is currently being resilvered.
action: Wait for the resilver to complete.
  scan: resilver in progress since Mon Jan 22 09:41:03 2026
        1.20T scanned at 1.68G/s, 612G issued at 858M/s, 4.10T total
        612G resilvered, 14.58% done, 0 days 01:10:22 to go
config:

        NAME        STATE     READ WRITE CKSUM
        tank        ONLINE       0     0     0
          raidz2-0  ONLINE       0     0     0
            sda     ONLINE       0     0     0
            sdb     ONLINE       0     0     0
            sdc     ONLINE       0     0     0
            sdd     ONLINE       0     0     0

Значення: Resilvering навантажує CPU і пам’ять (контрольні суми, стиснення, парність). Якщо теплові умови CPU граничні, таке навантаження їх виявить.

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

Завдання 13: Перевірити журнал подій BMC на термальні або вентиляторні події

cr0x@server:~$ sudo ipmitool sel list | tail -n 8
 217 | 01/22/2026 | 10:14:06 | Temperature #0x01 | Upper Critical going high | Asserted
 218 | 01/22/2026 | 10:14:10 | Temperature #0x01 | Upper Critical going high | Deasserted
 219 | 01/22/2026 | 10:14:12 | Processor #0x01   | IERR | Asserted

Значення: BMC зафіксував перетин термального порога. Також процесорна помилка може вказувати на нестабільність під впливом тепла.

Рішення: Ескалувати. Термічне — це вже не косметика; це викликає апаратні збої.

Завдання 14: Перевірити, чи шасі вважає кришку присутньою (таке трапляється)

cr0x@server:~$ sudo ipmitool sdr elist | egrep -i "intrusion|chassis"
Chassis Intrusion | Not Available     | ok

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

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

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

1) Інцидент через неправильне припущення

Середня SaaS-компанія мала флот баз даних, стабільний роками. Потім пройшла рутинна заміна апаратури: та ж сім’ї CPU, трохи новіший степінг, ревізія кріплення радіатора від постачальника.
Нічого страшного. Технік перепастив кілька хостів під час встановлення в стійку, бо кілька радіаторів здавалися «трохи сухими». Здавалося відповідальним.

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

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

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

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

2) Оптимізація, що дала протилежний ефект

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

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

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

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

Операційне правило: ніколи не комбінуйте фізичні зміни з політичними, якщо не готові бісектувати. Якщо не можете бісектувати — ви не навчитесь.

3) Нудна, але правильна практика, що врятувала день

Команда сховища, що працювала на щільних вузлах з обчисленням і NVMe, мала одну звичку, що виглядала майже комічно: кожного разу, коли знімали радіатор, вони логували це як заміну диска.
Тікет, причина, тип пасти, метод, патерн затягування і «до/після» 60-секундний знімок стрес-тесту. Нікому це не подобалося робити. Усі дуже цінували мати це пізніше.

Під час квартального фризу змін один вузол почав періодично тротлити. Він не падав зовсім. Просто працював повільно. Сервіс мав суворі SLO для хвостової латентності, і цей вузол тягнув
увесь пул вниз. Через фриз команда потребувала доказів перед тим, як попросити виняток для фізичних робіт.

Вони витягли історичні дані хоста і побачили, що package temps під стандартним стрес-тестом виросли приблизно на 10°C з останнього обслуговування. Також вони побачили запис про зняття радіатора
два місяці тому для RMA материнської плати. Це дало правдоподібну гіпотезу: тонке проблемне прилягання або pump-out.

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

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

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

1) Високі температури CPU відразу після перепастингу

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

Корінь: Забагато пасти (товстий шар), захоплені повітряні кишені, радіатор не сідає рівно.

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

2) Одне ядро/CCD значно гарячіше за інші

Симптоми: Велика дельта по ядрах під навантаженням; package temp виглядає «досить нормально», але точкове гаряче місце досягає порогів.

Корінь: Нерівномірний тиск монтажу, нахил, неправильний стандофф/спейсер, деформована основа радіатора, клин пасти.

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

3) Температури нормальні на холостому ході, погіршуються через 20–60 хвилин

Симптоми: Повільний підйом, потім тротлінг; часто корелюється з тривалими нагрузками (scrub, rebuild, пакетні роботи).

Корінь: Обмеження потоку повітря (фільтри, пучки кабелів), занадто консервативна крива вентиляторів, піки вхідної температури, pump-out пасти з часом.

Виправлення: Перевірити вхідну температуру й RPM вентиляторів через BMC; оглянути шлях потоку повітря; відновити рекомендовану політику вентиляторів; якщо історія вказує — переустановити пасту, яка стійкіша до pump-out.

4) Система перезавантажується під навантаженням, терміка «виглядає нормально»

Симптоми: Випадкові перезавантаження; іноді немає очевидного термального логу; іноді MCE/EDAC події.

Корінь: Локальний гарячий осередок, не зафіксований датчиком, перегрів VRM, неправильне вирівнювання радіатора або відсутність кришки/каналів, що призводить до нагріву компонентів.

Виправлення: Використати датчики BMC поза CPU (VRM, материнська плата, вхід). Підтвердити наявність повітряних каналів і кожухів. Переперевірити посадку радіатора. Не ігноруйте скоректовані помилки.

5) Вентилятори застрягли на низьких обертах, а температури ростуть

Симптоми: CPU досягає 90°C, вентилятори залишаються на низьких RPM; очевидних збоїв вентиляторів немає.

Корінь: Некоректна політика вентиляторів BMC, сенсор вторгнення шасі спрацьований або баг у прошивці.

Виправлення: Порівняйте температури в ОС і BMC; перевірте SEL на події політики; відновіть профіль тепла за замовчуванням; оновіть прошивку BMC у контрольованому вікні.

6) Паста на сокеті/компонентах після робіт

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

Корінь: Надмірне нанесення і розмазування під час зняття/встановлення радіатора; погана методика очищення.

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

7) «Ми перепастили і все одно гаряче»

Симптоми: Немає покращення після декількох перепастингів; всі втомлені; система залишається на межі.

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

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

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

Покроково: процедура «зробити один раз і забути» перепастингу (серверна)

1. Плануйте валідацію. Виберіть відтворюване навантаження (наприклад, stress-ng --cpu N --timeout 60s) і зафіксуйте базові температури та частоти до втручання.
2. Заплануйте вікно. Вам потрібен час для ретельного очищення і пост-робочого стрес-тесту. Поспіх — це шлях зробити пасту стилем життя.
3. Знеструмте і розрядьте. Вийміть кабелі живлення, зачекайте, дотримуйтеся сервіс-гіду платформи. Не «гаряче» змінюйте терпіння.
4. Акуратно зніміть радіатор. Послабляйте по діагоналі потроху. Уникайте крутіння, що розмазує пасту по компонентах.
5. Повністю очистіть обидві поверхні. Використовуйте безворсові серветки/тампони і відповідний розчинник. Видаліть стару пасту з кутів і щілин, де вона любить ховатися.
6. Огляньте поверхні. Шукайте подряпини, ямки, залишки і ознаки нерівного контакту. Підтвердіть правильний кронштейн/стендони для сокета.
7. Наносьте пасту економно. Використовуйте мінімум, який заповнить порожнини: маленька крапка для типової IHS, лінія/X для великої прямокутної серверної IHS за потреби.
8. Саджайте радіатор прямо вниз. Уникайте зміщення; невеликий зсув може створити порожнини або нерівномірне витиснення пасти.
9. Затягуйте поступово по діагоналі. По кілька обертів на гвинт, чергуючи кути, до повного сідання за специфікацією постачальника.
10. Встановіть кожухи і канали. Це не опціональна естетика. Це різниця між «системою охолодження» і «надією».
11. Запустіть і перевірте датчики. Підтвердіть вентилятори, вхідну температуру і температури CPU як у ОС, так і в BMC.
12. Запустіть валідаційне навантаження. Порівняйте з базою. Якщо температури гірші — зупиніться і перевірте монтаж і кількість пасти, а не хаотично міняйте патерни.
13. Задокументуйте зміну. Запишіть тип пасти, метод і метрики до/після. Майбутній ви буде нездоланно вдячний.

Контрольний список: здоровий стан потоку повітря і шасі (перед тим, як звинувачувати пасту)

• Всі модулі вентиляторів на місці, правильна модель, без помилок.
• Ребра радіатора чисті; немає пилу або пакувальної піни (так, таке буває).
• Повітряний кожух встановлений і сідає на місце.
• Заглушки RU на місці; немає відкритих отворів, що обводять потік повітря.
• Пучки кабелів не перекривають вхід вентиляторів або кожух CPU.
• Вхідні температури в очікуваному діапазоні; порівняйте з сусідами в стійці.
• Профіль тепла BMC встановлений у рекомендований режим для вашого навантаження.

Контрольний список: вибір пасти як доросла людина

• Віддавайте перевагу непровідному, неконденсативному складу для серверів, якщо немає вагомої причини і контролю якості робіт.
• Пріоритет — стійкість до температурних циклів (опір pump-out), а не пікові бенчмарк-стандарти теплопровідності.
• Стандартизуйте одну-дві затверджені сполуки і один метод нанесення на платформу.
• Уникайте змішування паст або нанесення поверх залишків; очищайте до голої поверхні щоразу.
• Якщо за дизайн використовують фазові пади, не замінюйте їх пастою поспіхом; ви змінюєте валідацію збірки.

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

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

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

2) Як дізнатися, що я використав забагато пасти, без розбирання?

Шукайте підпис після перепастингу: вищі package temps під тим же контрольованим навантаженням, більші дельти по ядрах, раніше розгін вентиляторів і нові повідомлення про тротлінг у логах.
Такі шаблони сильно вказують на поганий інтерфейс або посадку.

3) Чи завжди «метод горошини» правильний?

Ні. Це добрий дефолт для багатьох стандартних IHS, але великі прямокутні серверні IHS часто виграють від лінії або X, щоб забезпечити покриття кутів. Реальна вимога — тонке неперервне покриття,
а не відданість формі.

4) Чи варто розмазувати пасту карткою/лопаткою?

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

5) Як часто слід перепастувати сервери?

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

6) Чи варто використовувати «метал» або рідкий метал у продакшні?

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

7) Мій CPU гарячий; чи означає це автоматично, що паста погана?

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

8) Чому я бачу тротлінг, але немає очевидної температурної аварії?

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

9) Який єдиний найважливіший механічний фактор крім кількості пасти?

Тиск монтажу і рівномірність. Ідеальна паста не компенсує радіатор, що стоїть під нахилом, нерівномірно затягнутий або з неправильним спейсером/бекплейтом.

10) Якщо я перепастив і температури покращилися — чи це кінець?

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

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

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

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

• Виберіть стандартне валідаційне навантаження і зафіксуйте базові температури та частоти для кожної платформи.
• Коли терміка зсувається, пройдіть план швидкої діагностики перед тим, як торкатися апаратури.
• Якщо доводиться перепастувати — стандартизуйте тип пасти, метод нанесення і послідовність моментів затягування — і документуйте це як будь-яку іншу продукційну зміну.
• Після робіт валідуйте під тривалим реалістичним навантаженням, а не просто «воно завантажилось».
• Розглядайте термальні регресії як ризики надійності, особливо на вузлах сховища під час відновлень і scrub’ів.

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