一、为什么要关注主机性能瓶颈

想象一下你开着一辆大巴，车上坐满了乘客（虚拟机）。如果发动机（CPU）不给力，整个车就跑不快；如果油箱（内存）太小，跑一会儿就得趴窝；如果轮胎（存储）漏气，车身就会左摇右晃；如果排气管（网络）堵塞，车里全是废气，乘客憋得慌。ESXi主机就像这辆大巴，它自己不舒服，上面所有虚拟机都会跟着难受。你可能已经遇到过这种场景：在虚拟机里打开一个软件，光标转圈圈转半天；远程桌面动不动就断线；客户打电话说页面打开超级慢。这时候别急着责怪应用层，先低头看看主机是不是“生病”了。接下来咱们就用最平常的话，把CPU、内存、存储、网络这四条线路挨个捋一遍，学会自己当“老司机”排查性能瓶颈。

二、CPU维度诊断

2.1 怎么看CPU是否满了

CPU是主机的大脑，核心数量再多也架不住每个虚拟机都抢。想知道大脑累不累，最常用的工具是ESXi自带的esxtop。你可以用SSH登录主机，敲一下esxtop，它就能实时显示主机状态。但刚进去界面密密麻麻，看不懂没关系，记得几个按键就行。

# 登录ESXi主机后，直接输入esxtop并回车
esxtop

# 进入之后，按小写字母c，切换到CPU专用视图
# 屏幕上会出现很多行，每行代表一个逻辑CPU核心
# 最后一行是所有核心的平均值，主要看%USED列
# 如果这个数字长期超过80%，说明CPU已经忙得不可开交

为了把数据存下来分析，可以使用批处理模式，这样可以在后台采集一段时间，然后再慢慢看。

# 在批处理模式下采样CPU数据，采样3次，每次间隔2秒，输出到文件
esxtop -b -n 3 -d 2 -c > /tmp/cpu_records.txt

# 查看采集到的文件内容
cat /tmp/cpu_records.txt

# 输出的每一行会有很多列，我们只关注末尾的总体均值
# 如果PCPU（物理CPU）的平均%USED很高，说明物理核心负担重

除了看实时数据，还可以用esxcli命令查看物理CPU的型号和核心数，毕竟老旧的CPU就算闲着也跑不过新的。

# 查看这台ESXi主机上物理CPU的型号、主频、核心数等
esxcli hardware cpu list

# 查看CPU的总量信息（比如总核数、超线程状态）
esxcli hardware cpu global get

2.2 优化CPU策略

发现CPU紧张的时候，很多人第一反应就是给虚拟机多加几个vCPU，但这样可能适得其反。因为虚拟机之间抢CPU是有“席位”之分的。我们可以设置CPU份额（Shares），相当于给每个虚拟机分配不同的优先级。比如两个虚拟机都闹着要CPU，份额高的那个能拿到更多的运行时间。还可以设置预留（Reservation），保证重要虚拟机至少有一个核心的算力。

# 查看虚拟机ID列表，先找到你要调整的虚拟机
vim-cmd vmsvc/getallvms

# 假设虚拟机ID是42，查看当前虚拟机的CPU配置
vim-cmd vmsvc/get.summary 42

# 输出中会看到numCpu、cpuShares等字段，这些就是CPU的核心数和份额

修改CPU份额需要谨慎，一般建议在业务低峰期操作。比如把一台非核心虚拟机的CPU份额调低，把重要虚拟机的调高。

# 调整虚拟机42的CPU份额为“高”（可选项有low/normal/high/custom）
vim-cmd vmsvc/set.config 42 cpuShares high

# 如果想把某个虚拟机绑到特定CPU核上（一般不推荐），需要额外设置亲和性
# 这里只是示意，具体参数要谨慎查阅文档

另一个重要的优化点是不要盲目绑定CPU亲和性。很多人以为把虚拟机固定在某些物理核上能提升性能，其实反而会限制调度器灵活复用空闲核心。除非有特别严格的实时业务要求，否则别碰亲和性。

三、内存维度诊断

3.1 内存压力识别

内存就像办公室的工位，工位不够就得有人站着办公。当ESXi主机物理内存不足时，会把一部分不常用的内存数据“搬到”磁盘上，这个过程叫交换（Swap）。磁盘比内存慢几千倍，一旦开始Swap，虚拟机就会像陷入泥潭一样。所以判断内存是否紧张，就看有没有Swap发生。

在esxtop里按m键，可以看到内存视图。

# 在esxtop界面中，按小写字母m切换到内存视图
# 重点关注Swap Used这一项，如果数值大于0，说明已经有内存被挪到磁盘了
# 另外看%COMMITTED，这个值接近100%说明物理内存几乎全部被承诺给了虚拟机

也可以用esxcli查看物理内存总量和当前使用情况。

# 查看ESXi硬件的物理内存容量
esxcli hardware memory get

