IO队列深度max_queue_depth对系统性能的影响

通常在信息传输过程中将数据临时存储在磁盘队列中. 实验表明，随着服务器性能的不断提高，磁盘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从上到下依次遍历该堆栈:

AIX在堆栈的每一层监视IO，因此堆栈的每一层都有一个IO队列. 通常，如果每个层执行的当前IO超过了队列长度所限制的最大数量，则这些IO将被临时存储在等待队列中，直到获得请求的资源为止. 在文件系统层，文件系统缓存限制了每个文件系统的最大可执行IO数. 在LVM设备驱动程序层中，可执行IO的最大数量受hdisk缓存限制. 在SDD层上，如果dpo设备的qdepth_enable属性设置为yes，将建立IO队列，但是某些版本无法设置该队列. 在将IO发送到磁盘设备驱动程序层之前，SDDPCM不会执行队列处理. 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面包bwrtn

4.7 2.2M 19.0 0.0 2.2M

读取: rps avgserv minserv maxserv超时失败

0.0 0.0 0.0 0.0 0.0 0 0

写入: wps avgserv minserv maxserv超时失败

19.0 38.9 1.1 190.2 0 0

队列: avgtime最小时间maxtime avgwqsz avgsqsz sqfull

15.0 0.0 83.7 0.0 0.0 136

在这里，avgwqsz是平均等待队列长度，而avgsqsz是平均响应队列长度. 在等待队列中花费的平均等待时间为avgtime. sqfull值表示每秒提交到完整队列的IO数量. 对于具有缓存的磁盘子系统，IO响应时间将有所不同. iostat -D命令在系统启动后显示统计数据.

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

sar -d命令输出如下:

16:50:59设备％忙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 0.0

avwait和avserv是分别在等待队列和响应队列中花费的时间. 在aix 5.3及更高版本中，avque表示等待队列中的IO的平均数量.

优化方法:

首先，您不应盲目增加上述队列参数值. 这可能会使磁盘子系统过载，或者在启动过程中导致设备配置错误. 因此，仅增加hdisk的queue_depths值不是最佳方法，而应调整可同时提交的最大IO数. 当queue_depths和发送到磁盘子系统的IO数量同时增加时，IO响应时间可能会增加，但同时吞吐量也会提高. 当IO响应时间接近磁盘超时时间时，这意味着提交的IO超出了磁盘可以处理的限制. 如果看到IO超时并在错误日志中报告IO无法完成，则可能是硬件问题或需要缩短队列.

一个调整queue_depths的规则是，对于随机读写或当队列未满时，如果IO响应时间超过15ms，则不能增加queue_depths的值. 一旦IO响应时间增加，瓶颈就会从磁盘和适配器队列转移到磁盘子系统. 队列长度的调整应基于: 1）实际应用程序生成的IO请求数，以及2）使用测试工具观察磁盘子系统的处理能力. 其中，1）是主要依据.

IO队列具有以下四个状态:

队列已满，IO在hdisk或适配器驱动程序层中等待，队列未满，IO响应时间短，队列未满，IO响应时间长，队列未满， IO提交速度快于存储处理速度，并导致IO丢失

我们需要将队列调整为2或3. 情况3显示瓶颈不在hdisk驱动程序层中，而可能在磁盘子系统本身中，或者可能位于适配器驱动程序层中，或者SAN.

应避免第四种情况. 受用于存储IO请求和数据的内存大小的限制，所有磁盘和磁盘子系统都对IO执行次数有限制. 当存储丢失IO时，主机将超时，该IO将被重新提交，并且等待IO的事件将被挂起. CPU为了处理IO做很多事情，这种情况应该避免. 如果IO最终失败，它将导致应用程序崩溃或产生更严重的后果. 因此，必须仔细确认存储的处理限制.

合理的平均IO响应时间:

假设队列中没有IO，则读取操作将占用0到15ms，具体取决于寻址时间，磁盘速度和数据传输时间. 然后将数据从存储移动到主机. 有时数据在磁盘读取缓存中，在这种情况下，IO响应时间约为1ms. 对于在正常工作条件下的大型磁盘系统，平均IO响应时间约为5-10ms. 当小数据的随机读取时间超过15ms时，表明存储忙.

写入操作通常将数据写入缓存，平均时间少于2.5毫秒. 但也有例外: 如果存储将数据镜像到远程端，则写操作将花费更长的时间. 如果写入的数据量很大（超过64KB），则数据传输时间将大大增加. 没有缓存磁盘队列深度，写入时间的读取时间大约相同.

如果IO是按大块顺序读取和写入的，则除了需要更长的传输时间外磁盘队列深度，该IO还将被临时存储在磁盘物理层队列中，并且IO的响应时间比平均时间长得多. 例如: 应用程序提交了50个IO（50个64KB顺序读取），前几个IO将获得更快的响应时间，而最后一个IO必须等待其他IO完成，这需要很长的响应时间.

（2）

本文来自电脑杂谈，转载请注明本文网址：
http://www.pc-fly.com/a/jisuanjixue/article-259813-1.html