查看服务器磁盘IO使用情况，最直接的方式是用iostat命令，结合vmstat和iotop能快速定位是哪个进程在拖慢磁盘。无论你是刚接触服务器运维，还是已经被卡顿折磨了一下午，这篇文章就是帮你理清思路的实操手册。
常用的磁盘IO查看指令有哪些
很多朋友一上来就装各种监控面板,其实Linux自带的工具完全够用，记住一个原则：先看整体水位，再抓具体的“捣乱分子”。
用iostat看整体健康度
iostat是sysstat包里的核心工具，多数Linux发行版默认自带，如果提示找不到命令，用yum install sysstat或apt install sysstat装一下即可。
输入iostat -x 1 3，意思是每秒刷新一次，连续显示三次，你需要盯住这几个指标：
- %util：磁盘忙绿程度。超过80%基本可以判定磁盘是瓶颈了，但要注意，如果是SSD或者RAID阵列卡，这个值可能虚高，得结合后面的await一起看。
- await：I/O请求的平均等待时间（毫秒），机械盘在10ms以内算正常，超过20ms就是明显变慢；固态盘通常应该在1ms左右，如果到5ms以上就该查查了。
- svctm：这项在新版iostat里已经不太推荐使用，因为它被取消的传言很多，行业共识是直接看await就够了。
用top和vmstat快速判断是不是IO问题
有时候服务器负载高,以为是CPU问题，实际是磁盘拖后腿，记住这个判断技巧：top里看wa这一项，也就是CPU等待I/O的时间占比。wa超过30%，基本可以断定是磁盘IO在拖累整体性能。
再看vmstat 1的输出，重点看b列（阻塞进程数）和si、so（交换区读写），如果b列长期大于1，而且si和so频繁变化，说明内存不够导致系统在疯狂换页，磁盘IO被内存在无形中吃掉了大半。
iotop定位哪个进程在抢资源
iostat只能告诉你磁盘很忙，但不会告诉你谁在忙，这时候需要iotop，这个工具需要root权限，直接运行iotop -o，-o参数的意思是只显示有IO操作的进程。
TID列是线程ID，PRIO是优先级，IO>列显示了读和写的速率，往下看能找到进程名，比如遇到java进程的IO写速率飙到几十MB/s，那就要考虑是不是日志写得太频繁，或者GC时在疯狂做磁盘持久化。
磁盘IO占用过高如何排查与定位
发现磁盘IO飙高后,建议按照“确认现象→定位进程→分析原因”的顺序来操作，而不是直接重启服务器。
数据库服务器突然变慢
朋友遇到MySQL查询突然变慢,他第一反应是看慢查询日志，其实应该先看IO，用iostat -x 1观察，如果%util持续100%，但await只有几毫秒，这多半是SSD的IO队列积压，这时候用iotop能发现是mysqld进程在疯狂写binlog日志。
最直接的办法是把binlog和data目录分开到不同磁盘，或者调整sync_binlog=0来降低写盘的频率（但会有丢数据的风险，生产环境要慎重）。
网站页面加载速度慢
打开网页要好几秒,CPU和内存都正常，那就是磁盘在读操作上卡住了，用pidstat -d 1这个命令，能直接看到每个进程的磁盘读写量。
之前遇到过一个案例,pidstat显示某个PHP-FPM进程每秒读磁盘20多MB，后来发现是代码里循环读了一个大缓存文件，改成都存入Redis后，IO压力直接降到了一成左右。
磁盘读写速率远低于标称值
很多人买VPS或者独立服务器时,商家标称“读500MB/s”，自己用dd命令测出来只有一半，就来网上着急地问是不是被限制IO了。
这里要明白一个常识：云服务器都存在“邻居效应”，实测性能受宿主机负载、磁盘类型、块大小多重因素影响，比较靠谱的测法是用fio工具：
fio --filename=/tmp/testfile --direct=1 --rw=randrw --bs=4k --size=1G --numjobs=4 --runtime=30 --group_reporting --name=test注意看read IOPS和write IOPS结果，而不是单纯的MB/s数值，对于4K小文件的随机读写，IOPS才是衡量磁盘性能的关键指标。
解决磁盘IO瓶颈的几个实操优化方法
排查出问题只是第一步,真正要让服务器磁盘io使用情况降下来，你需要从应用、文件系统、硬件三个层面去调整。
调整IO调度器适应你的场景
Linux的IO调度算法有三种：noop、deadline和cfq，查看当前使用哪种：
cat /sys/block/sda/queue/schedulerSSD建议用noop或deadline，因为固态盘本身没有机械臂寻道的问题，用cfq反而增加无谓的队列开销，机械硬盘用deadline来保证延迟可控，临时切换可以执行：
echo deadline > /sys/block/sda/queue/scheduler永久修改需要在grub启动参数里加上elevator=deadline，不同的发行版修改方式略有差异，改之前记得先备份grub配置文件。
优化日志写入频率
应用程序写日志是最容易被忽略的IO消耗点,一位做高并发网关的朋友分享过经验：把日志从同步写改成异步写，IO使用率直接下降了40%。
具体操作是根据语言框架来,比如Java系的Log4j2，可以配置AsyncLogger；Nginx的access_log加buffer=32k这样的参数，让日志攒一批再写盘。
扩容与升级硬件的思考路径
软件层面的调整做到位了,如果还是不满足，才考虑硬件层面的处理。
- 检查当前磁盘是不是老旧的机械盘,换SATA SSD一般能带来4-6倍性能提升
- 如果用的是入门级VPS,大概率是共享热盘，考虑升级到NVMe SSD机型
- 不差钱或者对性能有极致要求,可以上NVMe组RAID 1，带宽和冗余兼顾
选购时建议用hdparm -t /dev/sda实测一下当前盘速作为基线，然后对比各方案，不要只看商家标称的峰值速率。
理解磁盘IOPS和吞吐量的区别
很多人在排查磁盘io使用情况时,对“IOPS高”和“吞吐量大”感到困惑，不知道哪个才是问题根源。
| 指标 | 含义 | 常见瓶颈场景 |
|---|---|---|
| IOPS | 每秒处理的读写请求次数 | 小文件频繁读写，如数据库查询、日志写入 |
| 吞吐量 | 每秒传输的数据量 | 大文件顺序读写，如视频转码、备份传输 |
识别技巧：如果iostat里tps很高但kB_read/s不高，这是IOPS瓶颈；反过来tps不高但kB_read/s把带宽打满了，那就是吞吐量问题。
针对IOPS瓶颈,优先考虑调整应用层逻辑，减少频繁的小写入；针对吞吐量瓶颈，就要考虑换更高带宽的磁盘阵列，而不是盲目加缓存。
常见的监控告警配置建议
手动排查不能每天做,配置好监控告警才是成熟运维的做法，核心思路是设置好阈值，让系统主动通知你。
- CPU的wa值：持续5分钟超过20%就告警，这往往暗示磁盘出问题
- %util：持续10分钟超过80%触发告警，排查是否有异常进程
- 磁盘空间+inode：超过85%就要留意，因为清理也要时间，别等满了才处理
工具推荐用Prometheus + node_exporter，或者简单的crontab + sysstat把数据存到历史记录里，不管是哪种方案，都要保留至少30天的历史数据，方便回溯是持续性问题还是突发高峰引起的。
关于查看服务器磁盘io的常见疑问解答
云服务器和物理服务器查磁盘IO的方法有区别吗？
方法上基本一致,iostat和iotop都能用，但要注意一点，云服务器的%util指标会受到宿主机层面其他虚拟机的影响，有时候你看到数值偏高其实不是自己这台机器导致的，可能是物理机上其他邻居在抢占IO资源。
看了iostat输出但看不懂哪些数值重要怎么办？
按优先级排序,先看%util是否接近100%，再看await和w_await是否远高于基准值，最后用iotop确认进程，初学者容易陷入分析很多参数细节的困境，其实这套流程能解决大部分问题，参数细节了解即可，实际工作中有三类关键指标就够了：利用率、等待时间、队列长度。
磁盘IO高一定会导致网站访问变慢吗？
不一定会,要看瓶颈是出现在“排队等待”还是“数据没有及时被处理”，如果磁盘持续繁忙但队列不算长，说明进程在按序处理，影响可能只是轻微延迟；但如果iostat里的aqu-sz（队列长度）长期超过2，页面响应时间明显拉长，那用户就能直接感受到卡顿，判断的关键在于对比正常时期的IO数据，日常留意运维基线很重要。
磁盘IO的排查本身就是“假设-验证“的过程，把iostat当听诊器，iotop当放大镜，加上对业务读写特征的理解能力，大多数问题都能当场定位。与其盲目调参，不如结合业务实际多观察几天，你对自己服务器的了解程度，就是最优的监控告警系统。
首发原创文章，作者：王坚，如若转载，请注明出处：https://idctop.com/article/783985.html
