HDD avgqu的哪个值是关键？

Question

来自不同应用程序的这是我的HDD avgqu图.：

App在内存中缓存数据，每n分钟将数据刷新到文件系统，+每m分钟是从内存中的文件系统加载的数据(Re)。这就是尖峰的原因。在这些峰值期间，块设备利用率为80%-95%。

问:我需要担心我的磁盘性能吗？如何解释这张图--好还是不好？我需要优化一些东西吗？

• 是的，我有很高的峰值~1k，但是队列大小是~1 =>，有一天，avg是16--我不知道我是否满意这个avg值。
• 是的，我知道度量avgqu-sz是什么意思。
• 是的，我已经为高IOps优化了我的文件系统(noatime，nodirtime)

Answer 1

是的，我知道度量avggu-sz是什么意思，这意味着您知道通常数据流是这样的。

     app --> bio layer --> I/O Scheduler --> Driver --> Disks
                           nr_requests                  queue_depth

这只是一个一般性的概述，不包括everything.As，只要nr_requests仍然是queue_Depth，I/O将从这些请求超过队列深度和I/O开始在调度程序层中执行时开始传递quickly.The问题。

查看您的图表，我强烈建议1:检查具有高峰的磁盘2:尝试更改nr_requests和queue_depth的值以确定它是否有用3:在测试环境中更改调度程序(因为这里的数据不包含合并请求(读/写)..so，我不能评论)

                /sys/block/<your disk drive sda,sdb...>/queue/nr_requests (io scheduler)
                /sys/block/<your disk drive sda,sdb...>/device/queue_depth (driver)

Answer 2

平均队列大小超过1,000个请求是一个麻烦，除非您正在运行一个数组，其中包含数百个磁盘，这些磁盘都是作为一个设备公开的。

然而，从你的图表来看，我认为你的尖峰大多是测量的，或者是图形化的人工制品--你的数据看起来像是每隔5分钟收集一次，但是这些尖峰的宽度基本上是零--非常不寻常。您应该查看sar收集的原始数据或iostat在近实时显示的原始数据，以排除这种可能性。如果您仍然看到每个主轴使用的队列大小超过30个请求，请在这里检查数据。