1. 从一次线上告警说起为什么磁盘IO如此关键那天下午监控系统突然告警提示某台核心业务服务器的响应时间飙升。登录服务器一看CPU和内存使用率都挺正常但业务日志里频繁出现“数据库连接超时”、“文件写入缓慢”的报错。第一反应是网络问题但网络监控面板一片绿色。这时候一个有经验的运维或者开发下一个排查点大概率会落在磁盘IO上。果不其然使用iostat命令一看某个数据盘的util利用率长时间维持在99%await平均等待时间高达几百毫秒问题根源瞬间清晰磁盘IO成了整个系统的瓶颈。这个场景几乎每天都在各种规模的线上系统中上演。无论是运行着MySQL、Redis的数据库服务器还是处理大量日志、文件的应用程序甚至是个人电脑在编译大型项目时磁盘IOInput/Output输入/输出性能都是决定系统“体感”流畅度的关键因素。CPU再快内存再大如果数据从磁盘读不出来或者写不进去整个流程就得“干等着”。尤其在云计算、虚拟化普及的今天一块物理磁盘可能被多个虚拟机共享IO资源的争用问题更加隐蔽和复杂。因此掌握查看和分析Linux磁盘IO使用情况的方法不是一项可选的技能而是进行系统性能调优、故障排查乃至容量规划的基础功。它帮你回答几个核心问题磁盘忙不忙是谁在让它这么忙是读得多还是写得多速度正常吗本文将抛开理论空谈直接切入实战带你系统性地掌握从基础命令到高级分析的全套工具链并分享我在实际运维中积累的排查心法。2. 核心观测工具四剑客iostat, iotop, vmstat, sarLinux生态的强大之处在于对于“观测”这件事它提供了从不同维度、不同粒度切入的多种工具。针对磁盘IO我们有四位主力“剑客”。2.1 iostat宏观性能指标报告员iostat来自sysstat工具包是查看磁盘IO状况最常用、信息最全的命令。它提供的是设备级的聚合数据。安装与基础使用大多数Linux发行版默认未安装sysstat需要手动安装# CentOS/RHEL/Fedora sudo yum install sysstat # Debian/Ubuntu sudo apt-get install sysstat安装后直接运行iostat会显示自系统启动以来的平均CPU和IO统计这通常不是我们想要的。我们更关注当前的实时状态。关键参数解析iostat -dx 1 3-d 仅显示设备磁盘统计信息不显示CPU。-x 显示扩展统计信息这是分析IO性能的关键提供了远比基础版丰富的数据。1 间隔1秒刷新一次。3 总共输出3次报告后停止。执行后你会看到类似下面的输出以xvda设备为例Device r/s w/s rkB/s wkB/s rrqm/s wrqm/s %rrqm %wrqm r_await w_await aqu-sz rareq-sz wareq-sz svctm %util xvda 0.50 2.10 20.00 84.00 0.00 0.10 0.00 4.55 0.80 1.20 0.01 40.00 40.00 0.60 0.16核心指标深度解读这才是重点r/s, w/s (rkB/s, wkB/s)是什么 每秒的读/写请求次数IOPS和读/写数据量吞吐量KB/s。怎么看 这是最直观的“活动量”指标。高IOPS不一定有问题需结合其他指标看。如果wkB/s持续很高可能是有大量数据写入如日志、数据库持久化需要关注写入目标如/var/log,/data是否合理。%util是什么 磁盘设备的利用率百分比。表示设备有I/O请求即非空闲的时间比率。经典误区与正解%util高不一定代表磁盘慢。对于传统机械硬盘HDD队列深度为1时%util达到100%通常意味着磁盘已饱和I/O请求开始排队。但对于现代固态硬盘SSD或RAID阵列它们支持很高的队列深度和并发操作%util即使达到100%只要await时间很低磁盘依然能提供高性能。所以%util必须与await结合看。await (r_await, w_await)是什么 平均每个I/O请求所需的等待时间包括在队列中排队的时间和服务时间单位毫秒(ms)。这是衡量磁盘响应速度的关键指标直接影响应用性能。经验阈值机械硬盘await通常应低于 20ms。持续高于 50ms 可能表明磁盘繁忙或存在故障。SSD硬盘await通常应低于 5ms甚至更低。r_await和w_await差异大 通常写入的await会高于读取因为写入可能涉及更多的元数据操作或等待数据落盘。但如果两者差异巨大例如写等待时间是读的10倍以上可能需要检查文件系统日志如ext4的journal模式或磁盘的写缓存策略。aqu-sz (avgqu-sz)是什么 平均请求队列长度。即平均有多少个I/O请求在等待被处理。怎么看 如果这个值持续大于1说明磁盘的处理能力跟不上请求产生的速度请求开始堆积。这是%util高和await高的直接原因。svctm是什么 磁盘设备处理一个I/O请求所需的平均服务时间不包括排队时间单位毫秒。注意 在较新的sysstat版本中官方文档已说明svctm指标在并行处理的设备如SSD、RAID上计算不准确未来可能被移除。建议主要参考await。实操心得 我习惯用iostat -dx 1进行实时监控。当发现%util持续高于80%且await也同步飙升时基本可以断定磁盘存在性能瓶颈。接下来就要用iotop找出“元凶”。2.2 iotop定位IO消耗进程的“任务管理器”iostat告诉你磁盘很忙iotop则告诉你是哪个些进程让它这么忙。它类似于top命令但是针对磁盘IO的。安装与使用# 安装 sudo yum install iotop # 或 sudo apt-get install iotop # 以root权限运行实时查看 sudo iotop界面与关键列解读运行后你会看到一个动态刷新的界面主要关注以下几列PID 进程ID。USER 进程所属用户。DISK READ, DISK WRITE 进程的磁盘读写速度KB/s。IO 该进程的I/O优先级类似CPU的nice值。SWAPIN 进程因内存不足导致swap交换的百分比与IO间接相关。COMMAND 进程名。常用交互命令o 只显示当前正在产生I/O的进程让界面更干净。p 在进程/线程视图间切换。有时一个多线程应用如Java的多个线程都在读写切换视图可以聚合查看。a 显示累积的I/O量而不是实时速率。这有助于找出从启动以来“读写总量”最大的进程。左右箭头 按不同列排序。踩坑记录 有一次排查一个MySQL服务器IO高的问题iotop显示一个jbd2内核线程jbd2/xvda1-8写IO很高。这其实是ext4文件系统的日志写入线程。根本原因是一个开发同事误操作在数据盘上执行了find /data -type f这样的全盘扫描触发了大量文件系统元数据访问导致日志频繁提交。所以高IO的进程不一定是你的业务进程也可能是文件系统或内核的后台任务。2.3 vmstat系统整体状态的“快照”vmstat是一个更全面的系统性能查看工具它能提供关于进程、内存、swap、IO和CPU的一个概览。虽然IO信息不如iostat详细但在快速系统检查时非常方便。关键IO相关指标vmstat 1 5输出中的bi(Blocks in) 和bo(Blocks out) 列表示每秒从块设备读入和写出的数据块数通常一块为1024字节。这两个值能快速告诉你系统级别的IO活跃程度。如果bo持续很高可能意味着内存不足系统正在频繁地交换swap内存页到磁盘这是一种严重的性能劣化信号。2.4 sar历史数据的“时光机”sar同样是sysstat工具包的一部分它的强大之处在于能查看历史IO数据。sysstat默认会通过cron任务每10分钟收集一次系统性能数据并保存。查看过去某一天的磁盘IO报告# 查看当天默认的磁盘IO统计每10分钟一个点 sar -d # 查看指定日期的IO统计例如查看2023年10月27日的数据 sar -d -f /var/log/sa/sa27 # sa27 代表27号的数据文件 # 以更易读的格式查看指定时间段的详细IO sar -dp 1 3 # ‘p’可以显示设备名而不是devX-Y格式为什么sar重要很多性能问题是偶发的当问题发生时你可能不在现场。有了sar你就可以在事后回溯查看问题发生时间点的IO状况结合监控系统的业务指标如API响应时间进行关联分析从而准确定位根因。3. 进阶排查当基础命令不够用时掌握了上述四剑客你能解决80%的磁盘IO相关问题。但剩下20%的疑难杂症需要更深入的武器。3.1 使用pidstat进行进程级IO追踪pidstat是sysstat包中另一个利器它可以按进程、按用户输出详细的资源使用统计包括IO。# 查看所有进程的IO统计每秒刷新共5次 pidstat -d 1 5 # 查看指定进程如PID为1234的IO pidstat -d -p 1234 1 5输出中的kB_rd/s和kB_wr/s列清晰地展示了每个进程的读写速率。它比iotop更适合在脚本中调用或进行长时间的数据收集。3.2 使用lsof strace进行深度溯源有时候iotop或pidstat只能告诉你一个进程在大量读写但不知道它到底在读写哪个文件。这时就需要组合拳。第一步用lsof找到进程打开的文件# 假设高IO进程的PID是 8888 lsof -p 8888在输出列表中查找TYPE为REG常规文件且FD列显示为读写模式如3u、4w的行NAME列就是文件路径。这能帮你快速定位到是哪个日志文件、数据库文件或临时文件被疯狂操作。第二步用strace追踪系统调用终极武器如果lsof列出的文件很多或者文件是动态打开的可以用strace动态追踪进程的所有系统调用包括read,write,open,fsync等。sudo strace -p 8888 -e tracefile -f 21 | head -50-p 8888 附加到PID为8888的进程。-e tracefile 只追踪与文件操作相关的系统调用。-f 追踪由该进程创建的所有子进程/线程。21 将标准错误输出重定向到标准输出。head -50 只显示前50行避免刷屏。这个命令会实时打印出进程及其子进程所有文件打开、读、写的操作是定位“幽灵IO”的终极手段。注意strace对性能有较大影响切勿在生产环境长时间运行。3.3 文件系统级洞察fatrace与inotifywait如果你想了解整个系统范围内所有文件的访问情况可以考虑fatraceFile Activity Trace。# 安装可能需要epel源 sudo yum install fatrace # 或 sudo apt-get install fatrace # 监听所有文件访问事件会产生大量输出 sudo fatrace它会输出进程名:PID: 动作 文件路径这样的格式信息量巨大常用于安全审计或深度性能分析。另一个轻量级工具是inotifywait来自inotify-tools包它可以监控特定目录下文件的创建、修改、删除等事件。# 监控 /tmp 目录下的所有文件写入和关闭事件 inotifywait -m -r -e close_write /tmp这在排查“谁在不停修改某个配置文件”这类问题时非常有用。4. 实战案例拆解一次完整的IO瓶颈排查之旅让我们把上面的工具串联起来模拟一个真实的排查场景。背景 线上Web服务器用户反馈图片上传功能时快时慢。第一步宏观确认iostat登录服务器首先运行iostat -dx 1。观察到/dev/sdb数据盘的%util在用户上传时周期性冲到100%w_await最高达到200ms以上而wkB/s写入吞吐并不算特别高。这提示我们磁盘的写入延迟很高可能遇到了随机写或同步写瓶颈。第二步定位元凶iotop/pidstat在iostat监控的同时打开另一个终端运行sudo iotop -o。发现一个名为nginx的进程和几个php-fpm进程在DISK WRITE列有持续活动。但写入速度并不算离谱。同时注意到一个jbd2/sdb1-8线程的写IO间歇性很高。第三步深入分析结合业务nginx和php-fpm写IO是预期的处理上传。但jbd2高说明文件系统元数据操作频繁。使用lsof -p nginx-pid查看nginx进程打开的文件发现它除了访问 socket 和日志还在频繁访问/data/upload/.tmp目录下的许多零时文件。第四步根因推断与验证上传图片时应用PHP可能会先将上传的临时文件保存到磁盘/data/upload/.tmp处理完毕如压缩、加水印后再移动到正式目录。这个“保存临时文件”的动作可能在短时间内创建大量小文件。对于ext4文件系统创建文件需要更新元数据inode、目录项这会触发文件系统日志journal的写入从而引起jbd2线程活跃。大量小文件的随机写入正是机械硬盘的软肋导致w_await飙升。验证 检查PHP应用的上传处理代码确认了临时文件存储逻辑。同时使用sar -d查看历史数据发现每天业务高峰时段sdb的await和%util都有规律性峰值。第五步解决方案短期缓解 将上传临时目录 (upload_tmp_dir) 指向一个tmpfs内存文件系统。这样临时文件的读写完全在内存中进行速度极快且避免了磁盘IO。设置PHP的upload_tmp_dir /dev/shm/php_upload。长期优化硬件层面 将数据盘/dev/sdb从机械硬盘升级为SSD。SSD对随机小文件写入的耐受度远高于HDD。应用层面 优化上传逻辑例如使用流式处理避免在磁盘上完整存储临时文件或者将小文件合并后再写入。文件系统层面 如果使用HDD且必须存储小文件可以考虑使用XFS文件系统它在处理大量小文件元数据时性能通常优于ext4。通过这个案例你可以看到工具链如何协同工作iostat发现宏观异常iotop定位相关进程lsof和业务知识结合推断根因最后给出分层级的解决方案。5. 性能基线建立与监控集成故障排查是被动的优秀的运维更注重主动预防。建立性能基线并集成到监控系统中至关重要。如何建立IO性能基线选择核心指标 对于磁盘我通常关注%util,await,rkB/s,wkB/s。收集常态数据 在业务平稳期如凌晨使用sar -d收集几天甚至一周的数据观察这些指标在无压力时的范围。# 收集一天的数据输出到文件 for i in {1..144}; do iostat -dx 1 1 /tmp/io_baseline.log; sleep 600; done定义告警阈值 基于基线数据设定告警。例如警告%util 80% 且await 50ms (HDD) / 10ms (SSD)持续5分钟。严重%util 95% 且await 200ms (HDD) / 20ms (SSD)持续2分钟。注意一定要结合await单独基于%util告警误报率会很高。集成到监控系统将上述命令和阈值集成到如Prometheus Grafana或Zabbix等监控系统中。Prometheus 使用node_exporter来暴露系统的diskstats指标。在Grafana中你可以轻松绘制出node_disk_io_time_seconds_total类似%util、node_disk_read_time_seconds_total、node_disk_write_time_seconds_total用于计算await等指标的趋势图并设置告警规则。Zabbix 利用其自带的Linux模板或自定义监控项通过zabbix_agent调用iostat或读取/proc/diskstats文件来采集数据。有了历史趋势图和智能告警你就能在用户感知到卡顿之前提前发现磁盘IO的潜在风险比如“每周五下午的await都在缓慢上升”这可能预示着磁盘碎片化加剧或业务量自然增长需要提前进行容量规划或优化。6. 不只是命令理解背后的IO模型与优化思路工具是招式理解原理才是内功。磁盘IO性能受多层因素影响硬件层HDD vs SSD 这是最大的性能鸿沟。HDD擅长顺序大IO惧怕随机小IOSSD对随机IO抗性极强。如果你的应用是随机读写密集型如数据库、邮件服务器SSD是唯一选择。RAID级别 RAID 0 提高吞吐但无冗余RAID 1/10 提高读性能和冗余写性能有损耗RAID 5/6 适合顺序读写随机写性能差写惩罚。本地盘 vs 网络存储如云上的EBS、NAS 网络存储会引入网络延迟其性能受限于网络带宽和IOPS配额。系统层I/O调度器 Linux内核有不同的I/O调度算法如cfq公平队列适合HDD、deadline保证延迟适合数据库、noop简单队列适合虚拟化或SSD。可以通过cat /sys/block/sda/queue/scheduler查看和修改。文件系统ext4稳健通用XFS擅长处理大文件和并发Btrfs和ZFS提供高级特性但更复杂。选择需匹配业务场景。挂载参数 例如noatime不更新文件访问时间可以减少大量元数据写入对读多写少的场景有提升。应用层写入模式 顺序写 vs 随机写。尽量将随机写转化为顺序写如Kafka的日志结构。IO大小 过小的IO如4KB会放大寻址开销。应用可以尝试合并写入Buffer。同步 vs 异步 同步IOO_SYNC保证数据落盘但极慢异步IO性能好但崩溃可能丢数据。根据业务容忍度选择。内存缓存 充分利用内存作为缓存如数据库的innodb_buffer_pool减少直接磁盘访问。一个简单的优化检查清单[ ] 关键业务是否使用了SSD[ ] 数据库的日志文件和数据文件是否分盘存放避免IO竞争[ ] 应用日志级别是否合理避免生产环境输出大量DEBUG日志刷盘。[ ] 是否有定时任务如日志切割、备份在业务高峰时段运行[ ] 文件系统是否使用了noatime挂载选项[ ] 对于虚拟机是否给虚拟磁盘分配了足够的IOPS配额云平台常见问题掌握查看磁盘IO的工具只是第一步结合对硬件、系统、应用的理解形成从监控、分析到优化的完整闭环才能真正驾驭系统的存储性能确保业务流畅稳定。记住指标是表象结合场景的推理和验证才是解决问题的关键。下次再遇到系统“卡顿”不妨先从iostat -dx 1这个简单的命令开始你的侦探之旅。
