1. iostat入门你的Linux磁盘性能诊断利器第一次接触iostat是在五年前的一个深夜当时负责的电商网站在大促期间突然响应变慢数据库查询延迟飙升。在排除了CPU和内存问题后我把目光投向了磁盘I/O。iostat就像一位经验丰富的诊断医生通过几行简单的命令就帮我找到了症结所在——RAID阵列中的一块磁盘出现了异常高延迟。iostat是sysstat工具包中的一员猛将专门用于监控系统I/O设备负载情况。与常见的top命令不同iostat提供了更细粒度的磁盘性能数据能够区分不同设备的读写压力。在Ubuntu/Debian系统安装只需一行命令sudo apt update sudo apt install sysstat而在RHEL/CentOS系列则是sudo yum install sysstat安装后最基本的用法是直接输入iostat但这通常只能看到汇总数据。实战中我们更推荐使用扩展模式iostat -x 1 3这里的-x表示显示扩展统计信息数字1表示每秒刷新一次3表示总共输出3次报告。这种动态观察方式比单次快照更能反映真实负载情况。2. 关键指标深度解读从数字到洞察2.1 CPU维度别让I/O拖累整体性能iostat输出的第一部分是CPU利用率统计其中有个指标特别值得关注——%iowait。这个数字表示CPU在等待I/O操作完成时的空闲时间占比。去年处理过一个案例某金融系统的%iowait长期维持在30%以上导致交易处理延迟。通过下面的命令可以专注查看CPU指标iostat -c 1关键阈值参考%user 70%应用层计算密集型%system 30%内核调用过多%iowait 20%可能存在I/O瓶颈%idle 30%系统整体负载较高2.2 设备维度解剖磁盘的每个动作设备指标才是iostat的精华所在。在扩展模式(-x)下每个磁盘设备会输出约20项指标我们可以将其分为四类吞吐量指标rkB/s, wkB/s直观反映磁盘实际读写量r/s, w/sIOPS每秒I/O操作数指标延迟指标r_await, w_await从请求发出到完成的平均耗时aqu-sz等待队列长度相当于堵车程度合并优化指标rrqm/s, wrqm/s内核合并的请求数%rrqm, %wrqm合并请求比例容量指标rareq-sz, wareq-sz每次I/O的平均数据量曾经诊断过一个MongoDB性能问题发现虽然%util只有60%但aqu-sz却高达8r_await超过50ms。这表明磁盘虽然未达理论极限但随机访问特性导致磁头频繁寻道实际性能已经严重下降。3. 实战诊断从指标联动发现真凶3.1 场景一随机读写拖垮SSD某次处理一个Redis服务器响应延迟问题iostat显示Device r/s w/s rkB/s wkB/s aqu-sz await %util nvme0n1 4500 800 18000 3200 6.8 12.3 98这个案例非常典型超高IOPSr/sw/s5300每次I/O数据量很小rkB/s/r/s4KB队列堆积aqu-sz6.8延迟升高await12.3ms解决方案是调整Redis的持久化策略将每秒刷盘改为每10秒刷盘并启用压缩。修改后aqu-sz降至0.5以下。3.2 场景二顺序大文件写入瓶颈处理日志收集服务器时遇到过这样的数据Device r/s w/s rkB/s wkB/s aqu-sz await %util sdb 5 120 20 60000 3.2 25.6 90特征很明显高吞吐wkB/s60000大块写入wareq-sz500KB高利用率但IOPS不高这种情况通常需要检查文件系统块大小是否匹配考虑使用更高效的压缩算法评估是否需要RAID0条带化4. 高级技巧与避坑指南4.1 不要过度依赖%util很多工程师看到%util接近100%就断定磁盘到极限了这其实是个误区。对于现代SSD和RAID阵列由于并行处理能力%util往往不能真实反映负载。更可靠的判断组合是aqu-sz 设备队列深度/2await 1/(IOPS能力)吞吐量接近接口带宽4.2 配合其他工具交叉验证iostat虽然强大但有时需要其他工具佐证# 查看块设备队列深度 cat /sys/block/sda/queue/nr_requests # 观察具体进程IO iotop -oP # 文件系统层面监控 df -h; findmnt -T /path4.3 长期监控与基线建立临时诊断用iostat长期监控建议配置sar# 编辑/etc/default/sysstat ENABLEDtrue # 设置采样间隔秒 SADC_OPTIONS-S XDISK 10这样会每10秒采集一次完整数据保存于/var/log/sysstat/可以用sar -d查看历史数据。记得有次排查一个间歇性故障就是靠历史sar数据发现每天凌晨3点的RAID卡缓存刷新导致了短暂的高延迟。
Linux——iostat 实战：从指标解读到瓶颈定位
1. iostat入门你的Linux磁盘性能诊断利器第一次接触iostat是在五年前的一个深夜当时负责的电商网站在大促期间突然响应变慢数据库查询延迟飙升。在排除了CPU和内存问题后我把目光投向了磁盘I/O。iostat就像一位经验丰富的诊断医生通过几行简单的命令就帮我找到了症结所在——RAID阵列中的一块磁盘出现了异常高延迟。iostat是sysstat工具包中的一员猛将专门用于监控系统I/O设备负载情况。与常见的top命令不同iostat提供了更细粒度的磁盘性能数据能够区分不同设备的读写压力。在Ubuntu/Debian系统安装只需一行命令sudo apt update sudo apt install sysstat而在RHEL/CentOS系列则是sudo yum install sysstat安装后最基本的用法是直接输入iostat但这通常只能看到汇总数据。实战中我们更推荐使用扩展模式iostat -x 1 3这里的-x表示显示扩展统计信息数字1表示每秒刷新一次3表示总共输出3次报告。这种动态观察方式比单次快照更能反映真实负载情况。2. 关键指标深度解读从数字到洞察2.1 CPU维度别让I/O拖累整体性能iostat输出的第一部分是CPU利用率统计其中有个指标特别值得关注——%iowait。这个数字表示CPU在等待I/O操作完成时的空闲时间占比。去年处理过一个案例某金融系统的%iowait长期维持在30%以上导致交易处理延迟。通过下面的命令可以专注查看CPU指标iostat -c 1关键阈值参考%user 70%应用层计算密集型%system 30%内核调用过多%iowait 20%可能存在I/O瓶颈%idle 30%系统整体负载较高2.2 设备维度解剖磁盘的每个动作设备指标才是iostat的精华所在。在扩展模式(-x)下每个磁盘设备会输出约20项指标我们可以将其分为四类吞吐量指标rkB/s, wkB/s直观反映磁盘实际读写量r/s, w/sIOPS每秒I/O操作数指标延迟指标r_await, w_await从请求发出到完成的平均耗时aqu-sz等待队列长度相当于堵车程度合并优化指标rrqm/s, wrqm/s内核合并的请求数%rrqm, %wrqm合并请求比例容量指标rareq-sz, wareq-sz每次I/O的平均数据量曾经诊断过一个MongoDB性能问题发现虽然%util只有60%但aqu-sz却高达8r_await超过50ms。这表明磁盘虽然未达理论极限但随机访问特性导致磁头频繁寻道实际性能已经严重下降。3. 实战诊断从指标联动发现真凶3.1 场景一随机读写拖垮SSD某次处理一个Redis服务器响应延迟问题iostat显示Device r/s w/s rkB/s wkB/s aqu-sz await %util nvme0n1 4500 800 18000 3200 6.8 12.3 98这个案例非常典型超高IOPSr/sw/s5300每次I/O数据量很小rkB/s/r/s4KB队列堆积aqu-sz6.8延迟升高await12.3ms解决方案是调整Redis的持久化策略将每秒刷盘改为每10秒刷盘并启用压缩。修改后aqu-sz降至0.5以下。3.2 场景二顺序大文件写入瓶颈处理日志收集服务器时遇到过这样的数据Device r/s w/s rkB/s wkB/s aqu-sz await %util sdb 5 120 20 60000 3.2 25.6 90特征很明显高吞吐wkB/s60000大块写入wareq-sz500KB高利用率但IOPS不高这种情况通常需要检查文件系统块大小是否匹配考虑使用更高效的压缩算法评估是否需要RAID0条带化4. 高级技巧与避坑指南4.1 不要过度依赖%util很多工程师看到%util接近100%就断定磁盘到极限了这其实是个误区。对于现代SSD和RAID阵列由于并行处理能力%util往往不能真实反映负载。更可靠的判断组合是aqu-sz 设备队列深度/2await 1/(IOPS能力)吞吐量接近接口带宽4.2 配合其他工具交叉验证iostat虽然强大但有时需要其他工具佐证# 查看块设备队列深度 cat /sys/block/sda/queue/nr_requests # 观察具体进程IO iotop -oP # 文件系统层面监控 df -h; findmnt -T /path4.3 长期监控与基线建立临时诊断用iostat长期监控建议配置sar# 编辑/etc/default/sysstat ENABLEDtrue # 设置采样间隔秒 SADC_OPTIONS-S XDISK 10这样会每10秒采集一次完整数据保存于/var/log/sysstat/可以用sar -d查看历史数据。记得有次排查一个间歇性故障就是靠历史sar数据发现每天凌晨3点的RAID卡缓存刷新导致了短暂的高延迟。
