​ ​​ ​

​ ​

​转载请在文首保留原文出处：​​EMC​​中文支持论坛​​https://community.emc.com/go/chinese​

​ ​​ ​

​ ​

​信息传输过程中数据通常暂存于磁盘队列。实验表明，随着服务器性能的不断提高，磁盘​​I/O​​队列常常成为影响磁盘响应速度的首要瓶颈。本文以​​AIX​​系统为例，描述了​​I/O​​队列在磁盘中的工作原理、监测命令，以及如何对其进行优化以提升磁盘性能。​

​ ​

​ ​

​使用​​I/O​​队列的意义​​:​

​ ​

​ ​

​为何要对磁盘​​I/O​​进行并行处理呢？主要目的是提升应用程序的性能。这一点对于多物理磁盘组成的虚拟磁盘（或​​LUN​​）显得尤为重要。如果一次提交一个​​I/O​​，虽然响应时间较短，但系统的吞吐量很小。相比较而言，一次提交多个​​I/O​​既缩短了磁头移动距离（通过电梯算法），同时也能够提升​​IOPS​​。假如一部电梯一次只能搭乘一人，那么每个人一但乘上电梯，就能快速达到目的地（响应时间），但需要耗费较长的等待时间（队列长度）。因此一次向磁盘系统提交多个​​I/O​​能够平衡吞吐量和整体响应时间。​

​ ​

​ ​

​理论上，磁盘的​​IOPS​​取决于队列长度÷平均​​IO​​响应时间。假设队列长度为​​3​​，平均​​IO​​响应时间是​​10ms​​，则最大吞吐量是​​300 IOPS​​。​

​ ​

​ ​

​ ​

​IO​​队列位于何处：​

​ ​

​以​​AIX​​系统为例，从应用层到磁盘物理层的​​IO​​堆栈如下所示，​​IO​​按照从上至下的顺序遍历堆栈：​

​ ​

​ ​
• ​应用程序层​
​ ​
• ​文件系统层（可选）​
​ ​
• ​LVM​​设备驱动层（可选）​
​ ​
• ​SDD​​或​​SDDPCM​​或其他多路径驱动层（如果使用）​
​ ​
• ​hdisk​​设备驱动层​
​ ​
• ​adapter​​设备驱动层​
​ ​
• ​磁盘接口层​
​ ​
• ​磁盘子系统层​
​ ​
• ​磁盘层​
​ ​

​ ​

​ ​

​AIX​​在每一层堆栈都会监测​​IO​​，因​​此堆栈的每一层都有​​IO​​队列。​​通常，如果当前各层执行的​​IO超过了队列长度所限制的最大数量，这些IO将暂存于等待队列中，直至获取申请资源。在文件系统层，文件系统缓存限制了各文件系统的最大可执行IO数量。LVM设备驱动层，可执行的最大IO数量受hdisk缓存的限制。在SDD层，如果dpo设备的qdepth_enable属性设置成yes，则会建立IO队列，但也有些版本无法设置队列。SDDPCM在将IO发送至磁盘设备驱动层之前没有进行队列处理。​​hdisk通过queue_depth参数设置最大响应IO数量​​， 而FC适配层的参数为num_cmd_elems。磁盘子系统层有IO队列，单块物理磁盘可接收多个IO请求但一次只能处理一个IO。​

​ ​

​ ​

​IO​​队列监测命令：​

​ ​

​ ​

​以​​AIX​​为例，​​AIX 5.3​​及以上版本，可用​​iostat​​和​​sar –d​​命令监测​​hdisk​​队列，​​iostat -D​​命令输出如下：​

​ ​

​hdisk6 xfer: %tm_act bps tps bread bwrtn ​
​4.7 2.2M 19.0 0.0 2.2M​
​read: rps avgserv minserv maxserv timeouts fails​
​0.0 0.0 0.0 0.0 0 0​
​write: wps avgserv minserv maxserv timeouts fails​
​19.0 38.9 1.1 190.2 0 0​
​queue: avgtime ​​mintime maxtime ​​avgwqsz avgsqsz sqfull​
​15.0 0.0 83.7 0.0 0.0 136​

​ ​

​ ​

​这里，​​avgwqsz​​是平均等待队列长度，​​avgsqsz​​是平均响应队列长度。在等待队列中花费的平均等待时间是​​avgtime​​。​​sqfull​​值代表每秒钟向已满队列提交的​​IO​​数。对于有​​cache​​的磁盘子系统，​​IO​​响应时间会有所不同。​​iostat –D​​命令显示的是系统从启动后的统计数据。​

​ ​

​ ​

​从应用程序的角度来看，处理​​IO​​的总时间是响应时间加上在​​hdisk​​等待队列中的时间。​

​ ​

​sar –d​​命令输出如下：​

