cas虚拟化平台kvm进程在后台的cpu利用率超过100,.200或者800%以上，

这是一个非常经典且容易让人产生错觉的现象。核心原因在于：虚机内部（Guest OS）和宿主机（Host OS）对 CPU 使用率的“100%”定义基准不同。

简单来说，虚机里看到的 200% 是基于虚机自身分配的 vCPU 数量；而宿主机上看到的 100%（如果是通过 top 或 virsh cpu-stats 观察）通常是基于单颗物理 CPU 核心，或者是该虚机进程整体消耗的宿主机单核容量。

以下是具体的拆解原因：

1. 虚机内部的 200% 是怎么来的？

在 Linux 系统中（包括虚机内部的 Guest OS），top 命令对 CPU 使用率的默认计算方式是累加的（Solaris 模式）：

• 100% 代表跑满 1 个 vCPU 核心。

• 如果你的虚拟机分配了 2 个或更多 vCPU，那么理论上总 CPU 使用率最高可以达到 $200\% \times \text{vCPU 数量}$。

• MongoDB 是多线程架构，当它在虚机内同时利用了 2 个 vCPU 核心在全力跑满负载时，虚机内部的 top 就会直观地显示出 200%。

2. 为什么 KVM 宿主机上只看到 100%？

在 KVM 宿主机上观察虚机的 CPU 消耗，通常有两种场景，两者的逻辑有些许不同：

场景 A：你在宿主机直接看 top（查看 qemu-kvm 进程）

如果宿主机的 top 也处于默认的 Irix/Solaris 模式，按理说 2 个核跑满应该也显示 200%。为什么会显示 100% 呢？

• 宿主机 top 切换了模式（Solaris mode toggle）： 如果在宿主机的 top 界面按了大写的 I，它会切换到“单核平均模式”。在这种模式下，无论虚机耗费了多少核，它的总量都会被平均到宿主机的总核心数上，或者最高上限被定义为 100%。

• CPU 资源限制（Cgroups / Quota）： 宿主机上可能对该虚机设置了 vcpu_quota 或 cgroups 限制。例如，虽然虚机内部认为自己有多个 vCPU 并且都在疯狂计算，但宿主机死死地把该虚机的总 CPU 绑定/限制在了相当于宿主机 1 个物理核的绝对计算量（即上限 100%）。此时虚机内部由于分时调度，看到每个 vCPU 都在动，加起来 200%，但实际吐出来的总算力被宿主机卡死在 100%。

场景 B：你使用的是 virsh list 或特定的 KVM 监控工具

有些 KVM 虚拟化管理平台（或者某些定制的 virsh 统计脚本）在定义“虚机 CPU 使用率”时，采用的是整体比例法：

• 它们把“虚机分配的所有 vCPU 整体跑满”定义为 100%。

• 如果你的虚机刚好分配了 2 个 vCPU，且这两个 vCPU 都跑满了，管理后台通过 API 计算出来的比例就是 $\frac{2}{2} = 100\%$。

💡 总结与排查建议

• 验证虚机核心数： 在虚机内执行 nproc 或 lscpu，确认是不是 $\ge 2$ 个 vCPU。如果是，内部显示 200% 完全正常，说明 MongoDB 占满了 2 个核心。

• 检查宿主机限制： 在宿主机执行 virsh vcpupin <vm-name> 或检查 XML 配置中的 <vcpu> 和 <cputune> 标签，看看是否有人为限制或绑定了特定的物理核。

• 调整宿主机 top 视角： 在宿主机看 top 时，可以按下 H 键开启线程模式（Show threads），找到该虚机进程（qemu-kvm）旗下的各个 vCPU 线程，你会发现其实有两个不同的 vCPU 线程各自卡在了宿主机的某个百分比上。