Перегрев сервера Linux: диагностика троттлинга и защита железа

Тепловая проблема почти никогда не выглядит как отказ. Служба отвечает, сайты открываются, top показывает простой — и при этом процессор десятки раз в минуту уходит в принудительный сброс частоты.

Средняя нагрузка при этом остаётся нулевой, поэтому стандартный мониторинг не даёт ни одного повода для тревоги. Жалобы формулируются как «периодически тормозит», а причина находится ниже уровня, который наблюдает система сбора метрик.

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

Шаг 1. Снять картину железа

До выводов требуется точная конфигурация: модель процессора и его теплопакет, плата, объём и режим работы памяти, состояние накопителей.

# Установка средств диагностики
sudo apt update && sudo apt install -y inxi lm-sensors smartmontools ethtool sysstat

# Сводный отчёт по конфигурации, самый читаемый вывод
sudo inxi -Fxxxz

# Данные SMBIOS: плата, прошивка, процессор, модули памяти
sudo dmidecode -t system -t baseboard -t bios -t processor -t memory

# Ядро, архитектура, признак виртуализации
hostnamectl

# Процессор: модель, ядра, потоки, частоты, кэш
lscpu

Память, накопители, сеть

# Память
free -h
sudo dmidecode -t memory | grep -E 'Size:|Speed:|Type:|Locator:|Part Number:'

# Накопители
lsblk -o NAME,SIZE,TYPE,MODEL,MOUNTPOINT
df -hT
sudo smartctl -a /dev/nvme0n1 | grep -E 'Model|Capacity|Percentage Used|Power_On_Hours|Temperature'

# Сеть
ip -br a
lspci | grep -i -E 'ethernet|network'
sudo ethtool eth0 | grep -E 'Speed|Duplex|Link detected'

Два поля, которым нельзя доверять без проверки по спецификации.

Второй случай — скорость сетевого канала. Порт 2,5 Гбит/с регулярно поднимается на 1000 Мбит/с из-за кабеля категории ниже требуемой либо ограничений коммутатора. Проверка ethtool выполняется на этапе приёмки, а не после того, как резервное копирование упёрлось в потолок скорости.

Единый отчёт о состоянии сервера

Ручной сбор данных плохо воспроизводится, поэтому диагностику удобнее оформить сценарием с выводом в файл.

#!/bin/bash
# sysreport.sh — единый отчёт о состоянии сервера
OUT="server-report-$(hostname)-$(date +%F).txt"
{
  echo "=== СИСТЕМА ==="
  hostnamectl
  echo
  echo "=== ПЛАТА И ПРОШИВКА ==="
  sudo dmidecode -t system -t baseboard -t bios | grep -E 'Manufacturer:|Product Name:|Version:|Release Date:'
  echo
  echo "=== ПРОЦЕССОР ==="
  lscpu
  echo
  echo "=== ПАМЯТЬ ==="
  free -h
  echo
  sudo dmidecode -t memory | grep -E 'Size:|Speed:|Type:|Locator:|Manufacturer:|Part Number:'
  echo
  echo "=== НАКОПИТЕЛИ ==="
  lsblk -o NAME,SIZE,TYPE,MODEL,MOUNTPOINT
  echo
  df -hT
  echo
  for d in /dev/nvme?n1 /dev/sd?; do
    [ -e "$d" ] || continue
    echo "--- $d ---"
    sudo smartctl -a "$d" 2>/dev/null | grep -E 'Model|Capacity|Percentage Used|Power_On_Hours|Temperature|Power Cycles'
  done
  echo
  echo "=== СЕТЬ ==="
  ip -br a
  echo
  lspci | grep -i -E 'ethernet|network'
  echo
  for i in $(ls /sys/class/net | grep -v lo); do
    echo "--- $i ---"
    sudo ethtool "$i" 2>/dev/null | grep -E 'Speed|Duplex|Link detected'
  done
  echo
  echo "=== ТЕМПЕРАТУРЫ ==="
  sensors 2>/dev/null
  echo
  echo "=== ТЕПЛОВАЯ ЗАЩИТА ==="
  for c in /sys/devices/system/cpu/cpu*/thermal_throttle/core_throttle_count; do
    [ -e "$c" ] || continue
    echo "$c: $(cat "$c")"
  done
  echo
  echo "=== ЧАСТОТЫ И РЕЖИМ ==="
  cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor 2>/dev/null
  cat /sys/devices/system/cpu/intel_pstate/max_perf_pct 2>/dev/null
  echo
  echo "=== НАГРУЗКА ==="
  uptime
} | tee "$OUT"
echo
echo "Отчёт сохранён: $OUT"

chmod +x sysreport.sh
./sysreport.sh

Шаг 2. Температуры и вывод sensors

sudo sensors-detect --auto
sensors

Ключевые строки вывода:

