iostat命令产生三类数据报表： cpu使用率、设备使用率、网络文件系统使用。下面先看一下前面两个数据指标的定义，以及如何帮助性能调优上发现问题点。
CPU使用率：
%user, 用户态的代码cpu执行时间占比
%nice, 带有nice优先级的用户态代码cpu使用时间占比
%system,内核态代码cpu使用占比
%iowait, 等待外部io的过程中，cpu空闲的时间占比
%steal，管理程序维护另一个虚拟处理器时，虚拟CPU的无意识等待时间百分比
%idle，cpu空闲时间占比
设备使用率：
tps, transfer per second,每秒io 请求个数
blk_read/s 每秒读的block的个数
blk_wrtn/s，每秒写的block的个数
blk_read，总共的读的block的个数
blk_wrtn,总共的写的block的个数
kb_read/s，每秒读的kb个数
kb_wrtn/s，每秒写的kb个数
mb_read/s,每秒读的mb个数
mb_wrtn/s每秒写的mb个数
mb_read，总共读的mb个数
mb_wrtn,总共写的mb个数
rrqm/s，read request mereded were queue ， 每秒排队的合并的读请求
wrqm/s，每秒排队的合并的写请求
r/s，每秒发布的读请求
w/s，每秒发布的写请求
rsec/s，每秒读的扇区的个数
wsec/s，每秒写的扇区的个数
rKb/s，每秒读的kb
wKb/s，每秒写的kb
avgrq-sz,发布的请求的平均大小，以扇区为单位
avggqu-sz,发布的请求的平均队列大小
await，平均io的时间，包括在队列中的时间，和实际执行的时间
utils,设备利用率，如果接近100，说明设备负载饱和
案例1
上面这个案例，查看是磁盘sda的性能情况。io写的指标w_await,平均耗时6ms，读平均耗时是5.33ms，磁盘使用率是1.04%，对于5200转速的硬盘来讲，这个性能数据看起来还可以。但是有一个地方有问题：cpu花在内核执行时间占比居然达到37.89%，超过用户占比23.45%。如果该机器上，还有别的程序在做io的事情，也许还可理解，但是如果只有被监测的目标程序一个，可能需要分析原因了。
有两个指标也可能提供了一些线索，w/s, wrqm/s，每秒写的请求个数和每秒进入写队列的请求个数。相对于wMB/s的0.14，每秒写0.14MB，但是io写的还是慢了。刚才提了，如果硬盘是5200转速的话，且有w_await佐证，单次io执行的速度并不慢，所以得需要看一下应用程序是如何进行io的。比如如果应用程序从用户态copy到内核态，然后再进行真正io，或者在内核态做了很多事情，都有可能导致这样的情况。
案例2：
从这个图中，我们可以看到，磁盘使用率是饱和状态，达到了100%，写的平均耗时超过了871ms，队列中io请求个数超过1010，每秒写81M的数据。因为磁盘负荷饱和，io执行时间过长，导致CPU因为等待io而空闲，空闲时间占比超过了47.89%。为了改善性能，需要从应用程序层面想办法降低IO的数据量，比如数据缓存在内存里（如page cache）、后台异步方式落盘等等策略。
小结
对于io密集型的应用或者任务，需要密切关注io操作对性能的影响。掌握iostat，理解背后的指标意义，针对不同的类型的IO性能问题，进行分析，对症下药找到不同的解决方案。