Debian 13: теплове тротлінгування руйнує пропускну здатність — доведіть це й виправте охолодження/обмеження потужності

January 16, 2026 • February 3, 2026 • Читання: 6 хв • Views: 7

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

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

На Debian 13 це часто не «Debian гальмує». Це фізика, прошивка та політика живлення. Теплове тротлінгування (CPU, NVMe, HBA, чіпсет) непомітно обмежує частоту, швидкість лінку або глибину черги, і пропускна здатність падає разом з цим. Завдання — чітко це довести, а потім виправити, не спаліть обладнання і не зіпсуйте електричну мережу.

Швидкий план діагностики

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

Перше: підтвердьте, що це залежить від часу і корелюється з температурою

Запустіть сталі навантаження (fio або відтворення реального навантаження) принаймні 5–10 хвилин. Тротлінг любить «після прогріву».
Одночасно спостерігайте частоту CPU + прапорці тротлінгу і температуру NVMe. Якщо продуктивність падає, поки температури ростуть і спрацьовують ліміти — у вас є кейс.

Друге: визначте, який компонент тротлить

CPU тротлінг: зниження частоти, події обмеження потужності (PL1/PL2), висока температура пакету, лічильники «throttled» інкрементуються.
NVMe тротлінг: температура контролера підвищується, стан «thermal management» змінюється, з’являються SMART-попередження, зростає латентність.
PCIe/проблеми лінку: лінк переузгоджується, зростають лічильники помилок, узгоджена ширина/швидкість падає при нагріванні.
Контроль охолодження: вентилятори не підвищують обороти, BMC застряг у «акустичному» режимі, прошивка ноутбука відмовляється розкрутити вентилятори.

Третє: вирішіть, політика це чи фізика

Політика: governor powersave, занадто низькі ліміти потужності, BIOS пресети «енергозбереження», профілі платформи.
Фізика: пил, заблокований повітряний вхід, відсутні радіатори NVMe, погана термопаста, дефектний вентилятор, неправильне зонування вентиляторів.

Зробіть ці три кроки — і ви перестанете сперечатися про «Debian vs kernel vs filesystem» і почнете сперечатися про те, що реально нагрівається, а це вже прогрес.

Як виглядає тротлінг у реальній пропускній здатності

Теплове тротлінгування не є тонким. Воно виглядає тонко лише якщо ви вимірюєте одну річ.

Класичний патерн:

fio стартує, наприклад, з 6–7 GB/s читань на RAID з NVMe.
Через 60–180 секунд пропускна здатність плавно знижується до 3–4 GB/s.
Латентність зростає. Збільшення глибини черги більше не допомагає.
Частота CPU падає на кількасот MHz, або температура контролера NVMe перетинає поріг, або й те, й інше.

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

Цитата, яку варто пам’ятати: Werner Vogels, CTO Amazon: «Все ламається, весь час.» (парафраз). Тротлінг — це режим відмови, який виглядає як регрес продуктивності, доки ви не інструментуєте його як проблему надійності.

Цікаві факти та контекст (бо історія повторюється)

Intel давно впровадив агресивну поведінку turbo, і «швидко в короткому, повільніше в довгому» стало нормою: підвищення PL2, PL1 підтримка.
NVMe диски мають формальні стани thermal management (часто два рівні), і багато споживчих накопичувачів налаштовані тротлити рано при поганому повітряному потоці.
Раніше дата-центри проектувалися для обертових дисків; щільність NVMe значно підвищила теплове навантаження на одиницю стійки, і припущення про повітряний потік порушилися.
У Linux керування частотою CPU пройшло кілька епох (acpi-cpufreq, intel_pstate, amd_pstate), і за замовчуванням змінювалися; «працювало на Debian X» — не доказ.
RAPL обмеження потужності були створені для енергоконтролю і доступні через MSR; продавці інколи встановлюють консервативні значення для акустики або теплових цілей платформи.
Деякі серверні BIOS профілі міняють стійку продуктивність на менший шум; «Balanced» часто означає «тихо, доки не стане погано».
Частота помилок PCIe може зростати з температурою; маргінальна передача погіршується з нагріванням, і повторні узгодження лінку можуть знизити ефективну пропускну здатність.
Деградація термопасти — реальна річ; паста «видавлюється» роками циклів нагріву, підвищуючи температуру кристала при тому ж навантаженні.
Ноутбуки започаткували агресивні евристики тротлінгу (температура шкіри, захист батареї), і ці ідеї просочилися в компактні сервери та edge-пристрої.

