宿主机资源超售，CPU内存网络负载监控，防止客户互相抢占

宿主机资源超售，简单说就是一台物理服务器上跑的虚拟机数量太多，CPU、内存或网络带宽的总需求超过了宿主机实际能提供的量。
超售严重时，某个客户的高负载业务会拖垮整台宿主机，导致其他客户网站卡顿、数据库超时甚至宕机。
本文从零基础运维视角出发，教你在 Linux 宿主机上通过 CPU、内存和网络负载监控确认超售情况，并用配额手段限制单台客户机的资源占用，避免互相抢占。

先确认宿主机整体负载状态

登录宿主机后，第一件事是看整体资源是否已经吃紧。
建议先执行 uptime 查看系统负载平均值：

uptime

重点关注 load average 后面的三个数字。
如果这三个值长期超过 CPU 逻辑核心数，说明宿主机已经严重超售。
比如一台 16 核的机器，负载均值超过 16 就代表任务排队明显。

接着查看 CPU 和内存的实时占用：

top

按大写 P 按 CPU 使用率排序，按大写 M 按内存排序。
观察是否有单个虚拟机进程（通常是 qemu-kvm 或 vcpu 线程）持续占满多核。
如果好几个客户机进程都长期在 80% 以上，基本可以判定超售导致互相抢占。

再看内存整体使用：

free -h

注意看 available 剩余量是否足够，如果宿主机物理内存只剩几百 MB，还开了大量 swap，说明内存超售风险很高。

定位是谁在抢占 CPU 和内存

只看宿主机的整体负载还不够，要找出具体是哪台客户机在抢占资源。

先列出宿主机上的虚拟化进程和对应客户机名称。
以 KVM 为例：

ps -eo pid,comm,args | grep qemu | grep -v grep

输出里会带 -name guest=客户机名 这类参数，记下是哪个客户机的进程。
然后针对这个进程查看它的线程级 CPU 占用：

top -p 12345 -H

其中 12345 换成实际的 qemu 进程 PID。
如果客户机内部的业务是多线程，你会发现多个 vCPU 线程轮流飙升，说明这台虚拟机把宿主机的 CPU 核心吃满了。

内存占用方面，查看 qemu 进程的 RES 实际占用：

ps -o pid,rss,comm -p 12345

单位是 KB，除以 1024 就是 MB。
如果确认某台客户机长期占用大块内存，就可以针对它做限制。

使用网络负载监控捕捉流量突发

很多“互相抢占”不只在 CPU 和内存上，还发生在网络带宽上。
某台客户机如果被打流量或跑 P2P，会瞬间占满宿主机的物理网卡，其他客户机的响应速度就会变得很差。

常用工具 iftop 可以实时查看宿主机网卡流量来源：

yum install -y iftop   # CentOS/RHEL
apt install -y iftop   # Debian/Ubuntu
iftop -i eth0

打开界面后，能看到每个连接到宿主机的外部 IP 流量大小。
先按大写 T 切换显示总流量，再按 S 和 D 切换源地址和目的地址。
如果发现某个 IP 的流量持续占用 100Mbps 以上，再用以下命令定位它的 MAC 地址或虚拟网卡：

ip neigh | grep 

得到 MAC 后，通过虚拟化平台的管理命令找到对应虚拟机。
比如 virsh 环境下：

virsh list
virsh domiflist <虚拟机名称>

对照网卡 MAC 地址即可确认是哪台客户机在跑大流量。

配置配额防止客户互相抢占

找到问题源头后，你需要做两层限制：宿主机层面的资源配额和虚拟机层面的带宽限速。

CPU 配额设置： 在 KVM 虚拟机 XML 配置中，给每个客户机设置 和 配额。
例如限制某客户机最多使用 4 个核且整体份额不超过 50%：

  512
  100000
  50000

修改后重启虚拟机生效。shares 决定竞争时的权重，quota=50000 表示每 100000 微秒周期内最多使用 50000 微秒，即最多占一半 CPU。

内存限制： 如果不想给客户机无限使用宿主机内存，在 XML 中调整 和 的值，单位为 KB。
例如限制为 4GB：

4194304
4194304

网络带宽限制： 使用 tc 命令可以对虚拟网卡做限速。
比如限制 vnet0 的下载速度为 50Mbps：

tc qdisc add dev vnet0 root tbf rate 50mbit burst 10kbit latency 50ms

注意 tc 配置重启后会丢失，建议写成开机脚本或使用 libvirt 的 配置。
更稳妥的方法是在虚拟机 XML 的 节点中加入：

这里的数值单位是 KB/s，即 50Mbps 约等于 50000 KB/s。

避坑经验与验证方法

在做资源限制时，有几个容易踩坑的点值得留意。

• 不要把 shares 设成绝对限制，它只是权重，宿主机空闲时客户机仍可能突破该权重使用更多 CPU。如果需要绝对上限，必须用 quota。
• 修改内存大小要保证客户机系统能识别，Windows 虚拟机缩内存前最好先关电源再调整，否则容易蓝屏。
• 用 tc 限速后记得检查虚拟网卡名称，宿主机重启后 vnet 编号可能变化，最好使用 libvirt 的带宽配置而不是手工 tc。

配置完成后，建议在业务高峰期再次执行 top、free -h 和 iftop，观察宿主机负载是否明显下降，同时登录客户机测试网站或接口的响应速度。
如果仍然卡，可以逐步降低配额数值，直到所有客户机都能稳定运行。

如果还想确认限制是否生效，可以在宿主机上用下面的命令实时查看某台客户机的 CPU 占用：

ps -o pid,pcpu,pmem,cmd -p $(pgrep -f 'guest=客户机名' | head -1)

正常情况下，加了配额后的客户机 CPU 占用不会再无限接近宿主机总核数，而是稳定在你设定的阈值附近。

宿主机资源超售不可能完全消失，但通过持续监控和合理配额，完全可以把“客户互相抢占”控制在可接受范围内。
先从负载检查开始，再定位热点虚拟机，最后落实限制策略，这套流程在任何虚拟化平台上的思路都通用。
如果条件允许，建议在宿主机上部署 Prometheus + node_exporter 做长期指标留存，方便事后回溯是哪台客户机引发的问题。