查看linux服务器io应该看什么意思，linux服务器io性能怎么看

查看Linux服务器IO，核心是看iostat输出中的%util、await和svctm三个指标，再配合iotop定位具体进程，才能判断磁盘是否真正成为性能瓶颈。

很多人一听说服务器卡顿、数据库慢查询增多，第一反应是看CPU和内存，但排查到最后，真正拖后腿的往往是磁盘IO，Linux服务器IO应该看什么意思，这个问题其实不难，难的是不知道每个数字背后代表什么，今天就掰开揉碎,把IO排查这件事讲清楚。

先搞清楚IO指标里的三个关键数字

用iostat -x 1命令后，输出里会冒出一大堆列，新手容易看花眼，别看那么多，真正要盯住的就是%util、await、svctm这三列。

行业共识认为，%util是衡量磁盘忙不忙的第一参考值，它接近100%不代表磁盘坏了，但代表磁盘已经没有多余时间处理新请求，就好比一条马路，如果红灯常亮,车再多也过不去。

await反映的是用户体感，你敲一个命令要转半天圈，数据库查一条记录要等几十毫秒，大概率就是await在飙升，而svctm是设备本身的处理能力，如果svctm很小但await很大，说明大量请求在排队，根子可能出在请求太多,而不是盘太慢。

linux服务器io应该看什么意思：不同场景下的判断逻辑

搞清楚指标含义后，关键是要知道什么情况算正常、什么情况算故障，单纯看一个数字没意义,得结合场景。

连续读写与随机读写要分开看

如果你跑的是大数据批处理，持续大文件读写导致%util接近100%，这属于正常工作负载，不用慌，但如果是Web应用、数据库这类大量随机小IO的场景，%util刚过50%就可能已经感觉到卡顿,因为随机读写对磁盘寻道能力要求更高。

举个例子：MySQL的binlog写入是顺序IO，iostat看起来再高也往往没事；而InnoDB的数据文件更新是随机IO，%util只有三四十时就可能导致事务响应时间翻倍，所以别看一个百分比就下结论,要结合业务类型去理解。

磁盘IO过高如何排查：先看整体，再抓现形

排查linux服务器IO问题，别急着上工具乱试，按顺序来,效率最高。

1. 先跑iostat -x 1观察3-5分钟，看有没有磁盘的%util持续偏高,记下是哪块盘。
2. 再用iotop或pidstat -d定位进程，iotop能实时显示哪个进程在疯狂读盘，pidstat -d能按进程统计IO使用量,两者搭配基本能锁定元凶。
3. 深入具体资源，如果发现是MySQL的进程在大量读盘，进到MySQL里看slow log；如果是Java应用，用jstack看线程栈。
4. 确认文件系统层是否出问题，有时磁盘没坏，但文件系统碎片化严重,会导致实际的IO放大效应。

这套步骤做完，基本能定位是哪个进程、在读写什么文件、是否属于异常行为，多数情况下，问题不是磁盘本身，而是某个程序写的SQL没走索引,或者日志框架配置错误导致疯狂刷盘。

针对数据库服务器io高怎么办，要先分清是读还是写

数据库服务器io高是最常见的头疼问题，遇到这种情况，先跑iostat -x 1看读写占比，判断是读多还是写多,方向完全不同。

读压力大时，看r/s和await，如果每秒读请求数很高且await大，优先考虑加缓存，Redis等内存缓存能挡掉很大一部分读压力，再不行就考虑只读从库分担查询，同时检查SQL，有没有全表扫描，EXPLAIN一下就能看出问题。

写压力大时，重点看w/s和%util，如果每秒写请求并不多但%util很高，通常是每次写入的数据量太大，比如一次UPDATE整个表，如果写请求量本身就大，考虑批量提交、合并小事务,或者将binlog和数据文件分到不同物理磁盘。

有个容易被忽略的点：数据库服务器io高怎么办，答案可能不在数据库本身，如果iostat显示的是系统盘（比如云服务器的/dev/vda1）而不是数据盘在忙，说明系统日志或者临时文件在频繁写入，此时检查/var/log目录大小，看看有没有程序在疯狂输出日志,这是很多生产事故的元凶。

linux iostat命令详解：一条命令看出所有门道

iostat是sysstat包里的工具，没有的话用yum install sysstat或apt install sysstat安装，光会看三个指标还不够,几个参数要熟练。