• Package id 0 или Tctl — температура кристалла целиком, основной показатель;
• Core 0…N — потемпературно по ядрам, показывает неравномерный контакт радиатора;
• Composite в разделе nvme — накопитель, штатный диапазон до 60–70 °C;
• high и crit — пороги включения защиты и аварийного отключения.

Шаг 3. Счётчик срабатываний тепловой защиты

Абсолютная температура малоинформативна. Значение 72 °C при пороге 105 °C выглядит как запас, но не говорит ничего о том, сколько раз кристалл уже упирался в предел.

cat /sys/devices/system/cpu/cpu0/thermal_throttle/core_throttle_count
uptime

Счётчик инкрементируется каждый раз, когда ядро достигло предельной температуры и было принудительно замедлено. Значение обнуляется при перезагрузке, поэтому читается исключительно вместе с временем работы системы.

Счётчик за сутки работы	Интерпретация
0	Тепловая проблема отсутствует
Единицы	Кратковременные пики под нагрузкой, приемлемо
Десятки	Охлаждение на пределе, запаса нет
Сотни и больше	Инфраструктура работает в аварийном режиме

Практическую ценность имеет прирост, а не абсолютное число:

C1=$(cat /sys/devices/system/cpu/cpu0/thermal_throttle/core_throttle_count)
sleep 300
C2=$(cat /sys/devices/system/cpu/cpu0/thermal_throttle/core_throttle_count)
echo "Прирост за 5 минут: $((C2 - C1))"

Шаг 4. Журнал ядра и аварийные отключения

last reboot | head -5
journalctl -k -b    | grep -i -E 'thermal|throttl|mce' | tail -20
journalctl -k -b -1 | grep -i -E 'thermal|critical temperature|mce|hardware error' | tail -20

Строка Critical temperature reached в предыдущей загрузке означает самостоятельное отключение по перегреву. Записи mce (Machine Check Exception) фиксируют аппаратные ошибки, которые тепловая нестабильность вызывает регулярно.

Короткие значения uptime вперемежку с такими записями складываются в однозначную картину: машина циклически уходит в защитное отключение, а причина ошибочно списывается на нестабильное питание.

Шаг 5. Как ограничить производительность процессора

Стресс-тест на этом этапе избыточен и вреден: данных для диагноза достаточно, дополнительная нагрузка только ускоряет деградацию. Ограничение вводится немедленно.

Процессоры Intel с драйвером intel_pstate

echo 40 | sudo tee /sys/devices/system/cpu/intel_pstate/max_perf_pct
echo powersave | sudo tee /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor

Подробности работы драйвера описаны в документации ядра по intel_pstate.

AMD и системы без intel_pstate

Там, где max_perf_pct недоступен, предел задаётся частотой через cpufreq. Универсальный сценарий определяет доступный способ самостоятельно:

#!/bin/bash
# cpu-limit.sh — ограничить производительность процессора заданным процентом
# Использование: ./cpu-limit.sh 40
set -e

PCT="${1:-40}"

if [ "$PCT" -lt 10 ] || [ "$PCT" -gt 100 ]; then
  echo "Допустимый диапазон: 10–100"
  exit 1
fi

if [ -w /sys/devices/system/cpu/intel_pstate/max_perf_pct ]; then
  echo "$PCT" > /sys/devices/system/cpu/intel_pstate/max_perf_pct
  echo "intel_pstate: потолок производительности $PCT%"
else
  for c in /sys/devices/system/cpu/cpu[0-9]*/cpufreq; do
    [ -e "$c/cpuinfo_max_freq" ] || continue
    MAX=$(cat "$c/cpuinfo_max_freq")
    MIN=$(cat "$c/cpuinfo_min_freq")
    TARGET=$(( MAX * PCT / 100 ))
    [ "$TARGET" -lt "$MIN" ] && TARGET="$MIN"
    echo "$TARGET" > "$c/scaling_max_freq"
  done
  echo "cpufreq: верхняя частота ограничена $PCT% от максимума"
fi

for g in /sys/devices/system/cpu/cpu[0-9]*/cpufreq/scaling_governor; do
  [ -e "$g" ] || continue
  if grep -q powersave "${g%governor}available_governors" 2>/dev/null; then
    echo powersave > "$g"
  fi
done
echo "Регулятор частоты переведён в powersave"

Закрепление ограничения после перезагрузки

sudo install -m 755 cpu-limit.sh /usr/local/sbin/cpu-limit.sh

sudo tee /etc/systemd/system/cpu-limit.service > /dev/null <<'EOF'
[Unit]
Description=Ограничение производительности процессора при недостатке охлаждения
After=multi-user.target

[Service]
Type=oneshot
RemainAfterExit=yes
ExecStart=/usr/local/sbin/cpu-limit.sh 40

[Install]
WantedBy=multi-user.target
EOF

sudo systemctl daemon-reload
sudo systemctl enable --now cpu-limit
sudo systemctl status cpu-limit --no-pager

Возврат к штатному режиму после ремонта охлаждения:

