Как процессор охлаждается в стойке и что такое троттлинг в дата-центре

MAATRIX

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

Путь тепла от кристалла до улицы

Тепло от процессора уходит по цепочке из нескольких звеньев, и каждое из них может стать узким местом.

Сначала тепло снимается с кристалла CPU через теплопроводящую пасту (или, в серверных платформах последних лет, всё чаще через жидкий металл или предустановленную термопрокладку) на крышку процессора, а с неё — на подошву радиатора. В серверных платформах радиаторы почти всегда пассивные: сами по себе они не охлаждают, а просто увеличивают площадь теплообмена рёбрами. Охлаждает их поток воздуха, который через радиатор гонят вентиляторы шасси — обычно несколько высокооборотистых вентиляторов 40-80 мм в передней части сервера, а не один большой кулер, как в десктопе.

Дальше нагретый воздух выходит через заднюю панель сервера в так называемый горячий коридор (hot aisle) — пространство за стойкой, куда «дуют» все серверы ряда. Спереди при этом — холодный коридор (cold aisle), откуда серверы забирают воздух на вдох. Вся конструкция дата-центра строится вокруг разделения этих потоков: холодный воздух не должен смешиваться с горячим до того, как дойдёт до процессора.

Из горячего коридора воздух забирают кондиционеры (CRAC/CRAH-системы) или, в дата-центрах с фрикулингом, часть тепла отводится напрямую наружным воздухом через теплообменники — это дешевле электричества на охлаждение, но зависит от климата и сезона. Финальное звено — компрессоры и градирни, которые в конце концов сбрасывают тепло в атмосферу.

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

Что физически происходит при троттлинге

Троттлинг — это не «зависание» и не сбой, а штатный защитный механизм, встроенный в сам кристалл процессора. Современные CPU (и Intel, и AMD) имеют десятки термодатчиков прямо на кремнии, которые постоянно опрашиваются контроллером питания процессора.

Когда температура ядра приближается к предельной (для серверных Xeon и EPYC это обычно область 95-105°C в зависимости от модели — точное значение указано в спецификации конкретного процессора, ориентируйтесь на неё, а не на общие цифры), процессор начинает снижать множитель частоты по нескольким ядрам или по всему чипу. Это происходит на уровне микрокода и контроллера питания — операционная система не участвует в решении и часто узнаёт о нём постфактум, если вообще узнаёт.

Важное отличие от отказа оборудования: троттлинг — это плавное снижение производительности ради выживания, а не авария. Процессор жертвует скоростью, чтобы не дойти до аппаратного отключения (thermal shutdown), которое сработает, если частоты уже недостаточно, а температура продолжает расти. Иными словами, троттлинг — это первая линия защиты, а полное выключение по перегреву — вторая, на случай если первая не помогла.

Есть нюанс, который путает многих: троттлинг не обязательно означает «сервер сломан» или «его специально ограничили». Чаще всего это ответ на конкретное локальное условие — временный или постоянный, в зависимости от причины.

Причины троттлинга: не только сама нагрузка

Логично предположить, что троттлинг — это просто «слишком тяжёлая нагрузка для процессора». Это действительно самая частая причина: длительная 100% утилизация всех ядер (рендеринг, компиляция, майнинг, тяжёлые ML-инференсы) поднимает температуру кристалла до предела быстрее, чем короткие пиковые нагрузки, с которыми радиатор легко справляется. Но в реальной эксплуатации в стойке есть ещё несколько причин, которые не связаны с самой задачей:

• Забитый пылью радиатор. Даже в дата-центре с фильтрацией воздуха пыль и волокна со временем оседают на рёбрах радиатора и лопастях вентиляторов, снижая эффективность теплообмена. В колокейшене, где сервер физически не обслуживается годами, это накопительный эффект.
• Деградация или отказ вентилятора сервера. Серверные вентиляторы работают на высоких оборотах постоянно и изнашиваются быстрее десктопных. Один вышедший из строя вентилятор в блоке обычно компенсируется остальными (в серверном шасси они почти всегда резервированы и hot-swap), но если откажет второй — эффективность охлаждения падает резко.
• Локальный «hot spot» в ряду стоек. Даже при исправном кондиционировании воздух в холодном коридоре может неравномерно распределяться по высоте и длине ряда: юниты в верхней части стойки или в её конце (дальше от источника холодного воздуха) получают более тёплый воздух на вдохе, чем нижние юниты у начала ряда.
• Неправильная организация кабелей и заглушек в стойке. Незакрытые заглушками пустые юниты, кабели, перекрывающие вентиляционные решётки, — всё это создаёт локальную рециркуляцию горячего воздуха обратно в холодный коридор.
• Перегрузка самой системы охлаждения дата-центра. Рост плотности размещения (больше серверов на стойку, больше кВт на юнит) может выйти за проектную мощность кондиционирования конкретного ряда или зала, особенно в жаркий сезон при использовании фрикулинга.

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

