TG咨询CPU超售风险排查的难点，不在于找到一个“CPU使用率过高”的数字，而在于判断虚拟CPU是否真的获得了应有的物理计算时间。Linux虚拟机、Windows Hyper-V来宾系统和Kubernetes节点，都可能出现应用占用率不高、响应却变慢的情况。排查时应同时观察来宾机、虚拟化主机和业务进程三个层面。
先建立可比较的基线
没有基线，任何告警都容易误判。建议先选取业务正常时的工作日高峰，连续记录15至30分钟的CPU使用率、运行队列、steal time、iowait和请求延迟。批处理、备份或镜像构建期间的数据应单独标记，不能直接与在线业务混在一起比较。
在Linux中可以使用mpstat -P ALL 5 12观察各逻辑CPU，也可以结合sar -q 5 12查看运行队列。Windows环境可在性能监视器中关注Processor\% Processor Time、Processor Queue Length及Hyper-V相关计数器。若只保留平均CPU使用率，往往会漏掉短时调度等待。
CPU超售风险排查最常见的6个问题
1. 把来宾机CPU使用率当成全部答案
虚拟机显示的CPU使用率低，并不代表物理CPU没有争用。Linux的steal time表示虚拟机本应运行、却被虚拟化调度器安排等待的时间。通常，偶发的1%至3%不一定构成问题；如果在业务延迟升高的同一时段持续达到5%甚至更高，就应进一步核对宿主机负载。这个范围会受工作负载、采样间隔和虚拟化平台实现影响，不能脱离基线单独下结论。
2. 只看虚拟机，不看宿主机的分配比例
CPU争用常由过量分配引起。比如一台物理主机有16个物理核，却向多个虚拟机分配了远高于16的vCPU总量；在低峰期可能没有影响，高峰期则会同时争抢调度时间。排查时应汇总同一主机上的已分配vCPU、实际活跃vCPU和预留资源，并按时间窗口观察，而不是只查看某一台虚拟机。
- 列出宿主机物理核数、超线程情况以及所有来宾机的vCPU配置。
- 按小时统计活跃虚拟机数量，标记数据库、编译、视频转码等突发型负载。
- 将宿主机运行队列、CPU就绪或调度等待指标与来宾机延迟时间对齐。
3. NUMA拓扑与大规格虚拟机不匹配
双路服务器通常具有多个NUMA节点。本地内存访问延迟低，跨节点访问则需要经过互连通道。当一台虚拟机的vCPU数量接近或超过单个NUMA节点容量，却没有合理的虚拟拓扑时，可能表现为CPU使用率正常、内存访问变慢和延迟波动。数据库、Java堆较大或内存带宽敏感的任务尤其需要检查这一点。
可执行做法是先记录主机的NUMA节点数量和每节点核心数，再比较虚拟机vCPU、内存与节点边界。若缩小vCPU后吞吐没有明显下降、延迟反而稳定，说明原配置可能存在拓扑或调度问题。大规格虚拟机不一定比两台较小实例更合适。
4. 容器限额制造了“假性超售”
在Kubernetes中，节点CPU有余量，不代表容器一定能使用更多CPU。Pod的CPU limit会形成cgroup配额，达到配额后会被周期性限流；CPU throttling过高时，应用可能出现超时，而节点总体CPU使用率并不高。这属于容器资源配置问题，不应直接归因于虚拟化平台。
检查步骤包括：查看Pod的requests和limits，读取容器的CPU throttled time或对应监控指标，再与应用延迟、重启和队列长度对照。对于延迟敏感服务，应根据稳定负载设置合理的请求值，避免多个高峰服务共享过小的CPU上限；对于批处理任务，则可以接受更明显的波动。
5. CPU被其他任务周期性抢占
备份、病毒扫描、日志压缩、镜像构建和定时编译都可能制造短时峰值。此类任务未必让全天平均CPU超过80%，却会在几分钟内挤压在线服务的调度时间。排查时要把任务计划、进程级CPU、容器发布记录与延迟曲线放在同一时间轴。
- Linux可用pidstat按进程观察CPU和上下文切换。
- Windows可按进程查看CPU时间，并核对任务计划程序的执行时段。
- 云主机应检查是否发生实例迁移、宿主维护或突发性能额度耗尽。
6. 监控采样和告警阈值不合理
一分钟平均值可能掩盖10秒级的CPU等待。反过来，单次尖峰也可能只是正常的垃圾回收或连接建立。CPU超售风险排查应至少同时保留短周期和长周期视图，例如5秒至15秒用于定位瞬时抖动，1分钟至5分钟用于判断持续争用。告警最好采用组合条件：steal time或调度等待持续升高，同时业务延迟、运行队列或错误率也发生变化。
如何确认问题来自超售
- 先复现或等待同一业务时段，记录应用延迟、错误率和进程CPU。
- 检查来宾机的steal time、iowait、运行队列及容器throttling。
- 把异常时间与宿主机其他租户、备份任务和发布操作对齐。
- 在可控窗口降低vCPU超额、迁移到资源更充足的主机，或暂时停止竞争任务。
- 对比调整前后至少一个完整业务高峰，再决定长期扩容、重分配或优化代码。
只有当资源争用指标与业务症状在时间上相互印证，并且调整资源后得到改善，才能把问题定性为CPU超售风险，而不是仅凭一个监控数字下结论。
常见问题
CPU使用率低于50%，还会有超售吗？
会。虚拟机可能正在等待物理CPU调度，来宾机看到的使用率不会把等待时间计入有效计算。应同时查看steal time和业务延迟。
增加vCPU能解决CPU超售吗？
不一定。若宿主机本身已争用，增加vCPU可能让虚拟机更难获得整组调度时间；先确认宿主资源和NUMA拓扑，再决定扩容。
CPU超售与CPU限流有什么区别？
超售发生在多个虚拟工作负载争抢物理资源；限流通常由容器或虚拟机配额主动限制。前者要看宿主机竞争，后者要看配额和throttling指标。
什么时候应降低超售比例？
当高峰期持续出现调度等待、延迟超出基线，且迁移或暂停竞争任务后明显改善时，应优先降低超售比例或增加物理容量。CPU超售风险排查的最终目标，是让配置与业务峰值相匹配，而不是追求某个固定比例。