Доведіть це: інструментація, що витримає постмортем

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

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

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

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

Жарт #1: Теплове тротлінгування — це ваш сервер, який ввічливо каже «я втомився» перед тим, як робити половину роботи за ту ж зарплату.

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

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

Завдання 1: Підтвердьте ядро та базові дані платформи

cr0x@server:~$ uname -a
Linux server 6.12.0-1-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.12.0-1 (2025-10-01) x86_64 GNU/Linux

Що це означає: Ви на лінії ядер Debian 13 і записана конкретна версія. Поведінка тротлінгу може змінюватись з драйверами cpufreq і налаштуваннями планувальника.

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

Завдання 2: Перевірте governor CPU і драйвер (перевірка політики)

cr0x@server:~$ cpupower frequency-info
analyzing CPU 0:
  driver: intel_pstate
  CPUs which run at the same hardware frequency: 0
  hardware limits: 400 MHz - 5300 MHz
  available cpufreq governors: performance powersave
  current policy: frequency should be within 400 MHz and 5300 MHz.
                  The governor "powersave" may decide which speed to use
  current CPU frequency: 1200 MHz (asserted by call to hardware)

Що це означає: intel_pstate + powersave може бути цілком прийнятним для багатьох навантажень, але це підозріле місце, коли продуктивність падає під тривалим навантаженням.

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

Завдання 3: Примусово встановити governor performance (тимчасовий тест)

cr0x@server:~$ sudo cpupower frequency-set -g performance
Setting cpu: 0
Setting cpu: 1
Setting cpu: 2
Setting cpu: 3

Що це означає: Ви виключили одне поширене джерело «таємничого провалу».

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

Завдання 4: Встановіть і використайте turbostat для виявлення тротлінгу CPU

cr0x@server:~$ sudo apt-get update
Hit:1 http://deb.debian.org/debian trixie InRelease
Reading package lists... Done

cr0x@server:~$ sudo apt-get install -y linux-cpupower linux-tools-common linux-tools-amd64
Reading package lists... Done
Building dependency tree... Done
The following NEW packages will be installed:
  linux-cpupower linux-tools-amd64 linux-tools-common

cr0x@server:~$ sudo turbostat --Summary --interval 2
Summary: 2.00 sec samples
  PkgTmp  Bzy_MHz  Avg_MHz  Busy%  IRQ     SMI  PkgWatt  CorWatt  GFXWatt
   93     2800     2200     84.0   12000     0   150.2    120.8     0.0

Що це означає: Температура пакету висока (93C). Якщо ви бачите падіння частоти при високому Busy%, це класичне обмеження через тепло/потужність. На деяких платформах turbostat також показує лічильники «Throt» або причини ліміту.

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

Завдання 5: Доведіть обмеження потужності через лічильники RAPL (Intel)

cr0x@server:~$ sudo apt-get install -y msr-tools
Reading package lists... Done
Building dependency tree... Done
The following NEW packages will be installed:
  msr-tools

cr0x@server:~$ sudo modprobe msr

cr0x@server:~$ sudo rdmsr -a 0x610
00000000dd8080c8
00000000dd8080c8
00000000dd8080c8
00000000dd8080c8

Що це означає: MSR 0x610 часто — PKG_POWER_LIMIT. Потрібне декодування для інтерпретації ватів/вікон часу; сирий запис — це доказ і його можна декодувати за допомогою скриптів чи інструментів, якщо у вас є внутрішні стандарти.

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

Завдання 6: Перевірка статусу AMD pstate (системи AMD)

cr0x@server:~$ cat /sys/devices/system/cpu/amd_pstate/status
active

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

Що це означає: AMD pstate активний, але governor — powersave. Це може бути нормально; але також може виявитися занадто консервативним під тривалим I/O + компресією + чексума-навантеженнями.

