虚拟机建集群频繁卡顿，根源多半不在宿主机性能不够，而是资源分配策略、存储I/O调度和网络虚拟化叠加造成的长尾延迟，找准瓶颈按层优化，普通服务器也能跑出接近物理机的集群体验。 下面按照排查优先级拆解优化路径，每一条都是可以落地操作的具体动作。
虚拟集群性能优化有哪些技巧
先别急着加CPU，给虚机做“减法”比做“加法”更有效
卡顿出现时,多数人的第一反应是给虚拟机加配置，结果越加越卡，业内专家指出，虚拟机的CPU调度天然存在协同开销你分配8颗vCPU给一个负载不高但线程频繁切换的应用，反而会导致物理核被反复抢占和同步等待。
- 单虚机vCPU建议控制在物理总核数的一半以内，高并发场景下这个值还要进一步收敛
- 使用
virsh vcpuinfo <虚拟机名>查看vCPU实际绑定情况，确认是否有排队等待 - 开启CPU Pinning（CPU亲和性），让每个vCPU固定在特定物理核上运行，避免缓存抖动
- 生产环境的集群节点,关闭CPU超线程共享，避免两个虚机抢同一颗物理核的执行单元
实操建议：先压测再分配，用
fio和unixbench分别测试计算和I/O基线，根据基线数据决定创建集群时给多少CPU，而不是按物理机规格“拍脑袋”分配。
内存过载是虚拟机集群卡顿的第二大陷阱，但别误伤Overcommit
虚拟化平台为了提升资源利用率,默认开启内存Overcommit（超量分配），逻辑上没问题，真正伤害性能的是慌乱中的盲目关闭。内存优化技巧的核心是让宿主机内存不触发Swap，而不是追求总分配量小于物理总量。
- 检查宿主机的
ksm/zswap策略：KSM（页合并）在数据库类集群上建议关闭，它会消耗CPU去扫描重复内存页 - 在虚拟机XML配置中加入
<memoryBacking><hugepages/></memoryBacking>，开启HugePages后TLB命中率提升明显 - 关闭NUMA自动均衡（
numad），手动把虚机的内存和vCPU绑定到同一NUMA节点，避免跨节点访问
集群卡顿还常见于JVM类应用（比如大数据集群的NodeManager），Virtualization和GC的交互会让内存占用瞬时飙升，建议预留
宿主机20%-30%的空闲内存给页缓存和避让突发流量。
虚拟机集群卡顿怎么解决
存储瓶颈才是卡顿的第一元凶，盘阵划分有讲究
处理卡顿第一步不是看CPU和内存,而是看宿主机磁盘I/O，集群里的虚机同时刷盘，块设备的请求队列快速膨胀，卡顿即刻浮现，行业共识认为，虚拟化集群的I/O瓶颈概率高于计算瓶颈80%以上（基于常见故障排查统计）。
分层存放规则：
| 数据类型 | 存放位置 | 理由 |
|---|---|---|
| 系统盘 | SSD或NVMe | 读写频繁，延迟敏感 |
| 大数据节点数据盘 | 机械盘但做RAID10 | 顺序读写为主，追求容量和吞吐 |
| 日志盘 | 独立虚拟磁盘 | 隔离随机写对核心IO的冲击 |
| 虚拟机内存交换文件 | 禁止放机械盘 | 直接拖垮所有业务 |
关键操作：
- 为每台虚拟机添加独立的I/O权重（
iops_limit和iops_burst），防止单台虚机刷盘耗死整个存储 - 底层虚拟磁盘格式优先选择RAW或预分配Qcow2，不要用稀疏文件（thin provisioning），虽然省空间，但首次写入会造成磁盘扩展卡顿
- 使用
virtio-blk而不是ide或SATA作为总线类型，在数据密集型场景下IOPS差距能达到数倍 - 宿主机的存储调度器建议改为
deadline或none，别用CFQ，它会按优先级排队，加重集群内部各节点的不公平竞争
网络虚拟化优化：跨节点通讯延迟是集群卡顿的隐形杀手
对于集群（如K8s、OpenStack、PBS）节点间的心跳和数据复制都走虚拟网络，默认的NAT或OVS网桥会带来额外封装开销，导致延迟积累。
- 改用MacVTap或SR-IOV直通，让虚机直接使用物理网卡，绕过虚拟交换机的排队处理
- 修改虚拟机网卡队列,设置
<driver name='vhost' queues='4'/>，让多队列中断分散到不同vCPU处理，提升多核网络收包效率 - 如果你的集群频率同步走NTP协议且延迟平均超过10ms,那么先处理网络，不要优化应用了
宿主机内核参数优化，做一轮只要10分钟
| 参数 | 修改值 | 作用 |
|---|---|---|
vm.swappiness |
10 |
降低磁盘Swap使用概率 |
vm.dirty_ratio |
10 |
控制脏页占比，防止刷盘风暴 |
vm.dirty_background_ratio |
5 |
后台提前刷盘，避免瞬时阻塞 |
net.core.netdev_max_backlog |
20000 |
应对集群大量小包并发 |
kernel.sched_min_granularity_ns |
10000000 |
优化宿主机多任务调度 |
临时生效命令：sysctl -w vm.swappiness=10，永久生效则写入/etc/sysctl.conf，sysctl -p重新加载。
超售比例与集群规模的平衡：合理设定QoS参数
资源超售不是万能药。每个宿主机承载的虚拟机数量应控制在物理线程数的2倍以内，如果每台虚拟机使用4颗vCPU，物理服务器有32线程，那么最多承载16台虚机，超过这个比例，卡顿会以非线性的方式恶化。
同时配置QoS分组：
- 高优先级节点（如控制节点、SQL节点）：显式设置
cpu_shares=2048，memory=硬限制 - 低优先级节点（如计算节点）：
cpu_shares=512，内存使用软限制，允许调度突破
不同集群类型下的针对性优化
对数据库集群（Galera、MySQL主从）的特殊建议
- 关闭HugePages转储和KSM合并,页表锁定减少延迟波动
- 使用PCIe直通SSD给数据盘,彻底去掉文件系统的二次缓存
- 数据库虚拟机的磁盘
io_uring非轮询模式关闭，避免内核态轮询占用CPU
对大数据集群（Hadoop/Spark）的特殊建议
- 每台虚机至少分配8GB起的内存和4颗vCPU，堆内内存给虚机总内存的一半其余留给OS页缓存和Java堆外内存
- 网卡务必多队列,
ethtool -L eth0 combined 8
- 存储不推荐把DataNode目录挂载在共享存储上,本机直通盘更稳定
对桌面虚拟化/开发测试集群的建议
这类集群卡顿主要发生在集中开机和杀毒扫描时段,可以设置宿主机层级的iops_burst和CPU限额，把同时发起的虚拟机启动数量控制在每宿主机5台以内，更有效的做法是制作基础镜像快照，批量部署时关闭所有非必要自启动服务。
Q&A：虚拟机集群卡顿怎么办
问：集群里的虚机总是“假死”几分钟后恢复，是什么问题？
多半是存储阻塞所致,检查宿主机的iostat -x 1，观察svctm和%util是否持续偏高，如果%util接近100%且await超过100ms，就能确认是磁盘排队过深，解决方案是把该虚机的磁盘镜像迁移到更高性能存储池，同时给虚机增加I/O权重限制，避免夜间备份任务和业务高峰叠加抢盘。
问：虚拟机集群卡顿和超售有关系吗？怎么判断当前超售比例是否合理？
有直接关系,查看宿主机物理CPU核数和vCPU总数，以及物理内存和虚机分配内存总数，可以计算出超售比值，如果CPU超售超过2倍，或者内存超售超过物理内存后在free -g中看到swap被大量占用，那么不卡才怪，合理做法是保CPU不过度超售，内存可以额外超售但总分配量必须低于物理内存的70%，剩余量留给宿主机页缓存。
问：为什么有朋友换了全闪存储之后集群仍然卡顿？
换存储解决的是I/O延迟问题，如果卡顿原因是CPU调度等待（vCPU饥饿）或网络丢包重传，那么换闪存毫无帮助，需要先确认卡顿时的监控指标：如果宿主机top长时间wa高，优先处理存储；如果sy高且perf占用大量时间，需要处理CPU调度和超售；如果虚机内ping网关有丢包，最小化网络虚拟化层级。
最后还是要强调一个容易被忽略的结论：虚拟集群性能优化的本质是管理资源争抢，而不是把每个虚机都调成物理机。 合理分配、按场景做QoS、保持监控基线数据，你的集群卡顿就能肉眼可见地缓解，性能自然稳定下来。
首发原创文章，作者：王坚，如若转载，请注明出处：https://idctop.com/article/728126.html
