那台机器是我给客户搭的，配置写着8核16G，跑的是一个不算重的 Java 服务。白天一切正常，接口响应稳定在80毫秒左右。结果有天晚上客户反馈说：网站偶尔会卡一下，尤其后半夜提交表单的时候要等好几秒。我第一反应是数据库慢查询，或者是内存不够开始 swap 了。
登录机器一看，完全不是那么回事。CPU 使用率只有30%上下，load average 也正常，swap 根本没动。那既然 CPU 没满、内存也没满，为什么会慢？
后来排查发现，问题出在散热上CPU 核心温度撞上了温度墙，主频被硬件自动降了下来。机器标称8核，跑起来却只相当于6核的劲。这篇就把这套排查思路完整写下来：先看温度和频率的关系，再看风扇和散热片，最后看机房的物理环境。
如果你手上的服务器或独立机器需要长期满负载跑计算任务，散热和机房条件直接决定你能不能跑满核，选机器时可以先看看这几家的机房与硬件规格说明再下单：景文互联（IDC 机房与独立服务器）很多虚拟化主机的散热是被超售摊薄的，独享机房的物理散热条件才是满载跑计算的底线。
一、温度墙到底是什么，为什么它比你想的更普遍
CPU 出厂的时候设了一个最高结温（比如 95℃ 或 100℃），也设了一个最高可持续的封装功耗。这个结温是芯片内部，也就是 die 的温度，不是你用温度枪对着散热片测的那个外壳温度。
当核心温度逼近这个上限，处理器不会关机，也不会报错，它会做一件更隐蔽的事降频。CPU 把主频往下压，通过降低单位时间内的功耗来换取温度不再上升。这个过程在 Linux 里几乎没有任何提示，日志里也看不到，顶多在 dmesg 里偶尔冒一句 thermal throttling。
关键的地方在于：降频是按比例发生的，而且可能只在高负载的那几秒里发生。你如果只是随手看一眼监控面板上的 CPU 曲线，很难把「温度高」和「主频低」这两件事联系到一起。
我自己那台机器的情况还更复杂一点：它不是一直烫，而是到了后半夜，机房空调温度降下来之后反而更容易出事。这种反直觉的现象当时把我折腾了整整两天。
二、第一步：把频率和温度同时抓下来，别只看其中一个
单独看温度没意义，单独看频率也没意义，必须两条线放在一起对齐时间轴。我一般用下面这几条命令抓一轮数据：
grep MHz /proc/cpuinfo 看当前每个核心的实时主频；sensors 看温度传感器读数，需要装 lm-sensors；cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq 看 cpufreq 驱动认为的当前频率；cat /sys/devices/thermal/thermal_zone*/temp 看内核的热区温度。
关键动作是：一边压满负载，一边持续记录。用 stress-ng --cpu 16 或者 yum install stress 造一个持续满载，然后每两秒记一次温度和频率，样本攒够三五分钟，曲线形状就出来了。
我那台机器的曲线很有代表性：空载主频 3.0GHz（因为没负载，节能策略让它降下来了，这很正常），压测起来瞬间冲到 3.8GHz，然后温度爬到 96℃，主频开始往下掉，最后稳定在 2.9GHz 上下震荡。也就是说，标称的 8 核在满载时的实际表现只有 6 核多一点。
还有一个坑要提醒：温度墙和普通降频在监控上是两回事。普通降频是 CPU 没负载，节能策略主动降的，属于正常行为；温度墙降频是「有负载、有温度压力、被迫降频」，这才是要处理的问题。看监控的时候一定要把频率曲线和负载曲线叠在一起看。
三、第二步：查散热片和风扇，这两个最容易被忽略
温度墙被触发，根因无非两类：散热能力不足，或者散热能力被什么东西削弱了。绝大多数情况属于后者。
我这台机器犯的第一个错，是买回来就塞进了一个杂牌机箱，为了塞下主板，散热器压得死死的，硅脂是出厂随便涂的一层。第二个错更隐蔽机器搬进机房之后，机箱侧板一直没装，风道完全走的是乱流。
检查顺序建议这样走：
一看风扇转速。sensors 输出里的 fan1/fan2 如果是 0 或者几百转，说明风扇根本没转或者转不起来，直接白莲花式散热等于没有。
二看硅脂和压合。用了两三年的机器硅脂干裂是常态，拆开散热器能看到膏体已经发白发裂，那种情况散热效率能掉一半以上。
三看风道。机箱风扇的进风与出风方向要对，形成一条从前往后的通路，不要让热风在机箱里打转。
四看机箱滤网和灰尘。机房灰尘大的话，滤网半年不清理就能把风量砍掉三成，而风扇为了维持转速会拼命拉高转速，噪音先变大，然后温度跟着上去。
顺带说一句，如果你的机器是虚拟化出来的主机，物理层面的散热你根本管不了，那就要转去关注虚拟化层的限制：speedonline（服务器与主机方案）这类商家提供的配置与资源说明里，能不能拿到裸金属或者独享 CPU 的选项，直接决定了你会不会跟同机房的邻居抢散热余量。
四、第三步：软件层面的几个兜底手段
物理散热改不动的时候，还有几件事可以做，效果没有换散热器那么立竿见影，但能缓解。
第一是给核心降温降频率的关联设置做减法。生产机上把没用的后台任务、编译任务、非关键容器停掉，CPU 平均温度降个三五度并不难。
第二是调整 cpufreq 的策略。把 scaling_governor 从 performance 改成 powersave，会让 CPU 更倾向于在低频区间工作，反而可能减少温度墙上限被触碰的概率，但峰值性能会下降，取决于你的业务是吃突发还是吃平均。
第三是限制睿频和功耗。用 intel_pstate 的 max_perf_pct 或者 AMD 的 max_boost_freq 把最高频率封在出厂频率的 90% 左右。这招看起来像是自欺欺人少那 10% 性能你不心疼，但换来的是全天不撞温度墙，尾延迟反而更稳。
第四是配一条温度告警。阈值别设在 90℃ 这种拍脑袋的数上，先跑一轮满载测出你这台机器的稳定温度基线，再定线。我的做法是把基线上浮 8 度作为告警阈值，同时加一条「频率低于基线频率 85% 且负载高于 60%」的组合条件，后者才是真正指向温度墙的信号。
五、怎么确认你确实修好了
改完之后一定要重跑一遍同样的压测，对比三组数：峰值主频是不是能稳在标称附近、温度曲线是不是不再贴着上限、以及最关键的同样负载下的接口响应时间是不是回到了之前的水平。我那台机器把机箱侧板装回去、换了一把好硅脂、把两台风扇换成转向正确的型号之后，满载主频稳在了 3.9GHz，温度压在 78℃，接口响应从最差时的 2.3 秒回到了 90 毫秒。
回过头来看，这件事最值得记下来的地方是：「服务器变慢」这个现象，未必能在 CPU 占用率里看出来。温度墙降频属于是硬件层面的自我保护，它不留日志、不报警、监控面板上全是绿的，但它实实在在地拿走了你的性能。以后再遇到「明明没满载却变慢」的情况，除了内存和数据库，散热值得排进检查清单。
喜欢 
顶
难过
囧
围观
无聊