Рішення: Для діагностики перемкніть на performance і порівняйте тривалі результати. Якщо результати покращилися — встановіть постійну політику (див. пізніший розділ).

Завдання 7: Спостерігайте температури в реальному часі (просто і ефективно)

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

cr0x@server:~$ sudo sensors-detect --auto
# sensors-detect revision 3.6.0
# System: ExampleVendor ServerBoard
# Summary: 3 drivers loaded

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

nvme-pci-0100
Adapter: PCI adapter
Composite:    +78.9°C  (low  = -20.1°C, high = +84.8°C)

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

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

Завдання 8: Перевірте NVMe SMART температури та термальні події

cr0x@server:~$ sudo apt-get install -y nvme-cli smartmontools
Reading package lists... Done
Building dependency tree... Done
The following NEW packages will be installed:
  nvme-cli smartmontools

cr0x@server:~$ sudo nvme smart-log /dev/nvme0
Smart Log for NVME device:nvme0 namespace-id:ffffffff
critical_warning                    : 0x00
temperature                         : 80 C
available_spare                     : 100%
percentage_used                     : 2%
thermal_management_t1_trans_count    : 7
thermal_management_t2_trans_count    : 1
time_for_thermal_management_t1       : 438
time_for_thermal_management_t2       : 55

Що це означає: Диск перейшов у стан thermal management T1 і навіть T2. Це тротлінг із формальним обліком.

Рішення: Якщо ці лічильники зростають у вікні падіння пропускної здатності, припиніть звинувачувати файлові системи. Виправте повітряний потік і радіацію навколо NVMe пристроїв.

Завдання 9: Перевірка датчиків температури NVMe через smartctl (альтернативний погляд)

cr0x@server:~$ sudo smartctl -a /dev/nvme0
smartctl 7.4 2024-12-08 r5560 [x86_64-linux-6.12.0-1-amd64] (local build)
=== START OF INFORMATION SECTION ===
Model Number:                       ExampleNVMe 3.84TB
Firmware Version:                   2B0QEXM7
=== START OF SMART DATA SECTION ===
Temperature:                        80 Celsius
Temperature Sensor 1:               82 Celsius
Temperature Sensor 2:               76 Celsius
Warning  Comp. Temperature Time:    438
Critical Comp. Temperature Time:    55

Що це означає: Лічильники часу попередження і критичного температурного часу ненульові та зростають. Це сильно корелює з тротлінгом і інколи з прискореним зношуванням носіїв.

Рішення: Ставте NVMe температуру в категорію надійності так само, як помилки пам’яті: це сигнал про надійність, а не лише «продуктивність».

Завдання 10: Перевірте узгоджену швидкість/ширину PCIe (нагрів може виявити маргінальність)

cr0x@server:~$ sudo lspci -s 01:00.0 -vv | sed -n '/LnkCap:/,/LnkSta:/p'
LnkCap: Port #0, Speed 16GT/s, Width x4, ASPM L1, Exit Latency L1 <64us
LnkSta: Speed 8GT/s (downgraded), Width x4 (ok)

Що це означає: Лінк здатний на 16GT/s, але зараз на 8GT/s. Це може статися через налаштування BIOS, якість сигналу або інколи відновлення після помилок при нагріванні.

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

Завдання 11: Шукайте помилки PCIe, що збігаються з нагрівом і тротлінгом

cr0x@server:~$ sudo dmesg -T | egrep -i 'aer|pcie|nvme|thrott'
[Mon Dec 29 11:04:12 2025] pcieport 0000:00:1d.0: AER: Corrected error received: 0000:01:00.0
[Mon Dec 29 11:04:12 2025] nvme 0000:01:00.0: AER: can't recover (no error_detected callback)
[Mon Dec 29 11:05:01 2025] nvme nvme0: I/O 123 QID 4 timeout, aborting

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

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

Завдання 12: Вимірюйте пропускну здатність і латентність так, щоб ловити тротлінг (fio time series)

cr0x@server:~$ sudo apt-get install -y fio
Reading package lists... Done
Building dependency tree... Done
The following NEW packages will be installed:
  fio

