解读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的瓶颈,就无法改善了。
总结以上是内存溢出为你收集整理的详读iostat全部内容,希望文章能够帮你解决详读iostat所遇到的程序开发问题。
如果觉得内存溢出网站内容还不错,欢迎将内存溢出网站推荐给程序员好友。
欢迎分享,转载请注明来源:内存溢出
评论列表(0条)