• iostat -x 1：显示扩展统计信息，每秒刷新一次,这是日常排查最常用的。
• iostat -x 1 5：刷5次后自动停止,适合收集一段时间的采样数据。
• iostat -d -k：只看设备级别的读写速率，以KB为单位,适合快速了解吞吐量。

看输出时，还有两列也值得关注：rrqm/s和wrqm/s，这两列代表合并后的读写在队列中合并了多少，如果值很大，说明系统IO调度器正在发挥作用，Linux默认的deadline或mq-deadline调度器会把相邻的请求合并，减少磁盘寻道，对机械盘尤其重要，如果你看到rrqm/s长期为零，可以检查一下调度器是否被改成了none,这在虚拟化环境中偶尔会出现。

iostat看的是整个磁盘的聚合数据，如果机器上有多块盘，就分不清到底是哪一块在忙，此时要加-p参数，例如iostat -x -p sda sdb 1，按具体磁盘名逐块查看,定位会更精准。

IO瓶颈带来的连锁反应：为什么卡顿会蔓延

磁盘IO告急不只是读写变慢这么简单，它会引发一系列次生问题。CPU使用率看起来很高，实际可能是在等IO，进程在等待磁盘数据时处于D状态（不可中断睡眠），如果用top查看，就会发现CPU的wa（wait）指标持续走高，wa越高，说明CPU在空等IO,这时加CPU核心数毫无意义。

更隐蔽的是，IO慢会导致应用线程被阻塞，连接池被占满，然后新请求排队，最终表现为服务整体无响应，很多程序员第一次排查时盯着CPU和内存看半天，最后发现是磁盘IO在背后作祟，业内专家指出，在业务高峰期，IO延迟的微小抖动会被服务链路放大数倍,所以日常监控IO意义重大。

这就是为什么linux服务器io应该看什么意思这个问题值得每个运维和开发认真对待，它不只是看一个数字,而是通过数字判断整个系统的健康状况。

优化IO性能的几个实际入手点

当确认了IO瓶颈并且定位到具体进程后,可以按优先级做这几件事：

• 调整IO调度器，对SSD使用none调度器，对机械盘保持

  

  deadline，云服务器通常用none更合适，临时修改：echo none > /sys/block/sda/queue/scheduler。

• 加大预读值，用blockdev --setra调整设备预读大小,对顺序读多的高吞吐场景有帮助。
• 把频繁读写的目录移到内存盘，比如临时文件和sock文件放到/dev/shm，减轻磁盘压力，但这适用于可丢失的数据,不要拿数据库文件开玩笑。
• 使用更快的存储层，条件允许时，把核心业务的磁盘从机械盘升级为SSD，或者使用云厂商的高性能云盘,收益往往最直接。
• 从源头减少IO，索引优化、减少全表扫描、日志异步写入、增加Redis缓存层，这些方式比换硬件更考验功底,效果也持久。

IO指标是服务器健康状况的照妖镜

回到最初的疑问：linux服务器io应该看什么意思？答案很明确：看%util判断磁盘是否饱和，看await判断响应是否够快，看svctm区分是设备慢还是队列堵，再用iotop找到真凶，把这几步吃透,遇到服务器卡顿你就多了一把利器。

linux服务器io应该看什么意思？Q&A常见疑问

问：iostat的%util达到100%是不是磁盘就要坏了？

不是。%util只代表设备在工作，100%说明磁盘已经满负荷运转，也可以理解为一种极限工作状态，判断磁盘是否要坏，需要结合dmesg或smartctl查看硬件报错，util长期100%但没有任何错误日志，说明磁盘只是累了,不是病了。

问：服务器io延迟高是什么原因造成的？

原因五花八门，但大多数情况下集中在三个方面：并发请求太多导致排队，单个请求数据量过大导致处理时间变长，以及磁盘自身老化或RAID重建导致性能劣化，用iostat的await和svctm差值可以区分前两种，差值越大越倾向于排队问题,第三种需要结合磁盘健康检查来判断。

问：用top命令看到wa很高，就一定是磁盘IO有问题吗？

基本可以这么认为，但不完全绝对，wa高代表CPU在等待IO完成，这个IO可能是磁盘、也可能是网络文件系统（NFS），先跑iostat确认本地磁盘的读写情况，如果本地盘不忙，再看看有没有挂载网络存储,很多时候是NFS服务端响应慢导致客户端wa飙升。