cr0x@server:~$ fio --name=warmth --filename=/dev/nvme0n1 --direct=1 --ioengine=io_uring --rw=read --bs=128k --iodepth=32 --numjobs=1 --runtime=600 --time_based=1 --group_reporting=1 --status-interval=10
warmth: (groupid=0, jobs=1): err= 0: pid=22114: Mon Dec 29 11:07:10 2025
  read: IOPS=52.1k, BW=6512MiB/s (6827MB/s)(63.6GiB/10s)
...
warmth: (groupid=0, jobs=1): err= 0: pid=22114: Mon Dec 29 11:09:20 2025
  read: IOPS=34.0k, BW=4250MiB/s (4457MB/s)(41.5GiB/10s)
...
warmth: (groupid=0, jobs=1): err= 0: pid=22114: Mon Dec 29 11:17:10 2025
  read: IOPS=33.2k, BW=4149MiB/s (4350MB/s)(40.5GiB/10s)

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

Рішення: Коли ви бачите поетапне падіння, негайно зіставте відмічки часу з turbostat/sensors/nvme smart-log. Якщо кореляція сильна — припиняйте змінювати прапори fio. Починайте виправляти охолодження/потужність.

Завдання 13: Спостерігайте статистику блочного шару і черги пристрою (чи зависає пристрій?)

cr0x@server:~$ iostat -dxm 2 5 nvme0n1
Linux 6.12.0-1-amd64 (server) 	12/29/2025 	_x86_64_	(64 CPU)

Device            r/s     rMB/s   rrqm/s  %rrqm r_await rareq-sz  aqu-sz  %util
nvme0n1        52000.0   6500.0     0.0   0.00    0.60    128.0   31.0  99.0
nvme0n1        34000.0   4250.0     0.0   0.00    0.95    128.0   32.0  99.0

Що це означає: %util залишається високим, поки пропускна здатність падає і await зростає. Пристрій — обмеження (або шлях до нього), а не CPU, який позбавляє запитів.

Рішення: Спрямуйте ліхтар на температуру NVMe, стан PCIe і фізичне охолодження.

Завдання 14: Перевірте журнал systemd на підказки про температуру/потужність

cr0x@server:~$ sudo journalctl -k -b | egrep -i 'thermal|thrott|powercap|rapl|cpu frequency' | tail -n 20
Dec 29 11:04:55 server kernel: intel_rapl_common: Found RAPL domain package
Dec 29 11:05:03 server kernel: CPU0: Core temperature above threshold, cpu clock throttled
Dec 29 11:05:03 server kernel: CPU2: Core temperature above threshold, cpu clock throttled

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

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

Завдання 15: На серверах перевірте IPMI сенсори і поведінку вентиляторів

cr0x@server:~$ sudo apt-get install -y ipmitool
Reading package lists... Done
Building dependency tree... Done
The following NEW packages will be installed:
  ipmitool

cr0x@server:~$ sudo ipmitool sensor | egrep -i 'fan|temp|inlet|exhaust|cpu'
Inlet Temp       | 29.000     | degrees C  | ok
Exhaust Temp     | 51.000     | degrees C  | ok
CPU1 Temp        | 92.000     | degrees C  | ok
FAN1             | 1800.000   | RPM        | ok
FAN2             | 1700.000   | RPM        | ok

Що це означає: CPU гарячий, але вентилятори не «волають». Часто це питання політики керування (quiet mode, неправильне мапування сенсорів) або фізичної перешкоди.

Рішення: Ескалюйте налаштування BIOS/BMC фан-профілю. Якщо ви не керуєте цим — залучіть власника прошивки платформи. Сам софт інколи не зможе розкрутити вентилятори, якщо BMC проти.

Завдання 16: Швидка перевірка фонового «допоміжного» софту (tlp/power-profiles-daemon)

cr0x@server:~$ systemctl status power-profiles-daemon.service --no-pager
● power-profiles-daemon.service - Power Profiles daemon
     Loaded: loaded (/lib/systemd/system/power-profiles-daemon.service; enabled)
     Active: active (running) since Mon 2025-12-29 10:52:11 UTC; 25min ago

Що це означає: Демон може штовхати «balanced» поведінку. На ноутбуках це нормально. На вузлах зберігання — це тихий вбивця пропускної здатності.

