不同的控制器如何解释这个 I/O?

不同的控制器如何解释这个 I/O?

我的新 NAS 有 5 个磁盘。它们都是同一型号。

sde 连接到主板上的控制器。 sda-sdd 位于 raid 控制器上。

并行运行“pv /dev/sd[cde]”:

Device       rkB/s     wkB/s f_await  aqu-sz  %util
sdc      161536.00      0.00    0.00    1.50  99.60
sdd      175104.00      0.00    0.00    1.41  98.80
sde      170880.00      0.00    0.00    1.66 100.00

这就是我所期望的。

并行运行“pv /dev/sd[ae]”:

Device       rkB/s     wkB/s f_await  aqu-sz  %util
sda      147456.00      0.00    0.00    1.15 100.00
sdb      142848.00      0.00    0.00    1.74 100.00
sdc      147840.00      0.00    0.00    1.13  99.60
sdd      149120.00      0.00    0.00    1.15  99.60
sde      107008.00      0.00    0.00    1.34  96.40

最大值从 175 MB/s 变为 150 MB/s 可能是由于它们共享总线而导致的,并且该总线具有最大总带宽。

但请注意 sde 慢了 30%。

对于 sda-​​sdd,Renice 'pv' 为 19(将 sde 的 'pv' 保持为 0):

Device       rkB/s     wkB/s f_await  aqu-sz  %util
sda      137856.00      0.00    0.00    1.04  98.00
sdb      140032.00      0.00    0.00    1.06  99.20
sdc      132480.00      0.00    0.00    1.00  98.80
sdd      132608.00      0.00    0.00    1.02  97.60
sde      140672.00      0.00    0.00    1.73 100.00

请注意 sde 现在与其他的处于同一水平。这是我在正常情况下所期望的(没有重新调整)。

在空闲系统上,每个驱动器每秒搜索 80 次(如预期):

# parallel --tag -j0 -k --ll seekmaniac ::: /dev/sd[a-e]
/dev/sda        / 81 seeks per second           
/dev/sdb        / 81 seeks per second           
/dev/sdc        / 80 seeks per second           
/dev/sdd        / 81 seeks per second           
/dev/sde        / 82 seeks per second           

当“pv”运行时(如上所述):

# parallel --tag -j0 -k --ll seekmaniac ::: /dev/sd[a-e]
/dev/sda        o 15 seeks per second           
/dev/sdb        o 13 seeks per second           
/dev/sdc        o 15 seeks per second           
/dev/sdd        o 19 seeks per second           
/dev/sde        o 64 seeks per second           

请注意 sde 如何比其他的提供更多的搜索。

我认为此行为是由于 sde 在不同的控制器上造成的。

但控制器如何才能达到这样的效果呢?

如何解释这种行为?

编辑

搜索我发现的差异(sda=sdb=sdc=sdd):

# diff <(cd /sys/block/sde/; grep . queue/*) <(cd /sys/block/sda/; grep . queue/*) 
19c19
< queue/max_segments:64
---
> queue/max_segments:168
23c23
< queue/nr_requests:2
---
> queue/nr_requests:64
34c34
< queue/write_cache:write through
---
> queue/write_cache:write back

当我所做的只是读取时,写入缓存不太可能相关。

答案1

这只是一个猜测。我希望有人能够证明或反驳这个猜测。

sde 控制器的 max_segments=64 和 nr_requests=2。

sda 控制器的 max_segments=168 和 nr_requests=64。

假设CPU从sde获取数据的工作量更大:如果队列容量较小,CPU将不得不不断清空队列,而容量较大的队列则只需定期清空。

如果 CPU 错过了清空队列的机会,队列就会满,磁盘就会停止运行。如果队列容量较小,这种情况平均会更频繁地发生。

NAS 中的 CPU 是低端、速度慢的 CPU。

也许这可以解释读取性能 30% 的差异。

搜索的差异是否也可以用类似的推理来解释?

如果队列容量较低,CPU 将更快地发现可以调度新的查找。如果容量较高,CPU 在发现可以调度新的查找之前必须先清空队列。

再说一遍:我显然已经陷入了困境。老实说,我不知道这是否是正在发生的事情。

相关内容