商云软件操作流程（容易被误读的iostat(Linux系统)）

iostat主要用于报告中央处理器（CPU）统计信息和整个系统
    
    
   、适配器     


     


     

、tty 设备 




 




 




、磁盘和 CD-ROM 的输入/输出统计信息    
    
    
，下面小编就为大家具体的讲解Linux系统中容易被误读的IOSTAT
    
    
   。

iostat(1)是在Linux系统上查看I/O性能最基本的工具 


     


     


   ，然而对于那些熟悉其它UNIX系统的人来说它是很容易被误读的     


     


     

。比如在HP-UX上 avserv（相当于Linux上的 svctm）是最重要的I/O指标

 




 




 

，反映了硬盘设备的性能   

   

   

，它是指I/O请求从SCSI层发出

   

   

  、到I/O完成之后返回SCSI层所消耗的时间  

     

     

  ，不包括在SCSI队列中的等待时间


  




  




  
，所以avserv体现了硬盘设备处理I/O的速度  


  


  


，又被称为disk service time   
     
     
 ，如果avserv很大



   




   




   ，那么肯定是硬件出问题了 




 




 




。然而Linux上svctm的含义截然不同 



 



 



，事实上在iostat(1)和sar(1)的man page上都说了不要相信svctm              ，该指标将被废弃：

“Warning! Do nottrust this field any more. This field will be removed ina future sysstat version.    
    
    
”

在Linux上




    




    




    ，每个I/O的平均耗时是用await表示的













，但它不能反映硬盘设备的性能               ，因为await不仅包括硬盘设备处理I/O的时间



     



     



    ，还包括了在队列中等待的时间

   

   

  。I/O请求在队列中的时候尚未发送给硬盘设备













，即队列中的等待时间不是硬盘设备消耗的    
    
    
，所以说await体现不了硬盘设备的速度 


     


     


   ，内核的问题比如I/O调度器什么的也有可能导致await变大     

     

     
。那么有没有哪个指标可以衡量硬盘设备的性能呢？非常遗憾的是

 




 




 

，iostat(1)和sar(1)都没有   

   

   

，这是因为它们所依赖的/proc/diskstats不提供这项数据  




  




  




。要真正理解iostat的输出结果  

     

     

  ，应该从理解/proc/diskstats开始


  


  


 。

/proc/diskstats有11个字段


  




  




  
，以下内核文档解释了它们的含义https://www.kernel.org/doc/Documentation/iostats.txt  


  


  


，我重新表述了一下   
     
     
 ，注意除了字段#9之外都是累计值



   




   




   ，从系统启动之后一直累加：

(rd_ios)读操作的次数     
     
     。(rd_merges)合并读操作的次数   




   




   




。如果两个读操作读取相邻的数据块时 



 



 



，可以被合并成一个              ，以提高效率



 



 



。合并的操作通常是I/O scheduler（也叫elevator）负责的               。(rd_sectors)读取的扇区数量    




    




    



。(rd_ticks)读操作消耗的时间（以毫秒为单位）














。每个读操作从__make_request()开始计时




    




    




    ，到end_that_request_last()为止













，包括了在队列中等待的时间              。(wr_ios)写操作的次数     



     



     


。(wr_merges)合并写操作的次数














。(wr_sectors)写入的扇区数量
    
    
   。(wr_ticks)写操作消耗的时间（以毫秒为单位）     


     


     

。(in_flight)当前未完成的I/O数量 




 




 




。在I/O请求进入队列时该值加1               ，在I/O结束时该值减1

   

   

  。

注意：是I/O请求进入队列时



     



     



    ，而不是提交给硬盘设备时     

     

     
。(io_ticks)该设备用于处理I/O的自然时间(wall-clock time)  




  




  




。