Рішення: Прийміть чітке рішення: вузол продуктивності чи ні. Якщо так — зафіксуйте performance профіль і задокументуйте. Якщо ні — прийміть стелю пропускної здатності.

Спеціально для сховищ: NVMe, PCIe і «чому fio бреше?»

Пропускна здатність сховища — це ланцюг: CPU відправляє I/O, ядро ставить його в чергу, PCIe переносить, контролер обслуговує, NAND виконує роботу, а контролер намагається не розплавитися. Ви можете тротлити на будь-якому кроці.

Тротлінг NVMe зазвичай — проблема контролера, не NAND

Контролер NVMe — гаряча пляма. NAND терпить тепло до певної межі, а от силікон контролера і його пакетні обмеження — ні. Багато дисків віддають «Composite» температуру, але також мають кілька сенсорів. Якщо Sensor 1 стрибнув, а Composite — відстає, ви бачите, як контролер підгорає.

Перехід у стани thermal management (T1/T2) — це курильний слід, бо вони рахуються. Якщо ви можете показати інкремент thermal_management_t1_trans_count в той самий часовий штамп, коли впала пропускна здатність — ви довели випадок за документами самого диска.

Чому короткі бенчмарки пропускають це

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

PCIe швидкість і ASPM можуть бути червоними ослями — або всім поясненням

Якщо ваш PCIe лінк узгоджений на нижчій швидкості, ви можете обмежити пропускну здатність незалежно від можливостей диска. Іноді це конфігурація. Іноді — відновлення після помилок. Іноді — якість riser/cable. Іноді — «хтось вставив x4 диск в слот, що ділиться лініями з трьома іншими пристроями, тепер ми вчимося про топологію».

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

CPU тротлінг і сховище: неприємна взаємозалежність

Ви можете думати, що сховище — це «I/O bound» і частота CPU не важлива. Потім ви вмикаєте контрольні суми, компресію, шифрування, erasure coding або навантаження з високим IOPS і малим блоком. Раптом CPU виконує значну роботу на I/O, і частота має значення. Тротлінг перетворюється на менше IOPS, вищі хвостові латентності і іноді дивні «пристрій повільний» наративи.

Жарт #2: Якщо ви хочете симулювати теплове тротлінгування на нараді, покажіть графік, а потім повільно знизьте голос, поки всі не занудьгують.

Виправлення, що дійсно допомагають: охолодження, повітряний потік і контакт

Виправлення охолодження непрезентабельні. Вони також працюють. Якщо ви хочете стійку пропускну здатність — вам потрібен стійкий тепловий запас. Не «проходить 30-секундний тест». Стійкий.

1) Припиніть рециркуляцію гарячого повітря

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

Відсутні заглушки в портах.
Containment холодного/гарячого проходу — декларативний.
Кабелі блокують вхід або створюють турбулентність.
Сервер заштовханий у місце з поганим постачанням холодного повітря.

Вимірюйте температуру на вході й виході через IPMI. Якщо вхід вже високий до навантаження — ви працюєте з зменшеним запасом.

2) Переконайтеся, що вентилятори підвищують обороти, коли потрібно

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

Виправлення зазвичай у налаштуваннях BIOS/BMC: тепловий профіль «Performance», вищі мінімальні обороти вентиляторів або правильне мапування сенсорів. Якщо ви не можете це змінити — принаймні задокументуйте, бо ви живете в чиїхось припущеннях.

3) Радіатори NVMe і повітряний потік важливі більше, ніж здається

M.2 NVMe в серверах — класична пастка. Він народився в ноутбуках, де повітряного потоку мінімум і конструкція інтегрована. У серверах люди ставлять M.2 на плату «бо вміщається», а потім дивуються, чому він тротлить. U.2/U.3 відсіки зазвичай мають кращий потік, але навіть щільні фронтальні корзини можуть сильно грітися.

Практичні кроки:

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

4) Переустановіть/заміни пасту і прижміть радіатор (так, справді)

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

Коли робити це:

Один вузол із пулу тротлить раніше за однолітків.
Вентилятори працюють нормально, але температура CPU росте швидше, ніж очікувалося.
Можливі проблеми контакту радіатора (недавнє обслуговування, транспортування, вібрація).