# 查看主机的内存使用概况（包括物理内存和预留内存）
esxcli memory get
# 输出里会有“Physical Memory Utilized”和“Physical Memory Reserved”等字段

3.2 内存优化

如果发现内存压力大，第一件事不是去买内存，而是看看哪些虚拟机在“占着茅坑不拉屎”。有的虚拟机分配了16GB内存，实际只用2GB，这种就应该限制一下。可以给虚拟机设置内存份额和预留，保证核心业务有足够的内存。

# 查看所有虚拟机的内存大小和内存份额
vim-cmd vmsvc/getallvms | awk '{print $1}' | tail -n +2 | while read vm_id; do
    echo "VM ID: $vm_id"
    vim-cmd vmsvc/get.summary $vm_id | grep -E "name|memory"
done

内存优化的核心思路是：该省的省，该保的保。那些跑着静态网页的虚拟机，给4GB内存就够了，何必分它8GB？把多出来的内存拿给数据库虚拟机，主机整体压力自然就降下来了。当然，如果所有虚拟机都真的在忙，那还是老老实实加内存条吧。

四、存储维度诊断

4.1 存储延迟与队列

存储就是虚拟机使用的“硬盘”，它可以是本地机械盘、SSD，也可以是外接的SAN存储。存储慢是整个系统慢的常见原因，因为它直接决定了虚拟机读取和写入数据的速度。判断存储性能有两个关键数字：延迟和队列深度。延迟是发一个读写命令后要等多久，队列深度是同时排队等处理的命令数。

在esxtop中按d键，可以看到存储视图。

# 在esxtop中按小写字母d切换到磁盘视图
# 重点看DAVG列（设备平均延迟，单位毫秒）
# 还看QAVG列（平均队列深度）
# 对SSD来说，DAVG超过5毫秒就要警惕；机械盘可以放宽到20毫秒，但再高就说明很挤
# QAVG如果超过1，说明请求已经排起长队，明显堵车了

除了esxtop，用esxcli也能查看存储设备的健康状态。

# 列出主机上所有存储设备，以及它们是不是SSD
esxcli storage core device list

# 查看某个存储设备的统计信息（根据前面list得到设备名，比如naa.xxxx）
esxcli storage core device stats get -d naa.xxxx

4.2 存储优化

存储优化首选是升级硬件，比如把机械盘换成SSD。但很多时候我们只能在软件层面做调整。先检查是不是有虚拟机积累了太多快照，快照会把读写操作拖得很慢，特别是长时间不合并的快照。另外，给不同的虚拟机配置不同的“磁盘份额”，让重要的虚拟机多占用I/O通道。这个份额可以在虚拟机配置里设置。

# 查看存储路径选择策略（RoundRobin是轮询，适合多路径SAN）
esxcli storage nmp path list

# 如果某个存储设备拖慢了整体，可以考虑把虚拟机迁移到别的数据存储
# 可以使用vmkfstools工具复制虚拟磁盘，但这要停机，不推荐
# 最好在vCenter里用Storage vMotion在线迁移，这里不展开

存储优化还有一个容易忽略的点：存储控制器上的设备队列深度。太浅了，并发请求上不去；太深了，反而导致某些请求超时。一般保持默认就好，除非厂家有特别建议。

五、网络维度诊断

5.1 网络丢包与流量

网络就像快递通道，包裹（数据包）如果堵在一个口子上，后面的大货车（应用程序）就进不来。判断网络是否拥挤，最直接的信号就是丢包。丢包意味着数据没有送达，应用就会重传，重传又加重网络负担，恶性循环。

在esxtop中按n键，可以看到网络视图。

# 在esxtop中按小写字母n切换到网络视图
# 关注PKTTX（每秒发送包数）和PKTRX（每秒接收包数）
# 更重要的是%DRPTX和%DRPRX，分别对应发送和接收丢包率
# 只要这两个数不是0，就说明网络这里有“堵车”

用esxcli也能看到物理网卡上的累计丢包数。

# 列出所有物理网卡名称
esxcli network nic list

# 统计每张网卡上的收发包数量和丢包数量
esxcli network nic stats get

# 假设输出中vmnic0的DropRx为30，说明这个网卡收到了30个包却找不到地方放，丢掉了

5.2 网络优化

网络出现问题，先检查物理层：网线是不是松了，交换机端口是不是变成了半双工，光纤模块是不是损坏。然后再看虚拟交换机配置。如果多个虚拟机都挤在同一块物理网卡上，可以增加一块物理网卡，并在虚拟交换机上配置负载均衡策略。另外，巨型帧也能提升大流量传输效率，但必须确保从虚拟机网卡、虚拟交换机、物理交换机到目标服务器都支持，否则会适得其反。

# 查看物理网卡当前的速率和双工模式
esxcli network nic get -n vmnic0

# 查看虚拟交换机的上行链路配置
esxcli network vswitch standard list