请注意io_ticks与rd_ticks(字段#4)和wr_ticks(字段#8)的区别













，rd_ticks和wr_ticks是把每一个I/O所消耗的时间累加在一起    
    
    
，因为硬盘设备通常可以并行处理多个I/O 


     


     


   ，所以rd_ticks和wr_ticks往往会比自然时间大


  


  


 。而io_ticks表示该设备有I/O（即非空闲）的时间

 




 




 

，不考虑I/O有多少   

   

   

，只考虑有没有     
     
     。在实际计算时  

     

     

  ，字段#9(in_flight)不为零的时候io_ticks保持计时


  




  




  
，字段#9(in_flight)为零的时候io_ticks停止计时   




   




   




。(time_in_queue)对字段#10(io_ticks)的加权值



 



 



。字段#10(io_ticks)是自然时间  


  


  


，不考虑当前有几个I/O   
     
     
 ，而time_in_queue是用当前的I/O数量（即字段#9 in-flight）乘以自然时间               。虽然该字段的名称是time_in_queue



   




   




   ，但并不真的只是在队列中的时间 



 



 



，其中还包含了硬盘处理I/O的时间    




    




    



。iostat在计算avgqu-sz时会用到这个字段














。

iostat(1)是以/proc/diskstats为基础计算出来的              ，因为/proc/diskstats并未把队列等待时间和硬盘处理时间分开




    




    




    ，所以凡是以它为基础的工具都不可能分别提供disk service time以及与queue有关的值              。

注：下面的公式中“Δ 


     


     


   ”表示两次取样之间的差值













，“Δt

 




 




 

”表示采样周期     



     



     


。

r/s：每秒读操作的次数=[Δrd_ios/Δt]r/s：每秒读操作的次数=[Δwr_ios/Δt]tps：每秒I/O次数=[(Δrd_ios+Δwr_ios)/Δt]rkB/s：每秒读取的千字节数=[Δrd_sectors/Δt]*[512/1024]wkB/s：每秒写入的千字节数=[Δwr_sectors/Δt]*[512/1024]rrqm/s：每秒合并读操作的次数=[Δrd_merges/Δt]wrqm/s：每秒合并写操作的次数=[Δwr_merges/Δt]avgrq-sz：每个I/O的平均扇区数=[Δrd_sectors+Δwr_sectors]/[Δrd_ios+Δwr_ios]avgqu-sz：队列里的平均I/O请求数量=[Δtime_in_queue/Δt]

（更恰当的理解应该是平均未完成的I/O请求数量














。）await：每个I/O平均所需的时间=[Δrd_ticks+Δwr_ticks]/[Δrd_ios+Δwr_ios]

不仅包括硬盘设备处理I/O的时间               ，还包括了在kernel队列中等待的时间
    
    
   。r_await：每个读操作平均所需的时间=[Δrd_ticks/Δrd_ios]

不仅包括硬盘设备读操作的时间



     



     



    ，还包括了在kernel队列中等待的时间     


     


     

。w_await：每个写操作平均所需的时间=[Δwr_ticks/Δwr_ios]

不仅包括硬盘设备写操作的时间













，还包括了在kernel队列中等待的时间 




 




 




。%util：该硬盘设备的繁忙比率=[Δio_ticks/Δt]

表示该设备有I/O（即非空闲）的时间比率    
    
    
，不考虑I/O有多少 


     


     


   ，只考虑有没有

   

   

  。svctm：已被废弃的指标

 




 




 

，没什么意义   

   

   

，svctm=[util/tput]

对iostat(1)的恰当解读有助于正确地分析问题  

     

     

  ，我们结合实际案例进一步讨论     

     

     
。

关于rrqm/s和wrqm/s

前面讲过


  




  




  
，如果两个I/O操作发生在相邻的数据块时  


  


  


，它们可以被合并成一个   
     
     
 ，以提高效率



   




   




   ，合并的操作通常是I/O scheduler（也叫elevator）负责的  




  




  




。

以下案例对许多硬盘设备执行同样的压力测试 



 



 



，结果惟有sdb比其它硬盘都更快一些              ，可是硬盘型号都一样




    




    




    ，为什么sdb的表现不一样？

可以看到其它硬盘的rrqm/s都为0













，而sdb不是               ，就是说发生了I/O合并



     



     



    ，所以效率更高













，r/s和rMB/s都更高    
    
    
，我们知道I/O合并是内核的I/O scheduler（elevator）负责的 


     


     


   ，于是检查了sdb的/sys/block/sdb/queue/scheduler

 




 




 

，发现它与别的硬盘用了不同的I/O scheduler   

   

   

，所以表现也不一样


  


  


 。

%util与硬盘设备饱和度

%util表示该设备有I/O（即非空闲）的时间比率  

     

     

  ，不考虑I/O有多少


  




  




  
，只考虑有没有     
     
     。由于现代硬盘设备都有并行处理多个I/O请求的能力  


  


  


，所以%util即使达到100%也不意味着设备饱和了   




   




   




。举个简化的例子：某硬盘处理单个I/O需要0.1秒   
     
     
 ，有能力同时处理10个I/O请求



   




   




   ，那么当10个I/O请求依次顺序提交的时候 



 



 



，需要1秒才能全部完成              ，在1秒的采样周期里%util达到100%；而如果10个I/O请求一次性提交的话




    




    




    ，0.1秒就全部完成













，在1秒的采样周期里%util只有10%



 



 



。可见               ，即使%util高达100%



     



     



    ，硬盘也仍然有可能还有余力处理更多的I/O请求













，即没有达到饱和状态               。那么iostat(1)有没有哪个指标可以衡量硬盘设备的饱和程度呢？很遗憾    
    
    
，没有    




    




    



。

await多大才算有问题

await是单个I/O所消耗的时间 


     


     


   ，包括硬盘设备处理I/O的时间和I/O请求在kernel队列中等待的时间

 




 




 

，正常情况下队列等待时间可以忽略不计   

   

   

，姑且把await当作衡量硬盘速度的指标吧  

     

     

  ，那么多大算是正常呢？

对于SSD


  




  




  
，从0.0x毫秒到1.x毫秒不等  


  


  


，具体看产品手册；

对于机械硬盘   
     
     
 ，可以参考以下文档中的计算方法：

http://101.96.10.61/cseweb.ucsd.edu/classes/wi01/cse102/sol2.pdf

大致来说一万转的机械硬盘是8.38毫秒



   




   




   ，包括寻道时间     

     

     
、旋转延迟  




  




  




、传输时间














。

在实践中 



 



 



，要根据应用场景来判断await是否正常              ，如果I/O模式很随机


  


  


 、I/O负载比较高




    




    




    ，会导致磁头乱跑













，寻道时间长               ，那么相应地await要估算得大一些；如果I/O模式是顺序读写



     



     



    ，只有单一进程产生I/O负载













，那么寻道时间和旋转延迟都可以忽略不计    
    
    
，主要考虑传输时间 


     


     


   ，相应地await就应该很小

 




 




 

，甚至不到1毫秒              。在以下实例中   

   

   

，await是7.50毫秒  

     

     

  ，似乎并不大


  




  




  
，但考虑到这是一个dd测试  


  


  


，属于顺序读操作   
     
     
 ，而且只有单一任务在该硬盘上



   




   




   ，这里的await应该不到1毫秒才算正常：

对磁盘阵列来说 



 



 



，因为有硬件缓存              ，写操作不等落盘就算完成




    




    




    ，所以写操作的service time大大加快了













，如果磁盘阵列的写操作不在一两个毫秒以内就算慢的了；读操作则未必               ，不在缓存中的数据仍然需要读取物理硬盘



     



     



    ，单个小数据块的读取速度跟单盘差不多