Будьте дисципліновані: плануйте час простою, дотримуйтесь ESD-практик, використовуйте визнану пасту і перевіряйте знову тією ж інструментацією.

Виправлення для обмежень потужності: RAPL, AMD pstate і прошивкові кайдани

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

CPU governor і профілі платформи: не дозволяйте дефолтам керувати вузлом зберігання

Дефолти призначені для систем загального призначення. Вузли зберігання, що виконують тривалу I/O, — не загального призначення. Якщо ви хочете передбачуваної продуктивності, встановіть явну політику:

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

Постійна конфігурація governor (systemd)

Для Debian один простий підхід — невеликий systemd unit, що встановлює governor при завантаженні. Це грубо, але чесно. Можна також використовувати cpufrequtils, але systemd робить намір явним і контролюваним версіями.

cr0x@server:~$ sudo tee /etc/systemd/system/cpupower-performance.service <<'EOF'
[Unit]
Description=Set CPU governor to performance
After=multi-user.target

[Service]
Type=oneshot
ExecStart=/usr/bin/cpupower frequency-set -g performance

[Install]
WantedBy=multi-user.target
EOF

cr0x@server:~$ sudo systemctl daemon-reload

cr0x@server:~$ sudo systemctl enable --now cpupower-performance.service
Created symlink /etc/systemd/system/multi-user.target.wants/cpupower-performance.service → /etc/systemd/system/cpupower-performance.service.

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

Intel RAPL: не крутіть ліміти бездумно

Налаштування RAPL може бути ефективним, але це також шлях перетворити «передбачуване тротлінгування» на «непередбачувані відключення», якщо охолодження не витримає. Якщо піднімаєте PL1/PL2 без зміни повітряного потоку — ви просто переміщаєте точку відмови.

Що робити натомість:

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

AMD: pstate + CPPC гарні, поки прошивка не стала консервативною

AMD pstate зазвичай поводиться добре, але вас все одно можуть обмежити платформи (PPT/TDC/EDC) і теплові обмеження. Шлях виправлення часто лежить через налаштування BIOS (performance profile, thermal limits, fan curves), а не лише Linux-параметри.

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

Цей розділ існує тому, що люди повторюють помилки з переконаністю.

1) Пропускна здатність падає через 1–3 хвилини, потім стабілізується низькою

Корінь: NVMe thermal throttling (T1/T2), часто через поганий повітряний потік або контакт радіатора.

Виправлення: Додайте радіатори/направники повітря, забезпечте підвищення оборотів вентиляторів, перемістіть диски від джерел тепла, перевірте через nvme smart-log лічильники.

2) IOPS падають, поки CPU Busy% залишається високим, температура CPU біля порогу

Корінь: Тепловий тротлінг CPU або обмеження потужності (PL1), що знижує стійку частоту.

Виправлення: Спочатку виправте охолодження (вентилятори/профіль/радіатор), потім перевірте governor і BIOS power profile. Використовуйте turbostat + журнали як доказ.

3) Продуктивність добра після холодного старту, погана після оновлення прошивки

Корінь: BIOS скинувся в «Balanced» або «Acoustic» профіль; змінилися ліміти потужності; крива вентиляторів змінилася.

Виправлення: Відновіть відомі робочі налаштування BIOS/BMC. Розглядайте оновлення прошивки як зміну конфігурації з чек-листом.

4) Один вузол у флоті повільніший при ідентичній конфігурації

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

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

5) Стрибки латентності, в dmesg показуються AER corrected errors

Корінь: Маргінальний PCIe лінк (riser/cable/slot), що погіршується з температурою; лінк може переузгоджуватись вниз.

Виправлення: Пересадіть/замініть riser, змініть слот, оновіть прошивку, покращіть повітряний потік навколо PCIe зони, підтвердіть узгоджену швидкість лінку.

6) Після «оптимізації потужності» сховище почало працювати повільніше

Корінь: Governor/профіль живлення надто консервативні; глибокі C-state або даунклок додають латентності і обмежують IOPS.

Виправлення: Встановіть явну політику performance на вузлах зберігання; виміряйте споживання і температури; не оптимізуйте під енергію без SLO.

7) fio показує величезні числа, а додаток усе одно повільний

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

