在Linux系统中查看IOPS（每秒输入输出操作数）最常用且直观的方法是结合使用iostat命令监控实时性能，或通过/sys/block/<设备>/stat文件读取内核层面的累计统计值，对于需要精细排查磁盘瓶颈的场景，建议配合iotop工具定位具体进程。
IOPS是衡量存储系统性能的核心指标之一，它直接反映了磁盘在单位时间内能够处理多少读写请求，对于数据库管理员、系统运维工程师以及云计算架构师而言，准确掌握磁盘I/O能力是保障业务稳定运行的关键，许多人在面对服务器卡顿或响应延迟时，往往首先怀疑网络或CPU，却忽略了存储子系统这一“隐形瓶颈”，本文将深入解析如何在Linux环境下高效获取IOPS数据,并解读这些数据背后的业务含义。
实时性能监控：iostat命令的深度应用
iostat是sysstat软件包中的核心组件，它不仅能显示CPU的使用情况，更是分析磁盘I/O性能的利器，对于大多数Linux发行版，如CentOS、Ubuntu或RedHat,安装sysstat后即可直接使用。
基础用法与关键指标解读
在终端中输入iostat -x 1可以每秒刷新一次磁盘的详细统计信息，这里的-x参数代表扩展模式，它会输出比默认模式更丰富的数据,你需要重点关注以下几个字段：
- rrqm/s 和 wrqm/s：分别表示每秒合并读请求和写请求的数量，如果这两个数值较高，说明内核正在有效地合并相邻的I/O请求,这是良好的现象。
- r/s 和 w/s：代表每秒实际发出的读和写I/O操作次数,这就是我们常说的IOPS。
- await：这是平均每次I/O操作的等待时间（毫秒），它包含了排队时间和实际服务时间，如果
await值显著高于svctm（服务时间），说明磁盘队列中存在大量等待，系统可能面临I/O瓶颈。 - %util
：磁盘利用率，当该值接近100%时，表明磁盘已经满载，无法处理更多请求,此时性能会急剧下降。
业内专家指出，单纯看IOPS数值往往具有误导性，必须结合await和%util综合判断，一个SSD可能拥有极高的IOPS，但如果await值飙升，说明其内部队列深度过大或控制器已饱和,实际用户体验依然糟糕。
区分不同存储介质的性能基线
不同介质的磁盘，其IOPS表现差异巨大，在分析数据时,你需要心中有底：
- 机械硬盘（HDD）：由于物理寻道时间的限制，单块HDD的随机读写IOPS通常在50-200之间，如果是RAID阵列,需根据条带化策略和磁盘数量进行估算。
- SATA SSD：相比HDD有数量级的提升，随机读写IOPS通常在3,000-10,000左右。
- NVMe SSD：利用PCIe通道，绕过了SATA接口的瓶颈，IOPS可达100,000甚至更高。
据行业共识认为，在评估云主机性能时，不能仅看标称的IOPS上限，更要关注突发性能（Burst）和持久性能的区别，许多云服务商允许短时间内的IOPS突发,但长期运行需维持在基线水平。
精准定位瓶颈：iotop与blktrace实战
当iostat告诉你磁盘很忙，但不知道是哪个进程在“搞鬼”时,就需要引入更细粒度的工具。
使用iotop查看进程级I/O
iotop类似于top命令，但它专门用于监控磁盘I/O，安装后运行iotop -o，只显示产生I/O的进程，你可以清晰地看到哪个MySQL线程、哪个Nginx worker进程正在疯狂读写磁盘，这对于排查“磁盘IO高”的问题至关重要。
操作路径与注意事项
- 确保已安装
iotop：yum install iotop或apt-get install iotop。 - 使用
sudo iotop -oP以进程模式运行，并按I/O排序。 -
注意：
iotop需要root权限才能准确显示所有进程的I/O统计。
深入内核层：blktrace的高级分析
对于极端性能调优场景，blktrace可以提供块设备层面的详细追踪，虽然学习曲线较陡，但它能揭示请求在队列中的具体等待时间、调度算法的影响等深层信息，通常配合blkparse和blkprint使用，生成可视化的I/O时间线图。
静态数据查询：/sys/block接口
在某些受限环境或脚本自动化场景中，你可能无法安装额外的监控工具，Linux内核提供的/sys文件系统是最好的选择。
读取累计IOPS统计
进入/sys/block/<设备名>/stat目录，例如/sys/block/sda/stat，该文件包含一行以空格分隔的数字,分别代表：
- 读操作完成次数
- 读扇区数
- 读合并次数
- 读等待时间
- 写操作完成次数
- 写扇区数
- 写合并次数
- 写等待时间
- 活跃操作数
- 活跃操作等待时间
- 操作时间
通过编写简单的Shell脚本，定期读取这些值并计算差值，即可得到实时的IOPS和吞吐量，这种方法轻量级且无需额外依赖,适合嵌入式设备或资源极度受限的容器环境。
对比不同监控工具的适用场景
| 工具 | 适用场景 | 优点 | 缺点 |
|---|---|---|---|
| iostat | 全局性能概览 | 系统自带，信息全面 | 无法定位具体进程 |
| iotop | 进程级瓶颈排查 | 直观显示进程I/O | 需要root权限，开销略大 |
| blktrace | 内核级深度调试 | 数据极其详尽 | 配置复杂，分析难度大 |
| /sys/block | 脚本自动化/轻量监控 | 无依赖，轻量 | 需自行计算差值，无实时图表 |
常见问题解答：linux iops 查看
如何查看Linux服务器当前的总IOPS？
可以通过组合iostat命令快速估算，运行iostat -x 1 1，查看输出结果中的r/s（读IOPS）和w/s（写IOPS）之和，需要注意的是，r/s和w/s统计的是I/O请求次数，而非字节数，如果需要进行长期监控，建议部署Prometheus配合node_exporter，其node_disk_reads_completed_total和node_disk_writes_completed_total指标可以通过PromQL查询得到精确的每秒速率。
iops高但吞吐量低，说明什么问题？
这种情况通常意味着系统正在处理大量的随机小文件读写，每个I/O请求的数据量很小，导致磁盘控制器频繁处理请求元数据，而实际数据传输效率不高，常见于数据库索引更新、日志记录或小型对象存储场景，优化方向包括增加内存缓存、使用SSD替代HDD，或调整应用层的批量写入策略,将小请求合并为大请求。
云服务器上的IOPS数据可信吗？
云服务商提供的IOPS监控数据通常基于宿主机层面聚合，可能存在一定的延迟或精度损失，对于关键业务，建议在操作系统内部使用fio等工具进行基准测试，以获得更贴近应用层真实体验的数据，注意区分“突发IOPS”和“基线IOPS”,避免在突发期结束后因性能回落而导致业务抖动。
首发原创文章，作者：世雄 - 原生数据库架构专家，如若转载，请注明出处：https://idctop.com/article/484590.html