sudo systemctl disable --now cpu-limit
sudo /usr/local/sbin/cpu-limit.sh 100

Шаг 6. Проверка результата

cat /sys/devices/system/cpu/cpu0/thermal_throttle/core_throttle_count
sleep 300
sensors | grep -E 'Package|Tctl'
cat /sys/devices/system/cpu/cpu0/thermal_throttle/core_throttle_count

Продолжающийся прирост счётчика на 40 процентах означает, что причина не в частотах. Остаются механические варианты: потерян контакт радиатора с кристаллом, деградировала термопаста, забит пылью канал продува, остановлен вентилятор. Машина выводится из эксплуатации и разбирается — программные меры исчерпаны.

Чего ограничение частоты не решает

Это временная мера, а не устранение причины

Ограничение останавливает деградацию на период до замены вентилятора или термопасты. Постоянным режимом эксплуатации оно не является: теплопакет никуда не делся, изменилась только рабочая точка.

Запас измеряется под нагрузкой, а не в простое

Значение 60 °C при нулевой загрузке ничего не гарантирует. При реальном трафике или перестроении индексов базы данных разница до порога закрывается за минуты. Оценка ведётся по худшему случаю.

Просадка затрагивает все службы сразу

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

free -h
vmstat 1 5          # столбцы si/so — ненулевые значения означают исчерпание памяти
sudo iotop -o       # источник нагрузки на накопитель

Пассивное охлаждение компактного корпуса — недостижимый сценарий

Вентилятор ставится производителем не для запаса: радиатор рассчитан на принудительный обдув и без него достигает собственного предела за считанные минуты независимо от теплопакета процессора. Демонтаж вентилятора ради снижения шума в production-инфраструктуре недопустим.

Порядок действий одним списком

1. Снять полную картину железа, не доверяя строке Maximum Capacity и заявленной скорости сетевого порта.
2. Прочитать вывод sensors. Отсутствие данных о вентиляторе указывает на неподдерживаемую микросхему Super I/O, а не на отказ.
3. Считать core_throttle_count вместе с uptime. Прирост счётчика в простое — аварийное состояние.
4. Проверить журнал предыдущих загрузок на Critical temperature reached и записи mce.
5. Немедленно ограничить производительность до 40 процентов и закрепить службой systemd.
6. Через пять минут убедиться, что счётчик перестал расти.
7. Запланировать физическое обслуживание: вентилятор, термопаста, очистка канала продува.

FAQ

Почему нагрузка нулевая, а процессор сбрасывает частоту?

Тепловая защита реагирует на температуру кристалла, а не на утилизацию. При отсутствующем обдуве даже базовое энергопотребление в простое выводит кристалл к порогу, поскольку рассеивание тепла нарушено физически.

Какое значение core_throttle_count считать нормой?

Нормой является ноль либо единичные срабатывания за сутки непрерывной работы под пиковой нагрузкой. Десятки срабатываний означают отсутствие теплового запаса, сотни — эксплуатацию в аварийном режиме.

Чем core_throttle_count отличается от package_throttle_count?

Первый счётчик фиксирует ограничение отдельного ядра, второй — ограничение пакета целиком по общему тепловому бюджету или пределу энергопотребления. Оба расположены в /sys/devices/system/cpu/cpu*/thermal_throttle/ и читаются совместно.

Ограничение через intel_pstate или через cpufreq — что выбрать?

При наличии max_perf_pct используется intel_pstate: параметр задаёт потолок в процентах и корректно взаимодействует со штатной логикой турбо-режима. На платформах AMD и в конфигурациях с драйвером acpi-cpufreq предел выставляется напрямую через scaling_max_freq.

Помогает ли отключение турбо-режима вместо ограничения процентом?

Отключение no_turbo снимает пиковые всплески энергопотребления, но не ограничивает базовую частоту. При тяжёлой тепловой неисправности этой меры недостаточно, при пограничной — достаточно и она дешевле по потерям производительности.

Нужен ли стресс-тест для подтверждения диагноза?

При растущем в простое счётчике диагноз подтверждён и нагрузочное тестирование только ускоряет деградацию. Стресс-тест применяется после ремонта охлаждения для проверки восстановленного теплового запаса.

Как контролировать состояние накопителей в той же ситуации?

Температура NVMe отображается в разделе Composite вывода sensors и в атрибутах SMART. Инструментарий и перечень атрибутов описаны в документации smartmontools.

Заключение

Тепловая диагностика сервера строится не на абсолютной температуре, а на счётчике срабатываний защиты, прочитанном совместно со временем работы системы и журналом ядра: именно эта пара показателей отличает штатный пик под нагрузкой от аварии, при которой железо разрушается в простое. Программное ограничение частоты через intel_pstate или cpufreq, закреплённое службой systemd, останавливает деградацию за пять минут и удерживает инфраструктуру в рабочем состоянии до физического обслуживания охлаждения — но остаётся именно временной мерой, а не заменой вентилятору и термопасте.