Как заметить троттлинг: признаки без явных ошибок

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

Признаки, на которые стоит смотреть:

• Реальная частота CPU под нагрузкой ниже заявленной turbo-частоты и не растёт при наличии свободного теплового запаса. Это самый прямой признак — но нужен инструмент, который показывает именно текущую частоту, а не номинальную из характеристик.
• Производительность просаживается не сразу, а спустя какое-то время после начала нагрузки. Троттлинг по определению тепловой — ему нужно время, чтобы температура успела подняться. Если тест или бенчмарк в первые секунды показывает одни цифры, а через несколько минут устойчивой нагрузки — заметно другие, это тепловая деградация, а не изначальный лимит производительности.
• Просадка воспроизводится стабильно при одинаковом типе нагрузки, но не при кратковременных пиках. Короткие всплески CPU радиатор гасит без проблем — тепловая инерция работает в вашу пользу.
• Job, который раньше укладывался в определённое время, стал занимать заметно больше на том же классе задачи и том же объёме данных — без изменений в коде и без роста нагрузки со стороны — это повод проверить тепловой режим, а не только профилировать код.

Как проверить конкретно на Linux-сервере:

# Текущая частота всех ядер в реальном времени
watch -n1 "cat /proc/cpuinfo | grep MHz"

# Более подробно, через утилиту turbostat (пакет linux-tools)
turbostat --interval 5

# Проверка счётчиков троттлинга по тепловым событиям (Intel)
# ищите ненулевые значения счётчиков thermal throttling
sudo turbostat --show PkgTmp,CoreTmp,PkgWatt --interval 2

# Температура датчиков (пакет lm-sensors)
sensors

turbostat в частности показывает не только частоту и температуру, но и счётчики срабатывания тепловой защиты (PkgThr% — процент времени, проведённого в состоянии package throttling). Ненулевое и растущее значение здесь — прямое подтверждение, что процессор именно троттлится, а не просто работает на базовой частоте по другой причине (например, из-за энергосберегающего governor).

Стоит сразу исключить похожую по симптомам, но другую по природе причину — программный лимит частоты через cpupower или BIOS-профиль энергопотребления, который иногда путают с тепловым троттлингом:

cpupower frequency-info

Если governor стоит в powersave или частота искусственно ограничена в BIOS/IPMI профилем энергопотребления — это не троттлинг, а настройка, и лечится она иначе, без замены термопасты и чистки радиатора.

Что можно сделать при подозрении на троттлинг

Если признаки выше подтвердились, порядок действий обычно такой:

1. Проверить температуру компонентов через IPMI/iDRAC/iLO (в зависимости от платформы) — там же обычно видна скорость вращения вентиляторов и есть история срабатывания тепловых событий на уровне BMC, независимая от ОС.
2. Сверить показания с паспортными пределами конкретной модели процессора — Tjunction max и рекомендованный диапазон температуры на вдохе сервера (обычно 18-27°C для холодного коридора по стандартам ASHRAE, но у конкретного дата-центра могут быть свои настройки).
3. Если сервер в колокейшене или у вас есть физический доступ — визуально проверить радиатор и вентиляторы на предмет пыли и повреждений при плановом окне обслуживания.
4. Если сервер арендован — обратиться в поддержку провайдера с конкретными цифрами (частота, температура, время суток и характер нагрузки), а не с формулировкой «сервер тормозит». Провайдер, у которого мониторится температура и место в ряду стойки, сможет быстро проверить, не связано ли это с локальным hot spot или проблемой у соседей по ряду.
5. При выборе процессора для новой задачи заранее оценивать не только частоту в паспорте, но и TDP — процессоры с высоким TDP при равной эффективности охлаждения троттлятся раньше при долгой полной нагрузке. Если для вас критична стабильная производительность под sustained-нагрузкой, а не пиковая частота на бумаге, это стоит учитывать при выборе конфигурации — разница между AMD EPYC и Intel Xeon в этом смысле не сводится к количеству ядер, у платформ разная тепловая архитектура — подробнее это разобрано в сравнении AMD EPYC и Intel Xeon.

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

Частые вопросы