你的 IO 还好吗

前言

在 CPU 看来内存好慢啊，看我跑的多快；在内存看来磁盘你好慢啊，看我比你还快点；磁盘...

IO 问题并非特别常见，但是因为最终要落到磁盘上，当它成为瓶颈时，往往会拖慢你的脚本，今天我们来分析下在 linux 中的 IO 问题

指标

看 IO 并不只是看 IO，记住这句话，因为很多时候，IO 问题总会伴随着别的问题一起出现，而会导致误判的，从而遗漏了问题的关键。

IO 问题的指标来源于两块：

文件系统
磁盘

iowait

命令

top

iostat

%iowait 表示在一个采样周期内有百分之几的时间属于以下情况：CPU空闲、并且有仍未完成的I/O请求。

指标

iowait 升高或者居高不下，可以考虑存在 IO 瓶颈或压力

rs / ws

命令

iostat -x -d 1

Device:         rrqm/s   wrqm/s     r/s     w/s    rkB/s    wkB/s avgrq-sz avgqu-sz   await r_await w_await  svctm  %util
vda               0.00    13.00    0.00    4.00     0.00    68.00    34.00     0.00    1.00    0.00    1.00   0.25   0.10
dm-0              0.00     0.00    0.00    0.00     0.00     0.00     0.00     0.00    0.00    0.00    0.00   0.00   0.00

指标

r/s: 每秒完成的读 I/O 设备次数。即 rio/s
w/s: 每秒完成的写 I/O 设备次数。即 wio/s
rkB/s: 每秒读K字节数。是 rsect/s 的一半，因为每扇区大小为512字节。
wkB/s: 每秒写K字节数。是 wsect/s 的一半。

从这里可以确定是读或者写存在压力

%util

指标

一秒中有百分之多少的时间用于 I/O 操作，即被io消耗的cpu百分比

如果 %util 接近 100%，说明产生的I/O请求太多，I/O系统已经满负荷，该磁盘可能存在瓶颈

wait

指标

await: 平均每次设备I/O操作的等待时间 (毫秒)。
svctm: 平均每次设备I/O操作的服务时间 (毫秒)。

如果 svctm 比较接近 await，说明 I/O 几乎没有等待时间；如果 await 远大于 svctm，说明I/O 队列太长，io响应太慢，则需要进行必要优化

排查步骤

对于 IO 问题，其实个人遇到的比较少，因为其实现在大多都是 web 类型的服务应用和一些数据处理服务，基本上都是累垮 cpu 和内存的，但是并不代表 IO 问题就没有，当出现问题的时候就很容易被忽视。（这里暂时不讨论网络的 IO 问题，关注于磁盘）

确定当前应用存在 IO 操作：有很多时候你自己都不知道你的应用存在 IO 操作，如：日志操作，临时文件...
确定 iowait ：这个指标很关键，虽然它高不一定 100% 有问题，但是能证明存在了大量的 IO 操作
使用 iostat 看：如果确定了前两项，那么就可以考虑 IO 可能存在瓶颈，就可以看一下读写大不大是否正常
使用 pidstat -d 看：确定是否是自己进程导致，还是别的应用或者是中间件导致
最后看到底是谁在操作并且操作了什么文件：strace + lsof 基本就能分析出最终的一个文件操作了

问题原因

日志打印

这个是最常见的一个问题，大多数情况下，日志的打印基本都是异步的一个操作，并且日志大多数情况下也比较小。但代码是人写的，所以就会出现问题。

最常见的是，将返回值直接输出到日志，有的时候，一些命令的调用或者是一些请求的返回，当出现异常时错误输出可能会很大，而直接输出到日志那么势必会增加 IO 负担。而当出现错误程序员必然会将错误打印日志。而出现错误必然会导致用户重试。

用户重试 -> 命令出错 -> 打印错误日志 -> 用户重试

一方面我见过直接日志把磁盘吃满的情况，一方面还有因为日志开启了 debug 导致其他 IO 等待的问题

临时文件

我们在执行命令或者是利用磁盘做缓存，或者是文件上传，都会产生一些临时文件，而这些临时文件的操作也有可能导致 IO 问题

中间件

mysql 、mongo、redis等等一下常见的组件都会对磁盘进行操作，尤其是数据库这种，存储数据量很大的情况。注意 IO 问题并不一定是写，有可能是读！ 因为你数据存磁盘上，你要进行读取，磁盘的磁头也就扫那么快，要不你就 SSD，否则当读取量很大的时候，那也有可能导致瓶颈

direct

有的时候也和我们操作 IO 的方式有关，如果我们之间跳过系统缓存直接操作磁盘。还有随机写，同步异步也会直接影响 IO 的速度

硬件

虽然这个很不常见，对于我们来说还是很少看到，但不得不提一下，凡是有万一嘛。

最直接的就是磁盘换 ssd，使用 RAID....

如果硬件出现问题，那么可以尝试看看 dmsg 看看是否有出现一些奇怪的报错信息。

总结

就想一开始说的，I/O 往往是一个系统中跑的最慢的，如果它出现瓶颈，那么势必带来的问题就很明显。

同样的，也就是因为是最后一个位置，在这之前都可以通过CPU、内存、缓存等等在这之前搞定它。

如果你的数据最后落库，那么数据库上的 I/O 问题也是需要被考虑在内的。