云平台上CPU利用率多少属于正常范围？

这是一个非常经典，但也是一个典型的“陷阱式”问题。

首先得泼一盆冷水：云平台上没有绝对的“正常范围”，只有“业务匹配度”。

如果你去问运维老鸟或者架构师，他们大概率不会直接给你一个数字（比如 60%），而是会反问你这几个关键变量：

1. 你的业务类型是什么？（高并发Web、大数据计算、还是离线批处理？）
2. 你的计费模式是什么？（按量付费、包年包月、还是抢占式实例？）
3. 你的SLA（服务等级协议）要求有多高？（允许宕机吗？延迟容忍度是多少？）

为了给你最落地的参考，我们把 CPU 利用率拆解成几种常见的场景来看，这样更真实，也更有参考价值。

1. 通用型/在线业务（Web Server, API, 微服务）

推荐区间：30% – 50%

这是最常见的场景。为什么不建议跑满？

• 突发流量保护：互联网业务都有波峰波谷。如果平时维持在 80%-90%，一旦遇到秒杀活动或突发热点，CPU 瞬间打满，响应时间（RT）会指数级上升，甚至导致雪崩。
• 上下文切换开销：当 CPU 长期处于高负载时，内核需要在进程间频繁切换，这本身就会消耗额外的 CPU 资源，导致实际可用算力下降。
• 弹性伸缩的缓冲：如果你用了自动伸缩组（ASG），保留一定的余量可以让扩容动作更平滑。如果 CPU 一直很高，扩容触发后可能已经晚了。

注意：这里的 30%-50% 是指平均利用率。在监控图表上，你看到的应该是锯齿状的波动，而不是拉成一条直线的 40%。如果是直线，说明你的代码可能有死循环或者逻辑问题，或者是负载极其不均衡。

2. 计算密集型/离线任务（Data Processing, Rendering, Batch Jobs）

推荐区间：70% – 90%

这类业务的特点是：我要的就是把这台机器榨干，尽快算完走人。

• 成本最优解：对于按量付费的计算节点，我们希望每一分钱都花在算力上。
• 容忍度高：这类任务通常对实时性要求不高，稍微慢一点没关系，只要能在截止时间前完成即可。

但是，即使是这类场景，也要避免长期 100%。因为一旦达到 100%，操作系统会出现严重的调度延迟，磁盘 I/O 等待也会增加，反而可能拖慢整体完成时间。留 10%-20% 给系统中断和垃圾回收（GC）是明智的。

3. 数据库/中间件（MySQL, Redis, Kafka）

推荐区间：20% – 40%（视具体组件而定）

• Redis：纯内存操作，CPU 占用通常很低。如果 Redis CPU 高了，通常意味着网络带宽打满了，或者 Key 设计有问题（如大 Key），这时候看 CPU 没意义，要看网络带宽和内存命中率。
• MySQL：复杂查询下，CPU 可以跑到 60%-80%。但如果超过 80%，通常意味着索引失效、SQL 写得烂或者连接数过多。数据库是 IO 密集型为主，CPU 只是辅助。如果 CPU 很高但 IO 很低，那是代码层面的性能瓶颈；如果 CPU 低但 IO 高，那是存储层面的瓶颈。

4. 容器化/K8s 环境

推荐区间：Pod 级别 40%-60%，Node 级别 60%-70%

在 Kubernetes 中，你需要区分 requests 和 limits。

• Requests：保证你能拿到的最低资源。
• Limits：你能占用的最高上限。

合理的配置是让 Pod 的平均使用率略高于 Request，但不要经常接近 Limit。如果 Node 级别的 CPU 长期高于 70%，K8s 的调度器可能会因为资源碎片化导致新 Pod 无法调度，或者引发 OOM（内存溢出）风险，因为 CPU 和内存往往是耦合调度的。

如何判断你的“正常”是否合理？

不要只看 CPU 百分比，要结合以下三个指标一起看：

1. Load Average vs CPU Cores

   • 在 Linux 中，top 命令里的 Load Average 不等于 CPU 利用率。
   • 如果你的服务器是 4 核，Load Average 为 4.0，说明所有核心都在忙，且可能有排队任务。
   • 如果 Load Average 是 2.0，但 CPU 利用率是 90%，说明大部分时间是阻塞状态（比如等磁盘 IO、等网络响应），这时候优化 CPU 没用，得优化 IO 或网络。

2. iowait（IO 等待）

   • 如果 CPU 利用率高，但其中 iowait 占比很大（比如超过 20%-30%），那恭喜你，你的瓶颈不在 CPU，而在磁盘或网络。这时候加 CPU 核心数是浪费钱。

3. 用户态 vs 内核态（User vs System）

   • User 高：代码逻辑复杂，算法效率低，或者有大量的计算。-> 优化代码。
   • System 高：频繁的上下文切换，锁竞争严重，或者驱动层问题。-> 优化并发模型，减少锁粒度。
   • Nice/Irq 高：后台任务多或中断多。-> 检查是否有定时任务堆积。

给国内云厂商用户的特别建议

既然你在用国内云平台（阿里云、腾讯云、华为云等），有几个坑要注意：

1. 超分比（Overcommitment）：
   很多共享型实例（如阿里云的 t5/t6，腾讯云的 S 系列）存在 CPU 积分机制或超分。这意味着你的 CPU 利用率可能看起来很高，但实际上是因为底层物理机过载导致的“邻居噪音”。这种情况下，即使你只用了 50% 的逻辑 CPU，体验也可能卡顿。解决之道：升级到高配通用型（如 g7, c7）或独占物理机实例。

2. 监控延迟：
   云平台的云监控（CloudMonitor）通常有 1-5 分钟的延迟。对于瞬时突发流量，你可能看到 CPU 飙升到 100% 时才收到告警，但此时业务已经受损了。解决方案：结合应用层监控（APM）和日志分析，而不仅仅依赖基础设施层的 CPU 指标。

3. 计费陷阱：
   如果你用的是按量付费，且 CPU 长期低于 10%，赶紧缩容或换小规格实例。云厂商的起步规格往往有一定冗余，但长期闲置也是浪费。反之，如果长期高于 80%，考虑购买预留实例（RI）或节省计划，或者开启弹性伸缩。

总结

• Web/API 服务：控制在 40%-60%，留出弹性空间。
• 计算/离线任务：冲到 80%-90%，追求极致性价比。
• 数据库：关注 IO 和 连接数，CPU 不是唯一指标，通常 30%-50% 较为健康。
• 核心原则：没有最好的利用率，只有最适合业务的利用率。 如果你的业务在 70% CPU 下依然能扛住双十一的流量，那对你来说就是正常的；如果在 30% 就崩了，那再低的利用率也是不合格的。

最后，建议你建立自己的基线（Baseline）。记录业务低谷期和高峰期的 CPU 表现，找到属于你自己的“正常范围”，而不是盲目套用别人的数据。