最近发现API服务的负载有几台入口机器负载很高，4C的机器负载经常飙升至10以上，且长时间负载不降， 但是CUP的使用率不是很高，不到20%，这几台入口机器部署了NG， 所以经常影响这个服务的接口请求转发， 影响接口的响应速度。
iostat -x 1 10 观测了下机器的IO情况：
await：每一个IO请求的处理的平均时间（单位是微秒毫秒）。这里可以理解为IO的响应时间，一般地系统IO响应时间应该低于5ms，如果大于10ms就比较大了。
%util：在统计时间内所有处理IO时间，除以总共统计时间。例如，如果统计间隔1秒，该设备有0.8秒在处理IO，而0.2秒闲置，那么该设备的%util = 0.8/1 = 80%，所以该参数暗示了设备的繁忙程度。一般地，如果该参数是100%表示设备已经接近满负荷运行了（当然如果是多磁盘，即使%util是100%，因为磁盘的并发能力，所以磁盘使用未必就到了瓶颈）。
原因：
1. 服务器IO繁忙， 等待时间超长。
2. 业务日志写入量过大， 平均每小时1G，日志的压缩迁移同样费性能。
3. 机器4c云主机，服务超过3年，机器不够power；
解决方法：
1. 研发层精简日志，不重要的业务接口尽量少打日志， 重要接口日志精简， 同时将重要接口请求转发至8C的机器负载低的机器。
2. NG部署优化，将原先4C机器上的NG服务迁移至8C的负载较低的机器， 提高接口请求响应速度。
3. 扩容机器， 一般老板都不同意， O(∩_∩)O哈哈~。
附： iostat命令使用
原文： http://www.fx114.net/qa-262-85784.aspx
iostat是一个I/O statistics（输入/输出统计）的缩写，主要的功能是对系统的磁盘I/O操作进行监视。它的输出主要显示磁盘读写操作的统计信息，同事给出CPU的使用情况。同vmstat一样，iostat也不能对某个进程进行深入分析，仅对系统的整体情况进行分析。
iostat一般不随系统安装，要使用iostat工具，需要在系统上安装一个sysstat的工具包。sysstat是一个开源软件，官方网址为：http://sebastien.godard.pagesperso-orange.fr/，可以选择源码包或rpm包的方式安装。安装完毕，系统会多出3个工具：iostat、sar、mpstat，然后就可以直接在系统下运行iostat命令了。
iostat命令的语法如下：
iostat [ -c | -d ] [ -k ] [ -t ] [ -x [ device ] ] [ interver [ count ] ]
各个选项及参数含义如下：
-c：显示CPU的使用情况。
-d：显示磁盘的使用情况。
-k：美妙以KB为单位显示数据。
-t：打印统计信息开始执行的时间。
-x device：指点要统计的设备名称，默认为所有的磁盘设备。
interval：指定两次统计间隔的时间。
count：按照“interval”指定的时间间隔统计的次数。
1、基本使用
[root@rhel /]# iostat -c
Linux 2.6.18-194.el5 (rhel) 2013年08月27日
avg-cpu: %user %nice %system %iowait %steal %idle
0.13 0.05 0.44 0.79 0.00 98.59
在这里，使用了“-c”参数，只显示系统CPU的统计信息，输出中没想代表的含义与sar命令的输出项完全相同。
下面通过“iostat -d”命令组合来查看系统磁盘的使用状况：
[root@rhel /]# iostat -d 2 3
Linux 2.6.18-194.el5 (rhel) 2013年08月27日
Device: tps Blk_read/s Blk_wrtn/s Blk_read Blk_wrtn
sda 1.57 54.36 10.34 861605 163828
sda1 0.00 0.14 0.00 2154 4
sda2 1.57 54.20 10.34 859147 163824
sdb 2.21 29.63 23.80 469667 377312
sdb1 0.00 0.07 0.00 1188 0
sdb2 2.21 29.50 23.80 467591 377312
dm-0 3.13 54.13 10.34 857970 163824
dm-1 0.01 0.06 0.00 896 0
Device: tps Blk_read/s Blk_wrtn/s Blk_read Blk_wrtn
sda 0.00 0.00 0.00 0 0
sda1 0.00 0.00 0.00 0 0
sda2 0.00 0.00 0.00 0 0
sdb 1.50 0.00 32.00 0 64
sdb1 0.00 0.00 0.00 0 0
sdb2 1.50 0.00 32.00 0 64
dm-0 0.00 0.00 0.00 0 0
dm-1 0.00 0.00 0.00 0 0
Device: tps Blk_read/s Blk_wrtn/s Blk_read Blk_wrtn
sda 1.00 0.00 44.00 0 88
sda1 0.00 0.00 0.00 0 0
sda2 1.00 0.00 44.00 0 88
sdb 1.50 0.00 32.00 0 64
sdb1 0.00 0.00 0.00 0 0
sdb2 1.50 0.00 32.00 0 64
dm-0 5.50 0.00 44.00 0 88
dm-1 0.00 0.00 0.00 0 0
这里需要注意的一点是，上面输出的第一项是系统从启动到统计时的所有传输信息，第二次输出的数据才代表在检测的时间段内系统的输出值。
tps：该设备每秒的传输次数（Indicatethe number of transfers per second that were issued to the device.）。“一次传输”意思是“一次I/O请求”。多个逻辑请求可能会被合并为“一次I/O请求”。“一次传输”请求的大小是未知的。
Blk_read/s：每秒从设备（driveexpressed）读取的块数。
Blk_wrtn/s：每秒向设备（driveexpressed）写入的块数。
Blk_read：表示读取的所有块数。
Blk_wrtn：表示写入的所有块数。
可以通过Blk_read/s和Blk_wrtn/s的值对磁盘的读写性能有一个基本的了解：如果Blk_wrtn/s值很大，表示磁盘的写操作很频繁，可以考虑优化磁盘或优化程序；如果Blk_read/s值很大，表示磁盘的读操作很多，可以将读取的数据放入内存中进行操作。这两个值没有一个固定的大小，根据系统应用的不同，会有不同的值。但是有一个规则还是可以遵循的：长期的、超大的数据读写，肯定是不正常的，这种情况一定会影响系统性能。
"iostat -x"组合还提供了对磁盘的的单独统计，如果不指定磁盘，默认是对所有磁盘进行统计。例如下面这个输出：
[root@rhel /]# iostat -x /dev/sdb 2 3
Linux 2.6.18-194.el5 (rhel) 2013年08月27日
avg-cpu: %user %nice %system %iowait %steal %idle
0.12 0.04 0.43 0.76 0.00 98.65
Device: rrqm/s wrqm/s r/s w/s rsec/s wsec/s avgrq-sz avgqu-sz await svctm %util
sdb 0.10 0.02 0.92 1.24 27.44 24.11 23.82 0.03 15.70 5.64 1.22
avg-cpu: %user %nice %system %iowait %steal %idle
0.00 0.00 0.51 0.25 0.00 99.24
Device: rrqm/s wrqm/s r/s w/s rsec/s wsec/s avgrq-sz avgqu-sz await svctm %util
sdb 0.00 0.00 0.00 1.49 0.00 31.84 21.33 0.01 8.00 4.33 0.65
avg-cpu: %user %nice %system %iowait %steal %idle
0.00 0.00 0.26 0.26 0.00 99.49
Device: rrqm/s wrqm/s r/s w/s rsec/s wsec/s avgrq-sz avgqu-sz await svctm %util
sdb 0.00 0.00 0.00 1.50 0.00 32.00 21.33 0.01 7.67 4.00 0.60
rrqm/s：每秒这个设备相关的读取请求有多少被Merge了（当系统调用需要读取数据的时候，VFS将请求发到各个FS，如果FS发现不同的读取请求读取的是相同Block的数据，FS会将这个请求合并Merge）；
wrqm/s：每秒这个设备相关的写入请求有多少被Merge了。
rsec/s：每秒读取的扇区数；
wsec/：每秒写入的扇区数。
r/s：The number of readrequests that were issued to the device per second；
w/s：The number of writerequests that were issued to the device per second；
await：每一个IO请求的处理的平均时间（单位是微秒毫秒）。这里可以理解为IO的响应时间，一般地系统IO响应时间应该低于5ms，如果大于10ms就比较大了。
%util：在统计时间内所有处理IO时间，除以总共统计时间。例如，如果统计间隔1秒，该设备有0.8秒在处理IO，而0.2秒闲置，那么该设备的%util = 0.8/1 = 80%，所以该参数暗示了设备的繁忙程度。一般地，如果该参数是100%表示设备已经接近满负荷运行了（当然如果是多磁盘，即使%util是100%，因为磁盘的并发能力，所以磁盘使用未必就到了瓶颈）。
2、常见用法
iostat -d -k 1 10 #查看TPS和吞吐量信息
iostat -d -x -k 1 10 #查看设备使用率（%util）、响应时间（await）
iostat -c 1 10 #查看cpu状态
3、实例分析
$iostat -d -k 1 |grep sda10
上面看到，磁盘每秒传输次数平均约400；每秒磁盘读取约5MB，写入约1MB。
iostat -d -x -k 1可以看到磁盘的平均响应时间<5ms，磁盘使用率>80。磁盘响应正常，但是已经很繁忙了。
延伸：
rrqm/s:每秒进行 merge 的读操作数目.即 delta(rmerge)/s
wrqm/s:每秒进行 merge 的写操作数目.即 delta(wmerge)/s
r/s:每秒完成的读 I/O 设备次数.即delta(rio)/s
w/s:每秒完成的写 I/O 设备次数.即 delta(wio)/s
rsec/s:每秒读扇区数.即 delta(rsect)/s
wsec/s:每秒写扇区数.即 delta(wsect)/s
rkB/s:每秒读K字节数.是 rsect/s 的一半,因为每扇区大小为512字节.(需要计算)
wkB/s:每秒写K字节数.是 wsect/s 的一半.(需要计算)
avgrq-sz:平均每次设备I/O操作的数据大小 (扇区).delta(rsect+wsect)/delta(rio+wio)
avgqu-sz:平均I/O队列长度.即delta(aveq)/s/1000 (因为aveq的单位为毫秒).
await:平均每次设备I/O操作的等待时间 (毫秒).即 delta(ruse+wuse)/delta(rio+wio)
svctm:平均每次设备I/O操作的服务时间 (毫秒).即 delta(use)/delta(rio+wio)
%util:一秒中有百分之多少的时间用于 I/O 操作,或者说一秒中有多少时间 I/O 队列是非空的.即 delta(use)/s/1000 (因为use的单位为毫秒)
如果 %util 接近 100%,说明产生的I/O请求太多,I/O系统已经满负荷,该磁盘
可能存在瓶颈.
idle小于70% IO压力就较大了,一般读取速度有较多的wait.
同时可以结合vmstat 查看查看b参数(等待资源的进程数)和wa参数(IO等待所占用的CPU时间的百分比,高过30%时IO压力高)
另外 await 的参数也要多和 svctm 来参考.差的过高就一定有 IO 的问题.
avgqu-sz 也是个做 IO 调优时需要注意的地方,这个就是直接每次操作的数据的大小,如果次数多,但数据拿的小的话,其实 IO 也会很小.如果数据拿的大,才IO 的数据会高.也可以通过 avgqu-sz × ( r/s or w/s ) = rsec/s or wsec/s.也就是讲,读定速度是这个来决定的.
另外还可以参考
svctm 一般要小于 await (因为同时等待的请求的等待时间被重复计算了),svctm 的大小一般和磁盘性能有关,CPU/内存的负荷也会对其有影响,请求过多也会间接导致 svctm 的增加.await 的大小一般取决于服务时间(svctm) 以及 I/O 队列的长度和 I/O 请求的发出模式.如果 svctm 比较接近 await,说明 I/O 几乎没有等待时间；如果 await 远大于 svctm,说明 I/O 队列太长,应用得到的响应时间变慢,如果响应时间超过了用户可以容许的范围,这时可以考虑更换更快的磁盘,调整内核 elevator 算法,优化应用,或者升级 CPU.
队列长度(avgqu-sz)也可作为衡量系统 I/O 负荷的指标,但由于 avgqu-sz 是按照单位时间的平均值,所以不能反映瞬间的 I/O 洪水.
别人一个不错的例子.(I/O 系统 vs. 超市排队)
举一个例子,我们在超市排队 checkout 时,怎么决定该去哪个交款台呢? 首当是看排的队人数,5个人总比20人要快吧? 除了数人头,我们也常常看看前面人购买的东西多少,如果前面有个采购了一星期食品的大妈,那么可以考虑换个队排了.还有就是收银员的速度了,如果碰上了连钱都点不清楚的新手,那就有的等了.另外,时机也很重要,可能 5 分钟前还人满为患的收款台,现在已是人去楼空,这时候交款可是很爽啊,当然,前提是那过去的 5 分钟里所做的事情比排队要有意义 (不过我还没发现什么事情比排队还无聊的).
I/O 系统也和超市排队有很多类似之处:
r/s+w/s 类似于交款人的总数
平均队列长度(avgqu-sz)类似于单位时间里平均排队人的个数
平均服务时间(svctm)类似于收银员的收款速度
平均等待时间(await)类似于平均每人的等待时间
平均I/O数据(avgrq-sz)类似于平均每人所买的东西多少
I/O 操作率 (%util)类似于收款台前有人排队的时间比例.
我们可以根据这些数据分析出 I/O 请求的模式,以及 I/O 的速度和响应时间.