​ ​

​16:50:59 device %busy ​​avque​​ r+w/s Kbs/s ​​avwait avserv​
​16:51:00 hdisk1 0 0.0 0 0 0.0 0.0​
​ hdisk0 0 0.0 0 0 0.0 0.0​

​ ​

​avwait​​和​​avserv​​分别是花费在等待队列和响应队列的时间，​​avque​​在​​AIX 5.3​​以上版本中，代表等待队列中的平均​​IO​​数量。​

​ ​

​ ​

​优化方法：​

​ ​

​ ​

​首先，不应盲目增加以上队列参数值。这样有可能造成磁盘子系统过载或在启动时引起设备配置报错。​​因此，仅增加​​hdisk的queue_depths值并不是最好的方法，而应该同时调整可提交最大IO数量。当queue_depths和发送至磁盘子系统的IO数量同时增加时，IO响应时间可能会增加，但同时吞吐量也得到了提升。当IO响应时间接近磁盘超时时间，则说明所提交IO超过了磁盘能够处理的界限。如果看到IO超时并在错误日志中报出IO无法完成，说明可能有硬件问题，或需要缩短队列。​

​ ​

​ ​

​调整​​queue_depths​​的一条法则是：对于随机读写或队列未满的情况，如果​​IO​​响应时间超过​​15ms​​，就不能再增加​​queue_depths​​值。一旦​​IO​​响应时间增加，瓶颈就从磁盘和​​adapter​​队列转移至磁盘子系统。调整队列长度应依据：​​1​​）实际应用程序产生的​​IO​​请求数，​​2​​）使用测试工具以观察磁盘子系统的处理能力。其中，​​1​​）为主要依据。​

​ ​

​ ​

​IO​​队列有以下四种状态：​

​ ​

​ ​
1. ​队列已满，​​IO​​等在​​hdisk​​或​​adapter​​驱动层​
​ ​
2. ​队列未满，​​IO​​响应时间短​
​ ​
3. ​队列未满，​​IO​​响应时间长​
​ ​
4. ​队列未满，​​IO​​提交速度快于存储处理速度并导致​​IO​​丢失​
​ ​

​ ​

​ ​

​我们需要把队列调整为​​2​​或​​3​​的状态。情况​​3​​表明瓶颈不在​​hdisk​​驱动层，而很有可能在磁盘子系统自身，也有可能位于​​adapter​​驱动层或​​SAN​​。​

​ ​

​ ​

​第​​4​​种情况是应该避免的。受限于存储​​IO​​请求和数据的内存大小，所有磁盘和磁盘子系统都有​​IO​​执行数量的限制。当存储丢失​​IO​​时，主机端超时，​​IO​​将被重新提交，同时等待该​​IO​​的事件将被暂停。​​CPU​​为了处理​​IO​​多做了很多事情，这种情况应该避免。如果​​IO​​最终失败，将会导致应用程序崩溃或更严重的结果。所以必须仔细确认存储的处理极限。​

​ ​

​ ​

​ ​

​合理的平均IO响应时间：​

​ ​

​ ​

​假设队列中没有​​IO​​，一次读操作将会占据​​0​​至​​15ms​​，取决于寻址时间，磁盘转速，以及数据传输时间。之后数据从存储移动至主机。有时数据位于磁盘读缓存，这种情况下​​IO​​响应时间约为​​1ms​​。对于大型磁盘系统在正常工作状态下，平均​​IO​​响应时间约为​​5-10ms​​。当随机读取小数据耗时超过​​15ms​​时，表明存储较为繁忙。​

​ ​

​ ​

​写操作通常将数据写入​​cache​​中，平均耗时不到​​2.5ms​​。但是也有例外：如果存储同步将数据镜像至远端，写操作将耗费更长时间。如果写入数据量较大（多于​​64KB​​）则数据传输时间会显著增加。没有​​cache​​的情况下，写时间的读时间差不多。​

​ ​

​ ​

​如果​​IO​​是大块顺序读写，除了传输时间较长，​​IO​​会暂存于磁盘物理层队列，​​IO​​响应时间远高于平均值。例如：应用提交​​50​​个​​IO(50​​个​​64KB​​顺序读​​)​​，最初几个​​IO​​会获得较快的响应时间，而最后一个​​IO​​必须等待其他​​49​​个完成，从而耗费很长的响应时间。​

​ ​

​ ​​ ​

​ ​

​https://community.emc.com/docs/DOC-18970​

​ ​

​https://community.emc.com/thread/129131​

​ ​

​https://community.emc.com/thread/145929​

​ ​​ ​

​ ​

​UNIX​​系统​

​ ​

​AIX​​系统​

​ ​

​ ​

​ ​

​ ​

​ ​

​ ​

​ ​

​ ​