核心是定位“谁在抢”和“抢什么”，表现为虚拟机响应慢、CPU/内存使用率偏高、I/O延迟突增；关键看%RDY（持续>10%即调度瓶颈）、ballooning（vmmemctl运行/Memsz增长）和DAVG/cmd（>20ms）等瞬时竞争指标。
排查虚拟化环境中的资源争抢，核心是定位“谁在抢”和“抢什么”——通常表现为虚拟机响应变慢、CPU或内存使用率持续偏高、I/O延迟突增，但宿主机整体负载未必超标。关键不在总用量，而在资源分配策略与瞬时竞争。
看CPU调度是否出现就绪队列堆积
宿主机的vCPU调度瓶颈常被忽略。即使平均CPU使用率不高，也可能因vCPU数量配置过多（如1:1超分）、或频繁抢占导致就绪时间（%rdy）升高。
- 在vSphere中检查每台VM的%RDY指标：持续 >10% 表明vCPU等待调度时间过长；>20% 属严重争抢
- 对比CPU Ready Time与CPU Usage趋势图：若使用率中等但就绪时间飙升，说明不是算力不足，而是调度排队
- 临时验证：将高就绪VM的vCPU数减半（需关机调整），观察%rdy是否回落；若改善明显，说明过度分配vCPU是主因
查内存是否触发 ballooning 或 swapping
内存争抢不只看“已用百分比”，更要看宿主机是否启动了内存回收机制——这会显著拖慢VM性能，且往往静默发生。
- 检查ESXi主机的Mem.Active（活跃内存）与Mem.Consumed（已分配）差异：若Consumed远大于Active，说明有大量内存被分配但未活跃使用，易被balloon驱动回收
- 确认vmmemctl进程是否运行、以及Memsz值是否增长：这是ballooning启动的明确信号
- 警惕Mem.Swapped非零：一旦发生swap，I/O延迟陡增，应立即降低内存超分比例或关闭内存共享（如Transparent Page Sharing）
盯住存储I/O路径是否存在队列深度饱和
同一存储LUN上多个VM并发随机读写时，争抢常发生在底层队列而非带宽本身，尤其在全闪存阵列上更易暴露延迟问题。
- 关注DAVG/cmd（单次I/O平均延迟）和KAVG/cmd（Kernel层排队延迟）：前者>20ms、后者>5ms即需警惕
- 对比同一数据存储下各VM的AVG Latency：若某VMIO量不大但延迟极高，可能是被其他VM的突发IO阻塞
- 检查存储多路径策略是否均衡：如所有VM都走同一路径（如Fixed模式未轮询），会导致单链路拥塞，改用MRU或Round Robin可缓解
识别网络层面的隐性争抢
分布式交换机或vSwitch上的流量整形、端口组QoS、甚至物理网卡中断绑定不当，都可能造成VM间网络资源不公平分配。
- 查看每台VM的Net.ReadPktRate与Net.WritePktRate是否接近vNIC限速阈值（如设定为1Gbps但实际跑满）
- 检查宿主机物理网卡的txqueuelen是否长期溢出（Linux宿主机可用
ip -s link查drop计数），表明驱动或队列深度配置不合理 - 确认是否启用了Network I/O Control (NIOC)并设置了份额/限制：若未启用，高吞吐VM可能挤占低优先级业务带宽
