详读iostat

解读iostat的状态值：——（操作系统层面：iostat -x 1 （x： extend：扩展）

 

%user：用户层面

%system：系统层面，绝大多数情况下是io出现了问题，为什么呢？IO请求（master、double_write、io、page_clear、purge 线程）主要是MySQL发出的， 但是真正处理IO请求的是操作（文件）系统的IO进程完成的。MySQL的各种io请求放到文件系统的io请求队列里面去，文件系统的 IO 进程负责取队列中的请求，读写磁盘中的文件等，这是系统(sys)层面的，假如读写很高的话，sys就很繁忙。

%iowait：能看出系统的瓶颈，43%cpu 花了43%的时间在等待 io，cpu对外显示很忙，但是这个忙有43%的时间在等待IO，说明cpu有43%的时间浪费掉了，但是这期间还不能干别的活，如果iowait很高的话表示浪费cpu资源。

%idle：cpu空闲时间16%，空闲16%，看出cpu很忙，但是iowait，43%的时间在等待io，说明43%的时间我在发呆，所以cpu真正的工作时间在100-16-43=41%左右，其中system的占了23%，user占了17左右，user 表示用户真正工作的时间。

%nice和%steal一般都是0。Steal的意识：我给哪些进程增加优先级，到时候优先级高的会去偷别人的cpu的时间，一般不去调进程的优先级。

User就是用户实际占用cpu工作的时间。

System和iowait一般结合着看，表示系统IO的情况，如果iowait很高的话， 说明cpu花太多的时间在IO等待上，说明系统的IO成为瓶颈了，iowait一般希望小于5%，如果大于25%就说明有问题了。

Idle一般希望大于25%，希望有25%的时间是空闲的。

 

 

 

Rrqm/s：合并读，合并读写一般都是0、如果合并读大于0、很严重的话说明系统有大量的全表扫描（发出的读请求都是连着的，访问相邻的数据页）因为数据库的特点是随机读（oltp交易系统），所以两个读被合并的概率很低，所以如果出现大量的合并读，说明系统在全盘扫描。正常的oltp系统不会出现严重的合并读。

Wrqm/s：合并写，什么情况会出现严重的合并写，比如系统在做批量的 insert，并且 insert 是按照主键依次递增的（插入相邻的数据行）；对于update来说，带where条件，按照主键顺序一会上一会下，很难出现这种合并写。

R/s：每秒读，加起来是系统的IOPS

W/s：每秒写，每秒读+每秒写=IOPS，还可以看出系统是读还是写为主。

Rsec/s：1376每秒读扇区的数量是1376、每个扇区是512字节1376*512/1024=688k

Wsec/s：14728 每秒写扇区的数量是14728、14728*512/1024=7364k/1024=7.1M,相加就是IO（读写）的吞吐量，每秒传输多少M，可以算一下，这里是8M左右。

Avgrq-sz：每个排队时间的平均处理的扇区数，avgrq-sz 101和abgqu-sz 3表示，前面平均有3个io请求，3 个 io请求平均总的请求101个扇区，也就是每个io请求33个扇区，一个扇区512字节，33*0.5=16k，每个io请求16k，一个数据块是16k。

Avgqu-sz：平均队列长度，2.82表示，平均等待队列长度是2.82个io请求，毫秒级，io的排队时间反应当前io是否过量，

Await：平均等待时间就是实际一个io请求的响应时间，=svctime*avgqu-sz，=排队的时间*队列中请求的平均长度（响应时间=排队时间+服务时间），>20ms就是性能不好了，一般认为小于6ms是性能正常的。

一堆请求过来，放到io队列里，a请求等待的时间就是等待时间。

Svctm：service_time，每一个请求的服务时间，反应了io性能，5、6ms表示io性能还可以，可以降到1ms 一下。有raid卡的的情况下，系统以写为主的话，一般这个值正常是接近于0.

如果队列有点长，需要提升io的能力，这时候可以尝试把表示io能力的服务时间降到1ms以下，这时候响应快了，队列就短了，但是也不是绝对的，如果到达了io的瓶颈，就无法改善了。

 

转载于:https://www.cnblogs.com/5945yang/p/11310230.html