Виправлення: Запустіть тривалі тести (10+ хвилин), логайте температури й тротлінг-події, виміряйте p95/p99 латентність у вашому додатку.

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

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

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

Два дні потому вдень почав зростати лаг інгесту. Не різкий збій, а повільне дрейфування в «чому ми знову відстаємо?» Графіки образили: вранці все було добре. До полудня продуктивність падала, латентність росла, backlog наростав. Люди звинувачували пайплайн, додаток, мережу.

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

Вони довели це двома хронологіями: тривалі читання fio і NVMe лічильники thermal management. Кожного разу, коли backlog ріс, thermal_management_t1_trans_count крокував синхронно. Виправлення не було винахідливим. Воно було фізичним: встановити коректні перегородки, увімкнути вентилятори в «performance» профіль вендора і додати радіатори для найгарячіших дисків.

Після змін післяобіднє провалювання зникло. Розбір був прямолінійним: вони вважали варіант платформи неважливим. Дія — базувати теплові заміри як частину приймання обладнання, а не чекати критичної продуктивності.

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

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

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

Оптимізація відкотилася, бо вони оптимізували не ту фазу дня. Система проводила багато годин у помірних навантаженнях і коротких сплесках, де енергоощадження було реальним. Але під час тривалого I/O з компресією CPU глухнув. Політика balanced даунклокувала агресивніше, ніж очікували, а стійкі ліміти потужності не дозволяли CPU тримати вищі частоти. Це було не просто «повільний CPU». Це був «повільний CPU саме тоді, коли нам потрібна стійка пропускна здатність».

Вони довели це, зловивши turbostat під час батча: падіння частоти при високому Busy%, плюс журнали ядра з повідомленнями про тротлінг. Графіки пропускної здатності сховища майже сором’язливо збігалися з кривою частоти. NVMe не був обмежувачем; обчислення на I/O — так.

Виправлення — розділити політику: зберігайте енергозбереження на загальних вузлах, але фіксуйте вузли для зберігання/батчів на performance профіль під час вікон виконання батчів. Це вимагало процесу, а не героїзму: change control, документація і простий сервіс при завантаженні для встановлення governor. Споживання трохи зросло. Інциденти впали значно.

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

Команда фінансових сервісів керувала скромним кластером на ZFS. Вони не блищали, але були дисципліновані. Щоквартально вони робили «sustained performance soak test» після патчів: 30 хвилин читання/запису з логуванням температур і лічильників тротлінгу та архівацією.

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

Вони порівняли телеметрію з попереднім кварталом і побачили дві відмінності: температура пакету CPU піднімалась швидше, а RPM вентиляторів BMC plateau-увала нижче. Прошивка тихцем скинула фан-профіль. Нічого «не зламалося», тому це не було очевидно. Але soak test зробив це очевидним.

Вони повернули BMC профіль у performance, повторили soak, і провал зник. Ніякого інциденту. Жодного метушні. Просто чекбокс і повторний запуск.

Менеджер назвав це «нудною відмінністю», що є найкращою похвалою для операцій. Тест не зробив їх кращими в героїзмі; він зробив героїзм непотрібним.

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

Покроково: доведіть тротлінг наскрізь (повторюваний метод)

Виберіть стале навантаження: 10–20 хвилин, постійні параметри. Уникайте «burst» тестів.
Запустіть навантаження зі статусом: fio з --status-interval.
Паралельно збирайте телеметрію CPU: turbostat кожні 2 секунди.
Паралельно збирайте температури: вивід sensors під watch.
Паралельно знімайте NVMe термальні лічильники: снапшот smart-log на початку/посередині/в кінці.
Позначте відмітки часу: або запишіть час, або логайте все у файли.
Шукайте кореляцію: падіння пропускної здатності вирівнюється з підйомом температури і доказами термального/потужнісного обмеження.
Класифікуйте вузьке місце: CPU vs NVMe vs PCIe link vs контроль охолодження.
Застосовуйте одне виправлення за раз: профіль вентиляторів АБО радіатор АБО governor, а не купу змін.
Повторіть той самий тест: порівнюйте криві, не окремі числа.

Чек-лист охолодження (сервери)