# 如果发现vmnic0的流量太高，但系统还有其他空闲网卡，可以给vSwitch添加新的物理网卡
# 这个操作最好在vSphere Web Client里做，命令行比较复杂，这里不推荐新手直接执行

网络优化还有一个思路：限制某些非关键虚拟机的带宽。通过虚拟机网络流量整形，把带宽留给核心业务，避免“一颗老鼠屎坏了一锅粥”。

六、综合示例：一次完整的排查流程

咱们来模拟一个真实场景：公司所有虚拟机都变得很卡，鼠标都飘，点按钮半天没反应。我们作为管理员，要像侦探一样按顺序排查。

第一步，SSH登录ESXi主机，先抓取一段时间的数据。

# 后台启动CPU和内存数据采集，各采样10次，间隔5秒
esxtop -b -n 10 -d 5 -c > /tmp/cpu_perf.txt &
esxtop -b -n 10 -d 5 -m > /tmp/mem_perf.txt &

# 用wait等待两个后台命令都完成
wait

# 同时用esxcli获取存储延迟和网络丢包数据
esxcli storage core device stats get > /tmp/storage_perf.txt
esxcli network nic stats get > /tmp/nic_perf.txt

# 现在/tmp下面已经保存了四类数据，接下来逐个分析

第二步，分析CPU数据。

# 查看CPU平均数，把最后一行“Total”那一行拿回来
grep -E "Total" /tmp/cpu_perf.txt | tail -1

# 如果%USED平均值低于40%，那CPU不是元凶

第三步，分析内存数据。

# 查看内存视图里Swap Used的变化
grep -E "Swap" /tmp/mem_perf.txt | tail -20

# 如果看到Swap Used一直在增长，说明内存有压力

第四步，分析存储数据。

# 读取存储统计文件，关注Latency列
cat /tmp/storage_perf.txt

# 如果某个设备读延迟超过20毫秒，或者写延迟超过10毫秒，存储就是重点怀疑对象

第五步，分析网络数据。

# 查看网卡丢包计数
cat /tmp/nic_perf.txt

# 如果DropRx或DropTx都是0，说明网络没有丢包，先排除网络

假设通过上面几步，我们发现CPU不高，网络没丢包，但内存的Swap Used很高，存储延迟也跟着升高。这时候基本可以断定：内存不足导致了Swap，而Swap把内存“换页”操作都压到了存储头上，最终让存储也变得很慢。解决方法就是给主机增加内存，或者把部分虚拟机迁移走，或者关闭一些空闲的虚拟机。这个例子就告诉我们，有时候你看到存储慢，其实根子不一定在存储，可能是在内存。

七、应用场景与优缺点

上面这套排查方法几乎适用于所有使用vSphere的运维场景。不管是虚拟机突然变慢，还是整台主机响应迟钝，甚至是新的应用上线前做容量评估，都可以用同样的思路。日常巡检时可以定时采集esxtop数据，形成主机的“体检报告”。故障发生时又能快速定位短板，做到心里有数。

这个方法的优点很明显：不需要额外安装第三方监控软件，全是ESXi自带的命令和工具；覆盖了CPU、内存、存储、网络四个最核心的方面；而且命令简单，适合不同基础的系统管理员。缺点也有：esxtop的输出对新手来说像天书，刚开始看到那么多列可能会懵；另外，实时快照只能反映当下，看不到一段时间的趋势，最好配合vCenter的全局监控或者性能图表，才能更全面地了解变化规律。

八、注意事项

排查性能瓶颈时，有一些坑千万要避开。不要看到某个指标高就立刻动手改配置，先想清楚业务高峰时段是不是就在这里。不要在业务高峰期做重大配置变更，比如调整虚拟机份额、迁移虚拟机、重启主机，这些操作很可能会让性能问题雪上加霜。另外，做任何修改前都要确认你有足够的权限并且已经理解了恢复方案。对于使用共享存储的环境，还要检查是不是有很多虚拟机在同时跑备份任务，这种“突然的外部压力”也会让存储和CPU飙升。最后，别忘了给ESXi主机本身留一点CPU和内存资源，别让管理服务因为资源耗尽而失联。

九、总结

排查ESXi主机性能瓶颈，其实就是一个不断缩小怀疑范围的过程。CPU、内存、存储、网络这四个维度，可以视为一台主机的体温、血压、呼吸和脉搏。我们用esxtop看实时数据，用esxcli查询硬件细节，用vim-cmd微调虚拟机配置。遇到故障时，按“先CPU、再内存、后存储、最后网络”的顺序逐一排查，能避免很多手忙脚乱。平时多记录一些空闲时期的基线值，等真正出问题时才能有对照。记住，性能优化不是一次性工作，而是持续观察、分析和调整的循环。希望你看完这篇博客后，下次遇到主机卡顿，能从容地打开命令行，一步步找到问题所在，然后微微一笑，把系统调回飞驰的轨道。