磁盘IO

磁盘：
IO瓶颈往往是我们可能会忽略的地方（我们常会看top，free，netstat，但经常忽略IO的负载情况），今天给大家详细分享一下如何确认一台服务器的IO负载是否达到了瓶颈，以及可能优化、优化的点。
先看一台典型的IO密集型服务器的cpu统计图
可以看到，cpu总使用率不高，平均1.1%，max才5.6%，虽然大部分耗在iowait上，但才5%左右，应该还没到瓶颈吧

安装iostat，通过yum 来安装，需要注意的是，不是直接yum install iostat 而是sudo yum -y install sysstat

[spuser@txxdbackend01 home]$ sudo yum -y install sysstat
Loaded plugins: fastestmirror
Determining fastest mirrors
epel/x86_64/metalink                                                                      | 6.7 kB  00:00:00     
 * base: mirror-hk.koddos.net
 * epel: repos.del.extreme-ix.org
 * extras: mirror-hk.koddos.net
 * updates: mirror-hk.koddos.net
 Total                                                                            206 kB/s | 356 kB  00:00:01     
Running transaction check
Running transaction test
Transaction test succeeded
Running transaction
  Installing : lm_sensors-libs-3.4.0-6.20160601gitf9185e5.el7.x86_64                                         1/2 
  Installing : sysstat-10.1.5-17.el7.x86_64                                                                  2/2 
  Verifying  : lm_sensors-libs-3.4.0-6.20160601gitf9185e5.el7.x86_64                                         1/2 
  Verifying  : sysstat-10.1.5-17.el7.x86_64                                                                  2/2 
Installed:
  sysstat.x86_64 0:10.1.5-17.el7                                                                                 
Dependency Installed:
  lm_sensors-libs.x86_64 0:3.4.0-6.20160601gitf9185e5.el7                                                        
Complete!
[spuser@tzxxbackend01 home]$ 

这里要特别注意：iowait≠io负载，要看真实的IO负载情况，一般使用iostat -x命令

[spuser@txxackend01 home]$ iostat -x 1
Linux 3.10.0-862.el7.x86_64 (txxxackend01.gz.bxxxi.cn)       05/10/2019      _x86_64_        (1 CPU)

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           2.06    0.00    1.72    0.00    0.00   96.21

Device:         rrqm/s   wrqm/s     r/s     w/s    rkB/s    wkB/s avgrq-sz avgqu-sz   await r_await w_await  svctm  %util
fd0               0.00     0.00    0.00    0.00     0.00     0.00     8.00     0.00   37.50   37.50    0.00  37.50   99.00
sda               0.00     0.01    0.04    0.26     2.30     1.96    28.14     0.00    0.30    1.99    0.05   0.10   99.00
sdb               0.00     0.04    0.01    0.05     0.28     8.80   308.66     0.00    8.93    3.84   10.16   0.32  99.00

这里重点指标是svctm和util这两列
svctm指的是“平均每次设备I/O操作的服务时间（毫秒）”
%util指的是“一秒钟内I/O操作的百分比”，可以跟cpu占用百分比差不多，只不过一个是cpu占用一个io占用百分比，这里发现%util已经接近100%，可以知道这台服务器的IO已经到达瓶颈了。
那为什么最前面的cpu统计图的iowait项只有5%呢，因为这个iowait（也就是top里的wa%）指的是从整体来看的，cpu等待io的耗时占比：%wa-iowait，也就是说，cpu拿出一部分时间来等待io完成（iowait），但从磁盘的角度看，磁盘的利用率已经满了（util%），这种情况下，cpu使用率可能不高，但是系统整体QPS已经上不去了，如果加大流量，会导致单次io耗时的继续增加，因为io请求都堵在 队列里了，从而影响系统整体的处理性能。

---

确认了io负载过后，可以使用iotop工具查看io负载主要落在哪个进程上
使用方法为 iotop或者 iotop -o
iotop 会列出所有进程按照IO占用的从大到小排序。
iotop -o 更人性化一些，只列出占用IO最高的，并且用占用情况的。

---

详解iostat命令

[spuser@txxxxxkend01 home]$ iostat -x 1 10
Linux 3.10.0-862.el7.x86_64 (tzxxxend01.gz.bxxxbi.cn)       05/10/2019      _x86_64_        (1 CPU)

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           2.06    0.00    1.72    0.00    0.00   96.21

Device:         rrqm/s   wrqm/s     r/s     w/s    rkB/s    wkB/s avgrq-sz avgqu-sz   await r_await w_await  svctm  %util
fd0               0.00     0.00    0.00    0.00     0.00     0.00     8.00     0.00   37.50   37.50    0.00  37.50   99.00
sda               0.00     0.01    0.04    0.26     2.30     1.96    28.14     0.00    0.30    1.99    0.05   0.10   99.00
sdb               0.00     0.04    0.01    0.05     0.28     8.80   308.66     0.00    8.93    3.84   10.16   0.32   99.00

rrqm/s每秒进行merge的读操作数目
wrqm/s每秒进行merge的写操作数目
r/s每秒完成的读I/O设备次数。
w/s每秒完成的写I/O设备次数， r/s + w/s类似于交款人的总数
rsec/s每秒读扇区数．
wsec/s每秒写扇区数．
rkB/s每秒读字节数．
wkB/s每秒写字节数．
avgrq-sz平均每次设备I/O操作的数据大小（扇区）,类似于平均每人所买的东西多少
avgqu-sz平均I/O队列长度（扇区），类似于单位时间里平均排队的人数
await平均每次设备I/O操作的等待时间（毫秒）,类似于平均每人的平均等待时间
svctm平均每次设备I/O操作的服务时间 （毫秒）,类似于收银员的收款速度
%utll一秒中有百分之多少的时间用于I/O操作（毫秒，IO使用率）,类似于收款台前有人排队的时间比例

如果%util接近100%说明产生的I/O请求太多，I/O系统已经满负荷，该磁盘可能存在瓶颈。
await：await 的大小一般取决于服务时间（svctm）以及I/O队列的长度和I/O请求的发出模式
如果svctm比较接近await说明I/O几乎没有等待时间
如果await远大于svctm，说明I/O队列太长，晌应时间变慢

---

那如何规避IO负载过高的问题呢？具体问题具体分析：

1. 如果你的服务器用来做日志分析，要避免多个crontab交叠执行导致多进程随机IO（参考：随机IO vs 顺序IO），避免定期的压缩、解压大日志（这种任务会造成某段时间的IO抖动）。
2. 如果是前端应用服务器，要避免程序频繁打本地日志、或者异常日志等。
3. 如果是存储服务（mysql、nosql），尽量将服务部署在单独的节点上，不要和其它服务共用，甚至服务本身做读写分离以降低读写压力；调优一些buffer参数以降低IO写的频率等等。另外还可以参考LevelDB这种将随机IO变顺序IO的经典方式。