★ FEATURED ARTICLE 半夜被监控告警吵醒抄起手机一看机房某台服务器 CPU 温度已经飙到 93 度。这种时候最磨人——不处理怕硬件提前报废立刻停机又影响线上业务。跑过去看了眼风扇全速在转出风口的风烫手机器表面摸上去都温热了。这不是个例几乎每个做运维的人迟早都会遇到一遍。CPU 温度过高这件事说大不大说小也不小但处理起来往往不是单靠清个灰就能解决也不是光调个参数就万事大吉必须物理处理和软件处理两条腿一起走还要分清楚当前到底处于哪个阶段。这篇文章我想把服务器 CPU 温度过高这件事从头到尾捋一遍什么样的温度该紧张物理层面有哪些动作值得做软件层面又该怎么调、怎么管以及一次完整排查链路应该怎么走。适合刚接手服务器维护的新手也适合遇到玲珑怪毛病想系统梳理一遍的资深运维。1. 先搞清楚CPU 温度多高才算“过高”很多人看到 70 度就开始慌了看到 85 度就觉得要出事。实际上单看温度绝对值没有意义CPU 的温度标尺是 Tjmax——内核允许的最高结温也就是芯片内部允许达到的极限温度。不同型号的 CPUTjmax 差别很大。拿主流的两大平台举例Intel Xeon 的 Tjmax 大多是 100 度左右AMD EPYC 某些型号可以到 95 到 100 度而老平台的酷睿系列可能只有 80 到 90 度。如果只是看监控面板上的数字就统一按 85 度报警很可能误伤了本来运行完全健康的机器也可能漏掉了真正危险的隐患。所以第一步应该是查清你这台服务器 CPU 的具体规格确认它的 Tjmax 是多少。那什么样的温度算正常我的经验是把运行温度分成三个区间舒适区满载时 60 到 75 度待机 40 到 55 度。这说明散热余量充足是理想工作状态。临界区满载时 80 到 85 度偶尔瞬间冲到 90 度但能快速回落。这个区间要开始留意了虽然还没到降频保护线但长期这么跑会明显加速电子迁移影响寿命。危险区持续 90 度以上甚至顶到 Tjmax 附近。这时候 CPU 会自动降频甚至触发保护性关机业务会直接受影响必须尽快处理。这里要特别说明一个误区同样一个温度数值在冬天和夏天含义完全不同。如果机房空调故障、环境温度整体升高CPU 温度也会同步抬升。所以我评估温度时一定会带上一个基线概念——同一台机器在室外温度 25 度和 35 度时满载温度差个 5 到 8 度都很正常。合理的做法不是盯死一个数字而是观察温度和负载的关系是否失衡。判断 CPU 是否过热的直接信号除了监控面板数值还有一个隐藏指标超线程和自动睿频是否还在正常工作。当温度逼近 Tjmax系统会一步步降低频率如果发现同样业务的 CPU 使用率没变但响应时间明显变长这就是降频的表现之一。这个现象往往比温度数字更早暴露问题。2. 物理处理的完整动作清单从环境到硬件的落地操作2.1 环境层机房气温、机柜位置的细节常常被忽略先说一个我踩过的坑。某次接手一台持续高烧的服务器CPU 温度常年比同批次其他机器高十几度硅脂重新涂过、风扇换过新的温度只降了一点点。后来检查机房布局才发现这台机器所在的机柜被夹在了两排高密度设备中间前面是封闭玻璃门后面紧贴墙壁进风侧基本被堵死了等于每时每刻都在呼吸别人排出的热风。把机柜挪了位置之后温度直接降了 15 度。物理处理的第一步不在机器身上而在环境。具体可以检查这几项机房空调出风温度是否正常设定值是否在 18 到 27 度这个常见区间内回风口有没有被物品挡住。机柜前后门的通风率是否足够。有些为了安全装的玻璃门几乎没有透气孔这种机柜是所有风冷设备的杀手。机柜内部是否有合理的进风空间设备之间的间距是否过小。密集堆叠会让后排设备吸入的都是前排的废热。地板送风或者空调送风口是否正好对着机柜进风方向。热环境的基本逻辑很简单服务器散热靠的是带走热量而不是降低自身发热。进风温度每下降 1 度CPU 核心温度大约能下降 0.8 到 1 度。环境不搞干净后面所有硬件操作都是事倍功半。2.2 硬件层除尘、硅脂与散热器的实操细节环境没问题之后大概率就是硬件本身的状态问题了。按操作顺序排列最常见的手段有以下几种。清灰是成本最低、见效最快的动作。长期运行的服务器风扇积灰后风量会明显下降散热鳍片上的灰尘更是直接形成隔热层把热量捂在里面。清灰要注意一定用防静电刷加压缩空气断电之后彻底操作。压缩空气除尘时不要让风扇叶片高速转动否则反过来会发电有可能弄坏主板电路。正确做法是先固定住风扇叶片再吹或者用低压气流慢慢吹。重新涂抹硅脂看起来简单其实很多人操作不规范。旧硅脂完全清除干净之后新硅脂的涂法有讲究。桌面端常用中心点法也就是在 CPU 顶盖中心挤绿豆大小的一点靠散热器压平展开。服务器场景下我反而更推荐薄抹法——用刮片把硅脂均匀摊开成一整层薄膜因为服务器的散热器底座往往比桌面端大很多单靠压力顶开中心点四角容易缺硅脂。厚度控制在半透明状态最好能看到底下的字但又有一层膜宁少勿多。硅脂型号方面追求性价比选常见的含银导热硅脂就行不推荐在服务器上涂液金导电风险太高。散热器的性能也是决定温度上限的关键。我自己整理过一个简单对比供参考散热方案适用场景关键字日常成本原厂铝挤散热器低功耗、低密度业务便宜、够用风扇易积灰塔式风冷铜管散热器标准 1U/2U 机架追求稳定热管多、鳍片大需要清灰高转速涡轮风扇模组高密度刀片服务器风压大、转速高噪音极大一体式液冷高端工作站、GPU 服务器安静、散热上限高有泄漏风险换散热器时要确认两件事一是扣具和接口是否和主板匹配二是散热器高度是否卡得住机箱盖板。1U 机箱内装塔式散热器直接盖不上盖这种失误在机房现场见过不少次。2.3 风道设计正压负压、盲板和冷热通道硬件层面的另一大块是机柜和机箱的风道设计。机柜层面最经典的是冷热通道隔离方案——机柜正面朝向冷通道背面朝向热通道空调冷风进正面热风从背面排出不让冷热空气混在一起。如果机房条件不允许也要保证机柜正面不能贴墙、背面不挡排风。机箱层面有几个容易被忽视的点空余的硬盘位、PCIe 挡板位能装盲板就装盲板。盲板的作用是强迫气流沿发热元件方向流动而不是从空位直接溜走。一个开了孔的 PCIe 挡板会让机箱内部风压大幅下降CPU 温度能直接抬升好几度。前面板进风口如果有多组风扇位尽量保证每台风扇转速一致。追求节能的一方风扇快一方慢会在机箱内部形成紊流反而降低整体散热效率。某些支持风扇热插拔的机型缺一个风扇模块系统会自动提高剩余风扇转速来补偿。这个设计本意是好的但长时间让其他风扇超转运行会加速轴承磨损导致噪音和振动越来越大。物理处理这块我的建议是先环境再硬件后风道。每一步做完都要重新观察温度变化再决定是否进行下一步不要上来就把硬件全部换一遍。正常情况下清灰加重新涂硅脂就能解决掉至少一半的 CPU 温度异常问题。3. 软件层面的监测与调控让系统主动帮你降温3.1 先把温度观测做准再谈控制软件处理的第一步其实是观测。你连当前温度都读不准后面所有调整都是盲人摸象。不同平台有不同的采集方式我这里直接列常用的。Linux 系统下最常见的是 lm-sensors 全家桶。安装后先运行 sensors-detect按提示一路 yes让内核加载对应传感器驱动。然后查看sensors输出里会明确列出 CPU 各核心温度、主板温度、风扇转速等。如果服务器支持 IPMI那么 ipmitool 是更底层、更可靠的采集方式它直接走 BMC 读取传感器数据不受操作系统负载影响ipmitool sensor list | grep -i cpu ipmitool sdr list | grep TempIPMI 的另一个好处是能直接查告警阈值。很多服务器出厂设定的温度上限告警在 85 度这些阈值可以通过 BMC 网页界面调整。我自己一般会把告警阈值分成两级警告 80 度严重 90 度这样既不会天天被误报告警骚扰也不会漏掉真正危险的隐患。如果是整个机房的监控视角我自己习惯用 Prometheus 加 node_exporter 去采集 CPU 温度指标再配 Grafana 做可视化面板。node_exporter 暴露的 node_hwmon_temp_celsius 指标可以直接套用在告警规则里。这套组合的好处是能够长期记录温度曲线真正排查问题时历史曲线往往比当前数值更有说服力。Windows Server 平台用 Core Temp 或者 HWiNFO 看温度就够了。微软自家的机器远程管理工具也能直接通过系统管理界面查看 BMC 传感器状态适合带外管理。3.2 CPU governor、频率锁定与降压观测工具就位后就是真正的软件调优。当前 CPU 频率策略是最直接的软件降温手段之一。Linux 内核里的 CPU 调频框架通过 governor 决定频率怎么变化。默认的 performance governor 会尽量把频率维持在最高档发热量自然最大powersave 则相反一直压最低频省电但性能损失明显。最常见的 ondeman 和 schedutil 是动态调节模式负载高升频空闲降频。温度高的机器我建议使用 schedutil它是目前基于调度器负载信息的默认方案反应比 ondemand 更灵敏也更符合现代内核的调度节奏。切换方式sudo cpupower frequency-set -g schedutil开机自动生效就写到 systemd 服务里或者在 /etc/rc.local 里加一行。除了调频策略另一个手段是主动降压 undervolt 。同一个 CPU 在低于默认电压下仍能稳定运行是常见现象降压后同频功耗明显下降温度自然跟着降。Linux 下可以用自制脚本调用 MSR 寄存器调整但这个操作风险高、影响面大不建议在服务器环境里常态化使用。仅在前面几十条链路都验证没问题、温度还差一点点时作为最后一档调试手段去试用而且必须小步调整、每步都做稳定性测试。还可以考虑限制睿频上限。很多服务器 BIOS 里有 Turbo Mode 开关或者可以通过系统工具限制最大频率。有些场景下放开全核睿频会带来很可观的发热量而业务根本用不满那么多频率。把 CPU 最大频率从 4.0 GHz 限制到 3.2 GHz一般业务完全无感但满载温度能降低 8 到 10 度。这类调整对数据库这类延迟敏感型业务要额外评估因为主频直接决定单线程延迟。3.3 风扇策略与自动调控服务器风扇默认是 BIOS 自动温控模式温度升高转速跟着升高。问题在于默认策略往往偏保守传感器温度到 70 度左右风扇才开始加速导致温度在 70 到 80 度区间内反复振荡。这时候需要手动干预风扇曲线。Linux 下可以用 lm-sensors 自带的 fancontrol 工具。先跑 pwmconfig它会帮你识别哪些温度传感器对应哪些风扇 PWM 控制通道。自动生成的配置文件里核心是定义温度点和对应 PWM 值。我的习惯是让风扇在 50 度时起步加速60 度到 75 度之间线性爬升85 度以上直接拉满留一个比较陡但也比较稳的斜率DEVPATHhwmon0 DEVNAMEcoretemp FCTEMPS/sys/class/hwmon/hwmon0/temp1_input FCFANS/sys/class/hwmon/hwmon0/pwm1 MINTEMP50 MAXTEMP85 MINSTART80 MINSTOP30 MINPWM80 MAXPWM255这段配置的意思是温度低于 50 度时风扇保持最小转速高于 85 度时直接全速中间线性插值。MINSTART 和 MINSTOP 是风扇启动和停止的最小 PWM避免低转速下风扇转不起来或者停在临界位置嗡嗡作响。如果服务器走 IPMI还可以直接通过 ipmitool 控制风扇转速百分比ipmitool raw 0x30 0x30 0x02 0xff 0x64这条命令把风扇固定在 100%。这类命令在生产环境要慎用因为没有回退机制一旦温度异常系统可能无法及时拉高转速。比较稳妥的做法是通过服务商控制面板调整风扇策略或者写一个后台监控脚本温度超过阈值时自动请求全速、温度回落后恢复自动模式。3.4 面向业务的软件侧分流还有一类软件降温思路不是调硬件参数而是从业务负载侧入手。CPU 温度升高的直接原因是功耗功耗的源头是计算任务。如果一台服务器长期跑着占用大量 CPU 的业务同时又承载了不紧急的批处理任务完全可以错峰运行。通过 cron 把定时全量计算任务调整到凌晨低频时段。用容器编排平台给在线业务和离线业务分别打标签调度到不同节点池。对高负载 CPU 密集型任务设置 CPU 配额和极速限流防止一个失控进程吃满整台机器的物理核心。这种调度层面的处理短期看起来只是“分摊负载”长期看是避免 CPU 持续处于高负载发热状态的有效手段也是软件处理里最不折腾、副作用最小的一种方式。4. 一次完整排查链路参考从温度告警到根因确认前面的内容比较散我在这里用一次完整的排查过程把它们串起来。某天下午监控平台发出告警某台 2U 机架服务器 CPU 封装温度达到 88 度超警告线持续时间五分钟。第一步确认是不是误报。我先看了当前系统负载发现整机负载并不高CPU 占用率不到 20%可温度依然在 86 度以上。这种负载和温度严重不匹配的情况通常指向物理散热环节出了问题。反过来如果负载很高、温度高那主要是散热上限不足或者环境温度高两者处理思路完全不同。第二步看风扇状态。通过 IPMI 读取风扇模块状态发现所有风扇都在全速运行转速数据和出厂标称一致。这说明控制系统已经努力吹风但温度压不住说明热量根本没被带走或者发热源功率远超散热能力。第三步物理现场检查。打开机箱前面板发现进风侧积了一层灰但不算严重。进一步拆开散热器发现硅脂已经完全干裂形成了类似硬壳的钙化层。CPU 顶盖和散热器底座之间有肉眼可见的缝隙。原以为多数是风扇问题结果风扇反而是最后还没坏的组件。重新清理、重新涂抹硅脂、装回并固定好散热器之后开机空载温度从 55 度降到 36 度满载运行十分钟稳定在 72 度左右问题解除。整个链条里最有价值的是中间的判断逻辑先验证温度数据和负载是否匹配再检查主动散热设备是否工作最后处理被动散热介质。这个顺序每次都能准确定位比盲目换风扇、盲目换 CPU 效率高多了。疑似环节验证方法常见结论温度误报用 IPMI 查询 BMC 原始传感器值并和系统读数比对有一方显示异常可能传感器漂移环境过热用红外热成像仪测机柜正面进风温度进风温度高于 28 度机房制冷有问题风扇失效读取所有风扇转速观察是否和负载联动转速拉满温度仍高风扇基本排除硅脂老化拆散热器后观察硅脂状态干裂、硬化的占大多数散热器安装问题检查扣具压力是否均匀、底座是否有明显不均缝隙常见于二手或频繁拆装机器需要提醒的是这种物理排查在保修期内的整机设备上要谨慎。拆散热器不会直接导致保修失效但操作过程中可能损坏内部引线而且确实有很多品牌机不支持非官方人员拆解核心散热组件。如果是品牌服务器还在维保期内优先开工单找售后做现场检测自己的动手处理留在出保之后。5. 长期运维视角散热预算与业务侧的代价权衡CPU 温度问题一次性解决了不代表以后就高枕无忧。散热系统的老化是一个长期过程风扇轴承的磨损、硅脂性能的衰退、散热鳍片的积灰都是按月甚至按年缓慢发生的。成熟运维团队通常会为散热问题做预算管理——给每台关键服务器设置温度基线和性能指标每月检查一次趋势。我自己的做法是每季度做一次温度巡检。挑一天业务低峰记录每台服务器空载、压力测试时的温度数据和历史同期数据对比。如果某台机器满载温度比去年同期高了 5 度以上即便还在告警线以内也会提前安排物理维护。另外要考虑的是散热策略和业务成本之间的平衡。有两个典型场景机柜整体温度偏高但单台负载不高。这时候优先处理机房制冷和气流组织而不是给每台机器换更大散热器。换散热器等于给每台机器加成本而改善风道一次的收益可以覆盖整个机柜。单台机器负载极高但它是不可替代的核心在线服务。此时先前做物理清理和软件调优收益有限更合理的选择是迁移负载扩容集群让核心业务在新的更健康节点上运行旧机器降载后做散热改造再重新加入集群。紧急状态下强行靠软件压频率也能继续跑但这只是续命方案不是正常投产方案。长期来看CPU 温度管理的本质是功耗管理和散热资源预算管理。要在成本、性能、可靠性三者之间找平衡点。没有一种配置能在所有场景下都最优关键是清楚当前这个节点的角色——是核心在线服务还是离线批量计算决定了你舍得为散热投入多少物理和软件层面的成本。6. 最后分享一个降温效果被低估的小操作折腾了这么多年服务器我最近发现一个很多人容易忽略的细节服务器前面板的防尘网。很多机器前端有一层磁吸式或者卡扣式防尘网新机器时候拆下来冲洗过用久了很多人就忘了它也能拆。当防尘网被灰尘糊住之后肉眼看起来只比原来灰了一点但进风量可能已经下降了四成以上。不要只盯着机箱内部清灰前面板防尘网至少每次巡检时拆下来看看必要时用清水冲净晾干再装回去。这个动作花不了五分钟降温效果却经常比换风扇还明显。我在一次巡检中无意中把某台机器的防尘网清洗干净后CPU 满载温度从 79 度直接降到了 67 度连侧面板都没打开过。从那之后我每次接到温度过高的工单都会在开箱之前先看防尘网是不是已经到了“透气困难”的状态。温度过高的处理本质上是一场体力活加脑力活的组合。体力活是清灰、涂硅脂、调风扇脑力活是搞懂温度从哪里来、要到哪里去、中间被什么挡住了。先做好物理侧的清理和散热布局再配合软件侧的监测与调频策略绝大多数温度问题都能在短时间内解决而且解决之后的效果是长期稳定的。
阅读完成 · 觉得有帮助？
