简介《虚拟化实施遇到问题的解决方案》面向虚拟化项目实施人员、运维工程师及刚接触平台搭建的技术人员聚焦VMware与Citrix两类虚拟化环境在落地过程中出现的故障与常见疑难提供可参考的处理思路和解决记录。内容源于作者个人实施经历兼顾问题现象、排查方向与应对方法适合在部署、调试和日常维护阶段对照查阅帮助读者减少重复试错。压缩包为zip格式整体约15.45MB上游未提供文件总数与类型明细故不展开具体文件构成。该资源已有502人浏览学习说明其对虚拟化实施场景具有一定参考价值。读者可从中获取VMware、Citrix虚拟化常见问题的解决经验理解实施环节的排错路径并据此整理自己的故障处理清单提升现场问题定位与处置效率。1. 虚拟化上线首周常见问题三台宿主机上的四十个业务「虚拟化」在方案书里只是架构图上的一个分层落到实施现场却完全不是一回事。我见过一个模拟项目 X四十多台业务机从物理机搬进虚拟化池白天一切正常晚上备份窗口一到监控全红虚拟机没宕、业务没挂就是慢得没法用。跑得起来和跑得好中间隔着一整套资源分配、指标和演练。这份资源讲的不是某个平台的安装向导而是虚拟化实施过程中真正会卡住人的那批问题超分怎么定、内存回收开不开、迁移为什么失败、快照为什么不回滚、慢到底慢在哪一层。适合正在做或即将做虚拟化改造的运维、实施和架构同学也适合已经上线、但总觉得「有点慢又说不出哪慢」的团队。下面按我踩过的顺序一条条拆。2. 先把资源分配算清vCPU 超分、内存回收与存储链路的三个定量问题虚拟化实施里最容易被含糊带过的就是「资源够不够」。方案评审时写一句「CPU 超分比 1:3、内存不超分」实施时没人核上线后就开始互相指责。这三个数字必须在上线前落在纸面上vCPU 分配总量与物理核的比例、内存回收机制开哪几个、存储后端能扛多少 IOPS。它们不是独立的三件事CPU 超分定得太激进虚拟机抢 CPU 时就绪时间上升业务感知到的就是「卡顿」内存不设预留气球驱动一回收客户机内部就开始换页存储链路没压过前面两项调得再漂亮一个备份窗口照样打回原形。下面按这三个维度分别给出可落地的算法和验证命令。2.1 vCPU 超分比从 1:1 到 1:4 之间怎么算出应用比例超分比的分母一定要用物理核数不是逻辑 CPU 数。开了超线程的机器nproc返回的是线程数拿线程数当分母算出来的比例天生偏乐观实际每核要承担两倍的压力。常见做法是交易类、数据库类业务 1:1 到 1:2通用 Web、中间件 1:2 到 1:4桌面虚拟化或测试环境可以到 1:6 甚至 1:8。但这些数字只是起点真正的判据是 CPU 就绪时间ready time / steal time——虚拟机想跑但物理核被别人占着排队等待的时间占比一旦长期超过 5%业务侧就开始有可感知的抖动。先把账面数字统计出来用下面这段脚本在每台宿主机上跑一遍#!/bin/bash # 统计当前宿主机所有虚拟机的 vCPU 分配总量用于计算真实超分比 total_vcpu0 for dom in $(virsh list --name); do [ -z $dom ] continue vcpu$(virsh dominfo $dom | awk /CPU\(s\)/ {print $2}) total_vcpu$((total_vcpu vcpu)) printf %-30s %s\n $dom $vcpu done # 物理核数 每路核数 × 路数注意不含超线程 pcores$(lscpu | awk -F: /Core\(s\) per socket/ {gsub(/ /,,$2); c$2} /Socket\(s\)/ {gsub(/ /,,$2); s$2} END {print c*s}) lcores$(nproc) echo ---------------------------------------- echo vCPU 分配总量: $total_vcpu echo 物理核数: $pcores 逻辑 CPU 数: $lcores awk -v v$total_vcpu -v p$pcores BEGIN{printf 按物理核超分比: %.2f:1\n, v/p} awk -v v$total_vcpu -v p$lcores BEGIN{printf 按逻辑核超分比: %.2f:1\n, v/p}逻辑说明virsh dominfo输出里的CPU(s)字段就是这台虚拟机配置的 vCPU 数遍历所有域累加得到分配总量lscpu里Core(s) per socket乘Socket(s)得到物理核数这个值才是分母。参数上唯一要改的是虚拟机名前缀过滤——生产环境里往往混着模板机和测试机建议在循环里加一层case判断只统计纳管业务。拿到账面比例后还要看实际使用率。这两件事经常背道而驰比例 1:2 但实际平均利用率只有 8%说明资源是浪费的比例 1:1.5 但峰值利用率 90%说明再搬一台机器进来就会翻车。下表是我在项目里用的对照参照注意最后一列才是决定是否继续扩容的依据。业务类型建议超分比峰值利用率参考就绪时间告警线数据库 / 交易核心1:1 ~ 1:2不高于 60%2%通用应用 / 中间件1:2 ~ 1:4不高于 75%5%文件、打印、测试环境1:4 ~ 1:6不高于 85%10%桌面 / 池化办公1:6 ~ 1:8不高于 85%10%注意超分比是结果不是目标。先按业务重要级别定就绪时间阈值再倒推能超分到多少而不是先定一个 1:4 的漂亮数字再往里塞机器。2.2 内存回收气球驱动、页合并与预留内存的取舍内存这块最常见的误解是「虚拟机里free看着还有富余宿主机就该够用」。实际上虚拟化层有三种机制在中间来回操作每一种都有代价气球驱动balloon是宿主机向客户机「借」内存的通道靠客户机内的驱动配合。它的前提是驱动装了、服务起来了否则宿主机以为能回收客户机一点没让出来两边账对不上。同页合并KSM把多台虚拟机里内容相同的物理页合并成一份对同模板克隆出来的机器效果明显代价是持续扫描消耗 CPU且与静态大页互斥。预留内存reservation是反方向操作锁定一部分内存不给回收适合数据库这类对内存延迟敏感的虚拟机。机制作用方向主要代价什么时候必须开气球驱动宿主机回收客户机空闲内存客户机内部可能触发换页超分比高于 1:1 且业务空闲内存多同页合并合并重复物理页持续 CPU 扫描开销大量同模板克隆的桌面/测试机内存预留锁定内存不被回收降低整体可调度内存数据库、缓存类核心业务静态大页减少 TLB miss需预分配不能动态调整大内存、低延迟业务验证气球和页合并是否真的在生效别只看管理平台的开关状态# 宿主机侧页合并是否开启已合并多少页页数 × 4KB 约为节省内存 cat /sys/kernel/mm/ksm/run # 1 开启0 关闭 grep -E pages_shared|pages_sharing|pages_unshared /sys/kernel/mm/ksm/* # 虚拟机侧查看内存上限、当前分配与实际使用单位 KiB virsh dominfo app01 | grep -E Max memory|Used memory virsh dommemstat app01 # 关注 actual / available / unused / rss逻辑说明dommemstat输出里的actual是当前真正分给这台虚拟机的内存available是客户机报告的可回收量两者差值接近零就说明气球已经压到头了再压只能靠客户机自己换页。参数上要留意单位是 KiB写监控脚本时别按字节算否则阈值会差三个数量级。我一般的做法是核心业务一律加预留预留量取近 30 天内存峰值的 1.1 倍非核心业务开气球但不设强制下限让它自然回收页合并只在克隆密度高的池子里开开了之后盯两天宿主机 CPU 的 sys 占比涨超过 3 个百分点就关掉。2.3 存储链路本地盘、共享块存储与分布式存储的边界存储是虚拟化实施里唯一一项「事后补不回来」的资源。虚机、网络、CPU 都能在线调存储的 IOPS 和时延是物理决定的容量买够了不等于性能够用。一条虚拟磁盘的 IO 路径是客户机文件系统 → 虚拟磁盘格式qcow2 / raw→ 宿主机缓存策略 → 后端存储。每一层都能成为瓶颈而绝大多数「虚拟化之后数据库变慢」的案例问题都出在第二层和第三层。先明确边界本地 SSD 时延最低但不支持在线迁移和跨主机高可用共享块存储支持迁移代价是多一层网络和控制器分布式存储扩展性好但随机小 IO 的时延通常是本地盘的 3 到 10 倍写放大还会额外消耗带宽。把核心数据库放在分布式存储上然后抱怨「虚拟化性能不行」是最常见的误判。虚拟磁盘创建时有两个参数值得在实施阶段就定死预分配策略和簇大小。精简置备省空间但首次写入时要分配块表现为「新机器前几天特别慢」元数据预分配能缓解这个问题几乎不占额外空间。# 创建 200G 虚拟磁盘元数据预分配簇大小 64K适合随机 IO 为主的业务 qemu-img create -f qcow2 \ -o preallocationmetadata,cluster_size64k \ /var/lib/libvirt/images/app01.qcow2 200G # 对后端存储做一次真实压测4K 随机读队列深度 324 并发持续 60 秒 fio --namerandread --filename/dev/mapper/vg_data-lv_vm --direct1 \ --rwrandread --bs4k --iodepth32 --numjobs4 \ --time_based --runtime60 --group_reporting逻辑说明preallocationmetadata只预分配元数据创建快、后续写入不产生额外的元数据膨胀cluster_size64k适合随机小 IO顺序大 IO 为主的业务备份盘、日志盘用默认 64K 或调大反而更省。fio这行里--direct1绕过系统页缓存测的才是真实后端--iodepth32模拟虚拟化层多个虚机并发的情况队列深度设在 1 测出来的数字好看但没有参考价值。压测结果对照下表判断能不能承接业务达不到就不要靠调超分比去「优化」后端类型4K 随机读时延p99适用场景不建议承载本地 NVMe 0.5 ms核心数据库、高 IO 中间件需要在线迁移的业务共享块存储FC/iSCSI1 ~ 3 ms通用业务、需要高可用的场景极高 IOPS 的写入密集业务分布式存储3 ~ 10 ms容量优先、弹性扩展低时延交易类NFS / 文件级共享5 ms 以上镜像库、备份、归档数据库数据文件3. 性能瓶颈定位CPU 就绪时间、内存争抢与 IO 等待的排查路径性能问题是虚拟化实施里最难交差的一类业务方说慢平台方看监控一切正常最后往往以「再观察观察」收场。原因很简单——两边看的不是同一层指标。虚拟化环境有三层观测点宿主机、虚拟机内部、业务应用自身。定不到层后面所有调优都是猜测。这一章给一条固定的排查顺序先在业务侧锁定时间点和现象类型再去宿主机同一时间窗看资源竞争最后进虚拟机内部看是不是客户机自己的问题。顺序不能反反了就容易在错误的层上做无效优化。3.1 三层指标对齐把「慢」拆成可观测的量业务侧的「慢」至少有三种形态对应的根因完全不同响应时间整体抬高通常是 CPU 争抢或存储时延上升、周期性卡顿通常是内存回收或备份任务、少量请求超时通常是网络丢包或队列打满。所以第一步不是登宿主机而是问清楚什么时间、持续多久、是所有请求还是部分请求、有没有伴随错误率上升。这四个问题的答案基本能把范围缩小一半。拿到时间窗后按下面的顺序取数# 第一层宿主机整体 CPU重点看 %steal 与 %sys mpstat -P ALL 1 30 # 第二层按进程看qemu-kvm 进程的 CPU 占用是否异常以及是否频繁上下文切换 pidstat -u -w -p ALL 1 30 | grep -E qemu|UID # 第三层虚拟机内部看 stolen time 与运行队列在客户机里执行 vmstat 1 30 # 关注 st 列与 r 列逻辑说明mpstat里的%steal是虚拟 CPU 等待物理 CPU 的时间占比这个值在宿主机上看不出来必须在客户机内或者通过 hypervisor 的就绪时间指标获取pidstat -w的cswch/s如果某台虚机的 qemu 进程远高于同级别机器通常意味着客户机内部有自旋锁竞争或者 vCPU 数量配多了。参数上1 30表示每秒采样一次共 30 次取数窗口要覆盖业务反馈的故障时段事后补采没有意义。对齐的关键是时间戳统一。我踩过的坑是宿主机用 UTC、业务侧日志用本地时间差了 8 小时对着「同一时间窗」查了半天什么也没查到。实施阶段就应该把宿主机、虚拟机、监控系统三处时区全部对齐这一步花五分钟能省掉后面几天。3.2 CPU 就绪时间与亲和性把抖动压下去确认是 CPU 侧竞争之后先分清两种情形。一种是总量不够——超分比过高或业务峰值叠加表现为所有虚机的就绪时间一起上涨这种只能扩容或者把业务迁走调参数没用。另一种是分布不均——总量够但某些 vCPU 老是落在被系统进程和其他虚机争抢的物理核上表现为个别虚机抖动、其他正常这种可以通过绑核和 NUMA 亲和解决。绑核之前先确认 NUMA 拓扑跨节点的内存访问延迟能高出 40% 以上vCPU 绑在同一节点、内存也落在同一节点才有意义# 查看 NUMA 节点与各节点上的 CPU 编号 numactl --hardware # 查看虚拟机当前 vCPU 落在哪些物理 CPU 上 virsh vcpuinfo app01 # 把 4 个 vCPU 绑定到同一 NUMA 节点内的物理核 8-11 virsh vcpupin app01 0 8 virsh vcpupin app01 1 9 virsh vcpupin app01 2 10 virsh vcpupin app01 3 11 # 检查宿主机调频策略节能模式会引入频率切换带来的抖动 cpupower frequency-info | grep -E current policy|governor逻辑说明vcpupin的第一个参数是虚拟机名第二个是 vCPU 序号从 0 开始第三个是物理 CPU 编号一个 vCPU 只能绑一个核才能做到严格隔离。参数上要避开 0 号核——很多系统中断和处理内核线程都在 0 号上绑过去等于给自己找麻烦。governor建议设为 performance代价是功耗上升但在虚拟化宿主机上这个代价换来的稳定性是值得的。严格绑核的副作用是牺牲了调度弹性绑死的核在虚机空闲时不能被别人用整体利用率会下降。所以只对核心业务做严格绑核普通业务保持共享用 CPU 份额shares做软性优先级就够了。3.3 内存争抢与 swap从现象到检查链内存争抢的表现比 CPU 更不直观。典型现象是宿主机内存使用率看着 90% 出头不算离谱虚拟机里free也显示有缓存可回收但业务就是间歇性卡顿几秒。这种「玄学卡顿」九成和内存回收有关——气球反复伸缩、客户机在 swap 里进进出出、页合并扫描占用 CPU任何一个都会造成短时抖动。证据链要按「宿主机是否在换页 → 哪台虚机在换 → 换页是否与卡顿时间吻合」三步走# 宿主机层面pswpin/pswpout 持续增长说明物理内存确实不够不是虚机自己的问题 grep -E pswpin|pswpout|pgmajfault /proc/vmstat # 单台虚拟机swap_in / swap_out 是否在增长单位 KiB virsh dommemstat app01 | grep -E swap_in|swap_out|major_fault # 宿主机内存水位与可用量 grep -E MemAvailable|SwapTotal|SwapFree|Dirty /proc/meminfo逻辑说明/proc/vmstat里的计数是累计值必须隔一段时间取两次做差才有意义单次读数的绝对值没有参考价值。dommemstat的major_fault增长快说明客户机在频繁地从磁盘换入内存页这种现象在虚机上被放大了——因为它要经过两层页表。参数上建议把采样间隔设为 10 秒连续采 5 分钟与业务侧记录的卡顿时间点做叠加对比两个曲线对得上才算定位成功。处理方式分三档轻度争抢就调整气球下限别让它压到业务的工作集以下中度争抢给核心业务加内存预留把压力转移给非核心业务重度争抢只能加内存或迁走业务任何参数调优都救不了物理内存不足。4. 网络不通、迁移失败、快照回滚不了三类高频故障的复现与处置这三类问题有个共同点报错信息都很含糊。网络不通只告诉你「目标不可达」迁移失败只说「操作超时」快照回滚失败更干脆直接给一个内部错误码。含糊的报错意味着必须靠分层验证去逼近根因而不是靠搜索错误码。下面每一类都给一条固定的验证路径按顺序走走到哪一步断了就是哪一层的问题。4.1 虚拟交换机与 VLAN不通、丢包、环路三种表现网络故障先分清楚是哪一种因为处置方式完全不同。完全不通通常是 VLAN 或者端口组配错能通但丢包通常是 MTU 不一致或者安全策略拦截时通时断、广播风暴通常是环路或者 MAC 地址冲突。分清之后再动手比一上来就抓包高效得多。最常见的配置错误是上游物理交换机的 Trunk 允许列表没放开对应的 VLAN ID虚拟化平台这边端口组配得再对包到物理口上也被丢掉。这类问题在宿主机上就能验证给虚拟交换机配一个同 VLAN 的临时接口看能不能拿到地址。MTU 问题更隐蔽。VXLAN 封装会在外层多加 50 字节如果物理口是 1500 而虚机也是 1500大包全部被丢表现为「小包通、大包不通SSH 能连但传文件卡死」# 在虚拟机内部验证路径 MTU1472 28 1500 ping -M do -s 1472 10.0.0.1 # VXLAN 场景下虚机侧建议 8950对应物理口 9000 ping -M do -s 8950 10.0.0.1 # 宿主机侧确认物理口、网桥、vnet 接口的 MTU 是否一致 ip link show | grep -E mtu|vnet bridge link show逻辑说明-M do强制不分片-s指定数据部分长度加上 28 字节的 IPICMP 头正好是探测的 MTU 值。逐级递减探测1472 → 1450 → 1400能快速找到路径上的真实 MTU。参数上注意 ICMP 可能被防火墙拦如果一直不通但业务正常换tcpdump抓包看是否真有分片重组的痕迹。注意虚拟交换机上如果开了 MAC 防伪造、混杂模式限制等安全策略集群心跳、负载均衡的 VRRP 报文都可能被拦掉表现为「网络通但主备切换不成功」这类问题查配置比抓包快。4.2 在线迁移失败五个检查点按顺序过迁移失败的原因五花八门但检查顺序是固定的按这个顺序走绝大多数问题三步之内能定位顺序检查点典型现象处置1目标机资源预留提示内存不足、CPU 不兼容预留至少等于源机已用内存关闭目标机超分挤占2CPU 特性兼容迁移到老旧机型直接失败集群内统一 CPU 基线主机掩码屏蔽新指令集3迁移网络进度卡在 10% 以下或超时独立迁移网络检查带宽与 MTU4存储可见性提示磁盘不可访问共享存储路径、多路径、LUN 掩码一致性5直通设备提示设备不支持迁移PCI 直通、vGPU、USB 映射的虚机只能关机迁移第三点最容易被忽略。迁移是把内存页通过网络复制到目标机同时跟踪脏页如果迁移网络和业务网络共用一条千兆链路热迁移一个大内存虚机基本没有成功的可能——脏页产生速度超过传输速度永远追不上。给迁移单独划一个网络并显式限制带宽避免迁移把业务网络打满# 走独立迁移网络带宽限制 800 MB/s保持持久化配置 virsh migrate --live --verbose --persistent \ --migrateuri tcp://10.0.20.11 \ --bandwidth 800 \ app01 qemussh://10.0.20.11/system逻辑说明--migrateuri指定迁移数据走哪个地址这是把迁移流量和业务流量分开的关键--bandwidth单位是 MB/s取值建议是迁移网络物理带宽的 70%留出余量给心跳和监控--persistent保证迁移完成后目标机上的配置落盘否则重启就丢了。参数上还有一个容易漏的大内存虚机建议先确认能否开启后拷贝post-copy但这会带来源机挂起后不可回滚的风险生产环境我一般不主动开。4.3 快照链与磁盘格式回滚失败的真实原因快照回滚失败几乎只有两个原因链断了或者格式根本不支持。qcow2 的快照是基于写时复制COW的链式结构每打一次快照就多一层读操作要逐层回溯快照层数越多 IO 越慢一旦某一层的 backing file 被移动、重命名或者被其他工具改过整条链就失效回滚时直接报错。更隐蔽的是「有快照时做了扩容或迁移」。给带快照的磁盘扩容老快照记录的还是原来的虚拟大小回滚时尺寸对不上直接失败。用备份工具直接读基础镜像做备份拿到的是快照创建那一刻的旧数据恢复出来的业务数据是错的——这个坑我在模拟项目 X 里遇到过等到恢复演练才发现代价是整个备份策略重做。# 查看快照链的深度与每层实际占用 qemu-img info --backing-chain /var/lib/libvirt/images/app01.qcow2 # 列出快照确认是否存在多余层级 virsh snapshot-list app01 # 把活动层合并回基础层并翻转合并期间 IO 会短暂停顿必须放维护窗口 virsh blockcommit app01 vda --active --pivot --verbose逻辑说明--backing-chain会把整条链逐层打出来如果某一层显示backing file: (null)但又不是最底层说明链已经断了。blockcommit --active --pivot是把当前活动层的数据合并到底层并切换过去合并过程中虚拟机保持运行但 IO 有停顿务必放在维护窗口执行。参数vda是磁盘目标名多磁盘虚机要逐块处理一次性对整机操作容易触发超时。实施阶段就应该定死一条规矩快照只用于变更前的短期保护存活时间不超过 72 小时超过就合并掉长期备份走独立备份链路不依赖快照链。这条规矩能省掉后面 80% 的存储空间告警和回滚失败。5. 避坑清单五个现场常见问题按现象、原因、处置拆开前面四章讲的是方法这一章讲记录。下面五条都是我在实施现场真实遇到过的每一条都按「现象 → 原因 → 处置」写清楚可以直接拿去当上线检查项用。分成两类前三条是配置层的当场能改后两条是流程层的改起来慢但影响更大。5.1 配置层三个当场能改但极易遗漏的坑坑一模板克隆后主机名、IP、MAC 三件套冲突。现象克隆出来的几台机器网络时通时断监控上丢包率忽高忽低看日志有 IP 冲突告警。原因模板机制作时没做通用化处理克隆继承了同一份网络配置和机器标识虚拟化层虽然会给新网卡分配新 MAC但客户机内部还留着旧的静态配置。处置模板首次启动必须走一遍初始化cloud-init或系统自带的通用化工具自动生成主机名和机器 ID静态 IP 改由地址池分配或者 DHCP 保留克隆完成后在虚拟化层核对一遍 MAC 唯一性。坑二磁盘缓存策略为了性能调到回写模式宿主机断电丢数据。现象日常跑分很好看一次机房供电切换之后几台虚机的数据库出现页损坏恢复出来数据不一致。原因缓存策略选了回写数据先落在宿主机的内存缓存里客户机以为写成功了实际没落盘。处置有掉电保护的阵列缓存可以继续用回写没有保护的一律改成直写或者不缓存代价是 IOPS 下降 20% 到 40%这个代价必须让业务方在上线前知情。核心库所在的存储我一般直接设成不缓存性能靠后端 SSD 补。坑三时间同步配置成多源头虚拟机时钟越走越偏。现象日志时间戳错乱集群节点之间心跳间歇性超时排查时发现几台虚机的系统时间差了几十秒。原因客户机同时配了宿主机同步和外部时间源两边都在拉加上虚机暂停恢复后时钟没校正。处置虚拟机内部只向一个内部时间源同步关掉与宿主机同步的选项宿主机自身向同一时间源同步对时间敏感的业务证书校验、分布式锁单独加时钟漂移监控阈值设 500 毫秒。5.2 流程层两个不会立刻报错但会拖垮项目的习惯坑四只监控容量使用率不监控精简置备的分配比。现象存储显示还有 20% 空闲某天突然所有虚机写入失败平台告警「数据存储空间不足」。原因精简置备的磁盘是按需分配的账面分配的容量远大于物理容量使用率指标看的是物理已用看不到「已承诺但未分配」的缺口。处置同时监控两个数——物理使用率和置备比已分配容量 / 物理容量置备比超过 1.5 就要预警给数据存储设 80% 硬阈值到线就禁止新建虚机别等 95% 再处理那个阶段连迁移都做不了。坑五变更前打快照但从不演练回滚。现象一次平台升级出问题按预案回滚发现快照回滚失败业务停了四个小时。原因快照打了几十个链深得离谱中间还有一次磁盘扩容回滚路径早就不可用了。处置变更前的快照数量控制在两层以内变更完成后 24 小时内合并每季度做一次回滚演练随机挑一台非核心业务实打实回滚一次验证从快照到业务启动的完整链路。演练这件事做过一次和没做过出事时的处置速度差一个数量级。6. 验收前的压测与基线把「感觉还行」换成一组数字虚拟化项目最容易糊弄过去的环节就是验收。虚机都起来了、业务都能访问、监控都有曲线就算交付了。等到三个月后业务量上来才发现当初根本不知道这套环境的极限在哪。我现在的做法是上线前必须跑完四项压测出一张基线表把「感觉还行」换成具体数字后面所有扩容和调优都以这张表为依据。6.1 四项必做的压测与通过标准压测项方法通过标准常见不通过原因CPU 混合负载满载跑 30 分钟混合计算型与 IO 型就绪时间 5%业务 RT 抬升 20%超分比过高、未做绑核存储随机 IO4K 随机读写队列深度 32多虚机并发p99 时延 基线 1.5 倍后端缓存不足、未预分配东西向网络跨宿主机虚机间打流逐步加压无丢包带宽达链路 80%MTU 不一致、上行收敛比不足迁移演练带业务负载热迁移再迁回业务中断 1 秒迁移耗时可预期迁移网络与业务网络共用第四项最容易被跳过但它是最值钱的一项。迁移能不能成功、要多久、业务有没有感知只有真跑一次才知道。压测时要在业务侧同时记录响应时间光看迁移任务成功不够——迁移成功但业务抖了 8 秒对小额交易类系统来说已经算事故。6.2 基线表与三个必须设置的告警压测跑完把结果固化成基线表同步配进监控。三个告警是我认为必须有的CPU 就绪时间、内存气球回收频率、存储 p99 时延。前两个反映资源竞争第三个反映后端瓶颈三个都正常的情况下业务再慢基本就是应用自己的问题可以把责任边界划清楚。指标采集位置基线取值告警线CPU 就绪时间宿主机 / 客户机 stolen压测峰值的一半超过 5% 持续 5 分钟内存气球回收宿主机 dommemstat压测期间回收次数单机每小时 10 次存储 p99 时延后端存储 / 宿主机压测 p99 值超过基线 1.5 倍网络丢包虚拟交换机端口0任意非零持续 1 分钟基线不是一次性的。业务扩容、平台升级、存储扩容之后都要重跑一遍把新基线覆盖旧的。我见过太多环境基线表还是两年前首版上线的数字监控阈值一直没动告警天天响最后所有人都学会了忽略告警——这比没有监控更危险。从那以后我每次交付虚拟化项目都会在验收前强制走一遍迁移演练和快照回滚两项都过才签字基线表打印出来贴在机房扩容前先对照看一眼。这两个习惯没有技术含量但救过我三次。希望帮到你。本文还有配套的精品资源点击获取