Температура на вході прийнятна під навантаженням? Якщо ні — виправляйте повітряний потік/containment стійки.
Вентилятори підвищують обороти з ростом температур CPU/NVMe? Якщо ні — виправляйте BMC профіль.
Наявні заглушки панелей? Кабельні пучки блокують вхід? Виправте.
NVMe має радіатори або потік повітря? Якщо ні — додайте.
Один вузол гарячіший за однолітків? Огляньте: пил, стан вентиляторів, паста, перегородки.

Чек-лист політики живлення (вузли Debian 13)

Підтвердіть governor і драйвер cpufreq відповідні вашим намірам.
Перевірте демони управління живленням на серверах; видаліть або налаштуйте.
Після оновлення валідуйте профіль платформи/BIOS.
Не піднімайте ліміти потужності, якщо охолодження не перевірене під тривалим навантаженням.

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

1) Як зрозуміти, що це тепловий тротлінг, а не «звичайна поведінка SSD-кешу»?

Шукайте явні докази: інкремент лічильників переходів thermal management NVMe (T1/T2), або повідомлення ядра «cpu clock throttled», вирівняні з падінням пропускної здатності. Ефекти кешу зазвичай не інкрементують теплові лічильники.

2) Чому мій бенчмарк виглядає чудово, якщо я запускаю його знову відразу?

Тому що зупинка навантаження охолоджує обладнання. Ви скидаєте тепловий стан. Стійкий тест показує steady-state стелю; короткі прогони — burst-стелю.

3) Чи може тротлінг CPU справді так сильно зменшити пропускну здатність сховища?

Так, особливо при компресії, контрольних сумах, шифруванні, малих блоках I/O, високих перериваннях або користувацьких стек-ах з обробкою в CPU. Якщо CPU не може достатньо швидко відправляти/обробляти завершення I/O — IOPS впадають.

4) Чи завжди ставити governor performance на вузлах зберігання?

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

5) Чи завжди потрібні радіатори для NVMe?

Не завжди, але часто це найдешевший спосіб уникнути тротлінгу, особливо для M.2 або щільних U.2/U.3 корзин. Якщо NVMe потрапляє в T1/T2 під тривалим навантаженням — відповідь фактично «так».

6) Мої вентилятори повільні, але температури високі. Чи може Linux це виправити?

Іноді на десктопах; часто — ні на серверах. Багато серверів використовують BMC для керування вентиляторами. Вам потрібні налаштування BIOS/BMC, а не хитрий kernel-параметр.

7) Чи безпечно піднімати ліміти потужності (PL1/PL2)?

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

8) Що робити, якщо швидкість PCIe показує «downgraded» тільки після нагріву?

Це сигнал маргінальної цілісності сигналу або відновлення після помилок під навантаженням. Перевірте AER помилки, пересадіть/замініть riser, покращіть повітряний потік навколо PCIe. Не ігноруйте — це може стати нестабільністю шляху даних.

9) Чому Debian 13 звинувачують у цьому?

Тому що оновлення ОС змінюють дефолти (governors, драйвери, демони) і часто збігаються з оновленнями прошивки. Часова збіглість породжує підозри. Фізика до цього байдуже.

10) Яку телеметрію варто архівувати для майбутніх дебатів «стало повільніше»?

fio статус по часу, підсумки turbostat, знімки sensors, NVMe smart-log лічильники, дампи IPMI сенсорів і журнали ядра з повідомленнями про тротлінг або AER.

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

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

Зробіть це в такому порядку:

Запустіть тривале навантаження 10–20 хвилин і захопіть таймсерії пропускної здатності.
Захопіть температуру CPU/частоту і докази тротлінгу (turbostat + journal).
Захопіть NVMe термальні лічильники (nvme smart-log, smartctl).
Якщо можете зіставити падіння продуктивності з доказами теплового/потужнісного ліміту — спочатку виправляйте охолодження і політику вентиляторів.
Лише потім тонко налаштовуйте політику живлення (governors, профіль платформи і — обережно — ліміти потужності).
Повторіть той самий тривалий тест і порівняйте всю криву, а не одне число в заголовку.

Мета — нудна стійка продуктивність. Швидкість сплеску — для маркетингових слайдів. Стійка пропускна здатність — для продакшну.