在虚拟机里查看IOPS，最准确的方式不是只看系统自带任务管理器，而是必须结合虚拟化平台（如VMware ESXi或KVM）的底层性能计数器，并辅以专业的压测工具（如fio测磁盘IOPS）进行验证，因为虚拟机的IOPS不仅受虚拟磁盘和Guest OS驱动影响，更受宿主机存储栈的调度限制。
如果你只是想知道当前虚拟机的磁盘负载是否快满了,那直接在系统里看性能计数器是最快的；但你要搞清楚"我这台云主机磁盘IOPS性能为啥总是跑不满"，就得一层层往下查，直到宿主机物理磁盘那层为止。
Windows虚拟机磁盘IOPS性能查看方法
Windows系统在Guest OS里自带的性能监视器，是判断"虚拟机看到的IOPS高不高"的第一道利器。
任务管理器里的"性能"页签
打开任务管理器,切到"性能"页签，选中磁盘，你会看到下面的列表：
- 活动时间：当前磁盘处理的繁忙百分比，这玩意越高说明磁盘越忙
- 平均响应时间：每次I/O请求从发出到返回的平均耗时，单位是毫秒，这个值如果长期飙到几十毫秒以上，说明存储有瓶颈
- 读取/写入速度：单位是MB/s，注意这只是吞吐量，不是IOPS
- 磁盘队列长度：这个数值比较隐蔽，默认不显示，需要右键图表区域手动勾选
坦白说,任务管理器适合看个大概，不推荐用作准确的IOPS量化标准因为它看不到虚拟机磁盘具体的IOPS次数（每秒读写次数），而且它展示的指标容易让人误以为"速度慢=带宽不够"，其实很多时候是延迟太大。
性能监视器：掏出系统自带IOPS计数器
真正要在Windows里看IOPS数值,要用性能监视器（perfmon）这个工具。
操作流程是：
- 按Win+R，输入
perfmon.msc并回车 - 在左侧导航栏找到"性能监视器"节点
- 在右侧图表区域右键,选择"添加计数器"
- 在可用计数器列表里,展开"PhysicalDisk"或"LogicalDisk"
- 关键计数器有这四组：
| 计数器名 | 含义 | 怎么用 |
|---|---|---|
| Disk Reads/sec | 每秒读次数 | 计数值就是读IOPS |
| Disk Writes/sec | 每秒写次数 | 计数值就是写IOPS |
| Disk Read Bytes/sec | 每秒读字节数 | 除以区块大小就是读IOPS |
| Disk Write Bytes/sec | 每秒写字节数 | 除以区块大小就是写IOPS |
比较实用的操作技巧：把 Disk Reads/sec 和 Disk Writes/sec 两个计数器加起来，得到的就是这台Windows虚拟机在Guest OS层面看到的实际IOPS，如果磁盘区块大小是4KB，而你看的是Bytes/sec，那直接除以4096，就能算出IOPS。
不过你需要明白一个行业共识：Windows系统里看到的IOPS，是虚拟磁盘控制器（比如PVSCSI或LSI Logic SAS）提交给虚拟化层之后的表现结果，它不包含宿主机存储层的排队等待和缓存命中情况，所以说这个数值对"当前虚拟机是否卡顿"有参考意义，但对"宿主机的IOPS性能上限"没有任何说服力。
Linux虚拟机磁盘IOPS性能检测工具对比
Linux环境下查看IOPS的手段更丰富,既有被动监测的经典命令，也有主动压测的专业磁盘IOPS测试工具。
iostat：老牌命令实时输出读写次数
iostat属于sysstat工具包的一部分,安装方式在CentOS系是yum install sysstat，在Ubuntu系是apt install sysstat。
直接跑一下iostat -x 1 3，输出结果里重点看这几列：
r/s（read per second）：每秒读次数，这就是读IOPSw/s（write per second）：每秒写次数，这就是写IOPSrkB/s和wkB/s：每秒读写的吞吐量，单位是KBawait：平均每次I/O的等待时间（毫秒），这个数字如果高于20，用户的直观感受就是操作卡%util：设备繁忙度百分比
补充一个大家常踩的坑：iostat -x里面的%util，很多刚入门的朋友把它当成"磁盘用了百分之多少"，其实它表示的是设备带宽利用率即使%util到了100%，也不代表IOPS已经到顶，只能说明在这一秒内的采样周期里总有不间断的I/O在排队。
fio压测工具：主动打满磁盘测IOPS上限
被动监测工具看的是现状,想要测试磁盘的极限IOPS性能，就得靠fio这类主动压测工具，这也是在选型云主机或物理服务器时，考察磁盘IOPS性能最常用的手段。
一段典型的看裸设备随机读IOPS的命令：
fio -filename=/dev/sdb -direct=1 -iodepth 32 -thread -rw=randread \ -ioengine=libaio -bs=4k -size=2G -numjobs=1 -runtime=30 \ -group_reporting -name=random_read_test
这串参数逐项拆解一下：
-filename=/dev/sdb：测试的目标设备，压测前必须确认这个设备里的数据可以清空，选错了可能把系统盘干掉-direct=1：绕过Page Cache直接走块设备层，这样测的是真实硬件性能，而不是内存缓存的速度-iodepth 32：队列深度，模拟有32个I/O在同时排队-rw=randread：随机读，想测随机写就改成randwrite-bs=4k：单次I/O的数据块大小是4KB，这是OLTP数据库这类场景最常见的块大小-runtime=30：测试持续30秒
fio跑完后,重点关注输出里的IOPS字段和lat (usec)延迟分布，比如这么两行：
read: IOPS=5870, BW=23MiB/s这表示随机读IOPS是5870左右lat (usec): min=112, max=10342, avg=324.57平均延迟324微秒
另一个比较实用的测试是混合读写场景,用-rw=rw -rwmixread=70来模拟70%读、30%写的情况，这更贴近数据库这种真实业务负载。
虚拟化平台层IOPS监控与物理磁盘瓶颈确认
在虚拟机内部无论怎么查,看到的IOPS都只是Guest OS视角，虚拟机IOPS性能如果达不到预期，问题很可能出在虚拟化层。
VMware ESXi环境用esxtop看真实IOPS
如果你用的是VMware虚拟化平台,直接在Guest OS里测IOPS，那看到的数值可能虚高，原因在于VMware的虚拟SCSI控制器和宿主机缓存会做I/O合并，想看准确IOPS，SSH登录到ESXi宿主机，敲esxtop，然后按u键切到磁盘设备视图，按d键切到磁盘设备模式。
重点关注这几个字段：
%USED：存储设备的利用率百分比CMDS/s：每秒钟下发给物理存储的命令数，这才是这个物理设备实际处理的IOPSMBREAD/s和MBWRITE/s：每秒读写吞吐量DAVG/cmd：命令在存储设备上的平均排队时间，这个如果超过50ms，那存储阵列基本属于超负荷状态
业界专家指出，绝大多数"虚拟机磁盘IOPS上不去"的原因，是宿主机上多台虚拟机争抢物理磁盘的排队配额，而不是虚拟磁盘本身配置有误，你可以在esxtop里按V键查看每台虚拟机的IOPS消耗情况，哪个VM是存储大户一目了然。
KVM平台用libvirt和块设备统计
KVM虚拟化环境下,可用virsh domstats命令直接向libvirt查询虚拟机的磁盘IO统计：
virsh domstats --block <虚拟机名称>
返回里的这几个参数对应关系如下：
block.0.rd.reqs：累计读请求次数block.0.wr.reqs：累计写请求次数block.0.rd.bytes和block.0.wr.bytes：累计读写字节数
用两次采样的差值除以时间间隔,计算出来的就是该虚拟机平均每秒的IOPS，因为是底层hypervisor直接读取的virtio-blk或virtio-scsi驱动力数据，这个结果的准确度比Guest OS内部看要更可信。
物理磁盘IOPS性能基准的行业参考值
分析采集到的数据时,心里要有物理设备的性能基准线，以下是行业共识的估算量级，具体数值需结合实际硬件和RAID配置来判断：
| 存储类型 | 随机读IOPS估算范围 | 典型延迟范围 |
|---|---|---|
| 机械硬盘（SATA 7200转） | 80~180 | 8~15ms |
| 机械硬盘（SAS 10000转） | 120~230 | 5~10ms |
| 企业级SATA SSD | 15000~40000 | 2~1ms |
| NVMe SSD | 200000以上 | 02~0.2ms |
如果测出来的虚拟机IOPS远低于上表对应存储类型的量级,且虚拟机的CPU和内存没有瓶颈，那就要重点检查宿主机存储链路配置，包括RAID卡的缓存策略、存储网络（SAN/NAS）的带宽，以及是否存在"噪声邻居"抢占存储资源。
最后回到最开始的核心观点：虚拟机里查到的IOPS只是现象，用fio这类压测工具配合虚拟化平台（如VMware的esxtop或KVM的virsh domstats）逐层排查，才能定位到真正影响磁盘IOPS性能的根因。 学会在Windows性能监视器和Linux的iostat命令之间灵活切换，你就能快速判断到底是虚拟机配置的问题，还是物理存储能力的天花板。
IOPS性能分析的常见误区
- 只关注IOPS数值，不关注延迟，同一块SSD在队列深度1时的IOPS可能只有3000，队列深度32时飙到30000，但延迟也从0.2ms涨到2ms，业务真正感知的是延迟变化，不是IOPS数字高低。
- 忽略数据块大小对IOPS的影响，同样的磁盘，用4KB块大小测能到5000 IOPS，换1MB块大小可能只有200 IOPS，比较IOPS必须明确块大小和读写模型（顺序/随机）。
- 以为虚拟化平台看到的IOPS和Guest OS看到的应该一致，虚拟化层会有I/O合并、缓存预读等机制，导致两者可能相差较大，部分场景下虚机内部看到的IOPS甚至高于宿主机物理磁盘的实际IOPS，这显然是因为数据落到了宿主机缓存层，还没真正写穿到底层磁盘。
Q&A模块
为什么Windows虚拟机的磁盘IOPS性能比物理机差一大截？
这是正常现象,虚拟机的I/O路径比物理机多走了好几层：Guest OS驱动 -> 虚拟化层调度 -> 宿主机存储协议栈 -> 物理磁盘，每一层都会引入额外的CPU开销和排队延迟，据行业统计数据，典型虚拟化环境下的IOPS损耗在10%到30%之间，具体取决于虚拟化平台、驱动类型（virtio或准虚拟化驱动通常比模拟设备损耗更小）以及宿主机负载情况，如果差距超过50%，应从存储缓存策略或磁盘队列深度设置两方面排查。
用fio测试云主机磁盘IOPS性能时，参数怎么选才贴近真实业务？
没有通用的标准参数组合,贴合业务场景最关键，如果是数据库场景，建议用-rw=randrw -rwmixread=70 -bs=8k -iodepth=16模拟OLTP随机读写混合负载，如果是大数据日志采集场景，顺序写才是重点，用-rw=write -bs=128k -iodepth=32，在公有云的环境里测试，有个需要留意的细节：云计算厂商通常会对单盘IOPS设有配额上限，比如简米云和酷番云的ESSD系列都有明确的IOPS规格说明，如果你的测试结果稳定在配额上限附近，那就说明云盘性能已经打满了，别怀疑是宿主机不稳定。
虚拟机磁盘IOPS性能瓶颈在宿主机还是虚拟机本身？
逐层排除法最有效率,先在虚拟机内用fio跑一轮，记录IOPS和延迟；再在宿主机上用底层工具（VMware用esxtop，KVM用iostat）测物理磁盘的IOPS，如果宿主机物理磁盘的IOPS接近其规格上限，说明瓶颈在物理存储层，这时候调整虚拟机队列深度或更换更高规格的存储设备是唯一出路；如果宿主机磁盘还有大量余量，但虚拟机内IOPS就是上不去，优先检查虚拟机的虚拟SCSI控制器类型是否过旧、是否开启写缓存，以及vCPU的调度是否为存储I/O中断预留了足够算力。