物理机负载长期偏低，未必等于资源选大了，但它一定是一个值得复盘选型口径的信号。 关键在于分清是"真闲置"还是"被监控口径骗了"前者该降配省钱,后者降了就要出事。
物理机负载长期偏低说明资源选大了吗
先把结论说透：负载低只是现象，不是结论，判断资源是否选大，要看的是峰值水位和增长斜率,而不是平均值。
CPU 长期低位意味着什么
一台 8 核物理机，top 里 CPU 使用率常年在 5%~15% 之间晃，cat /proc/loadavg 显示 load 1 分钟值长期在 0.5 左右,这算浪费吗？
算,但要先排除三种情况：
- 业务本身是突发型：白天几乎没量，晚上八点一个批处理任务把 8 核全部打满 20 分钟，这种情况平均值低是必然的，降配就会让批处理窗口从 20 分钟拉长到一小时。
- 压测留了余量：上线前做过压测，单机扛 3 倍日常峰值，那么日常跑在 15% 是设计结果,不是失误。
- 监控采样只看了平均值：
sar -u 1 300看 5 分钟粒度，或者只看 Zabbix 上那条平滑过的曲线,波峰早就被抹平了。
真正能说明"选大了"的信号是：连续 14 天以上，CPU 的 P95 和 P99 都低于核数的三分之一，且没有明显的周期性尖峰。
内存、磁盘 IO、带宽的"偏低"含义完全不同
这四类资源的判断逻辑不在一个维度上,用一张表说清楚：
| 资源类型 | 关键指标 | 常用命令 | "偏低"的判断 |
|---|---|---|---|
| CPU | P95 使用率、load/核数 | mpstat -P ALL 1、uptime |
长期低于核数 1/3 |
| 内存 | available、swap 使用 | free -h、vmstat 1 |
available 长期高于总内存 60% |
| 磁盘 IO | %util、await、IOPS | iostat -x 1、iotop |
NVMe 上 %util 参考价值有限，看 await |
| 带宽 | 峰值出/入带宽 | sar -n DEV 1、iftop |
峰值长期低于合同带宽 30% |
内存这块最容易误判，很多人看到 free 只有几百兆就以为内存紧张，buff/cache 是可回收的，真正要看 available 那一列，反过来，available 长期占到八成以上,才是内存选大的实锤。
物理机资源利用率多少算合适
行业共识认为，物理机的健康水位不是一个固定数字，而是跟业务形态绑定，业内专家指出，脱离业务谈利用率,等于脱离路况谈油耗。
计算密集型业务
这类业务 CPU 是主资源，合理区间一般在 50%~70%，低了浪费，高了排队严重，可以参考 pidstat -u 1 看单进程的 CPU 分布，如果一台上只跑一个进程、常年 20%,那就是典型的选大。
内存型业务
Redis、内存数据库、大页缓存这类，内存用掉 70%~85% 是正常甚至偏健康的，如果一台 256G 的机器上只用了 60G,那基本可以判定内存规格选过头了。
IO 密集型业务
看 iostat -x 1 的 await 和 aqu-sz（队列深度）。await 长期在个位数毫秒、队列深度小于 1，说明磁盘性能严重过剩，这种情况下降容量比降 CPU 更省钱。
网关、Web 前端类
这类业务的瓶颈通常不在单机性能，而在连接数和带宽，CPU 用 30% 但连接数打满的情况很常见，此时降 CPU 核数意义不大,要降的是带宽规格或机器数量。
物理机负载低要不要降配，先排除这几种假性偏低
动手降配之前，先自查这几条，踩中任何一条,降配都可能变成事故。
- 业务有明确波峰波谷：电商、票务、教育类业务，平峰期利用率低是常态，降配要看的是波峰能不能扛住,不是平峰好不好看。
- 监控口径偏差：load average 包含了 IO 等待和不可中断进程，CPU 空闲但 load 高，说明瓶颈在磁盘，这时候降 CPU 是南辕北辙。
- 冗余是设计的一部分：N+1 高可用、滚动发布、故障转移，这些都需要预留容量，一台机器挂掉后剩下的机器要能顶上,那日常水位就不可能高。
- 业务处于爬坡期：上线三个月，流量每月都在涨,现在低不代表半年后低。
判断方法很简单：把过去 30 天的监控拉出来，用 sar -u -f /var/log/sa/saXX 回放，找单日最高 5 分钟的 CPU 使用率，如果这个峰值都没超过核数的一半,降配才有讨论空间。
物理机选大了怎么降配省钱
这是最实际的部分，降配不是一键操作,走错顺序容易出问题。
第一步：拉够数据
至少 14 天，最好 30 天,要看的指标：
- CPU：P95、P99、单日峰值
- 内存：available 最低值
- 磁盘：await 峰值、容量使用率
- 带宽：95 计费值或峰值带宽
第二步：定位真正的瓶颈
用 vmstat 1 看 r 列（运行队列）和 b 列（阻塞进程）。r 长期大于核数，CPU 是真紧；b 有值，说明卡在 IO，两者都低,才是全面过剩。
第三步：选降配方式
- 同规格族内降配：8 核 32G 降到 4 核 16G，最直接，但要注意内存和 CPU 的配比是否还匹配业务。
- 迁移到更低规格机型：老一代 CPU 换新平台，核数减半但单核性能提升,实际算力不一定下降。
- 多业务混部：把两台各自 20% 利用率的业务合到一台，这是收益最高、风险也最高的做法，需要做好 CPU 亲和性绑定和内存 cgroup 隔离。
- 异构配比调整：有些业务吃内存不吃 CPU，可以选高内存低核数的规格,比通用型便宜不少。
第四步：灰度与回滚
不要一次全降，先降一档，观察 7 天，重点盯三件事：P99 延迟、错误率、队列长度，任何一项劣化超过可接受范围，立刻回滚，保留旧规格的快照或镜像,回滚窗口至少留两周。
华东地区物理机租用降配流程与成本考量
降配能不能省钱,跟计费方式和地域政策关系很大。
包年包月
：多数 IDC 和云厂商允许降配，但差价退还规则各不相同，有的按剩余周期折算退还，有的只支持到期后变更，走工单时把"降配后差价如何结算"问清楚,别只看月单价。
按量计费：灵活度高，随停随改，但单价通常比包年高出一截，长期低负载的业务，反而是从按量转包年+降配更划算。
华东地区的机房资源相对紧张，部分节点降配需要重新分配机位，可能涉及迁移，迁移窗口建议放在业务低峰期，同时确认公网 IP 能否保留IP 变了，DNS 和防火墙白名单都要跟着改。
还有一个常被忽略的点：软件许可证按物理核数计费，Oracle、部分商业数据库按核授权，降核能直接省下许可证费用，这部分钱有时比硬件差价还多，但如果软件是按实例或按用户授权,降配对许可证没影响。
什么情况下坚决不要降配
- 压测峰值水位已经接近 70%
- 未来半年有明确的大促、投放或业务翻倍计划
- 有合规要求的物理隔离，机器不能混部
- 单机故障后剩余容量无法承接全量流量
- 降配省下的钱，抵不上一次故障的损失
Q&A：物理机负载长期偏低与资源选型
物理机 CPU 常年 10% 以下，是不是肯定选大了？
不一定，先确认三件事：业务是否有突发尖峰、监控是否覆盖了峰值、是否有高可用冗余要求，三者都排除后，才能判定是选型偏大，真正确凿的证据是 P99 长期低于核数的三分之一。
物理机选大了怎么降配最稳妥？
顺序是：拉 30 天监控 → 定位瓶颈是 CPU、内存还是 IO → 选择同规格族降配或迁移到低配机型 → 灰度观察 7 天 → 保留回滚镜像两周，一次只降一档，不要跨两档操作,包年包月用户还要提前确认差价结算规则。
物理机资源利用率多少算合适？
计算密集型看 CPU 在 50%~70%，内存型业务看内存使用在 70%~85%，IO 密集型看 iostat 的 await 是否长期处于低位，没有通用数字，判断基准永远是业务的峰值水位和增长斜率,而不是平均值。