☰

在 3Ware 9650SE 上，IO 任务很容易互相耗尽

tag-icon • tag-icon linux io 3ware
在 3Ware 9650SE 上，IO 任务很容易互相耗尽

我有一台服务器（Debian 6 LTS），带有 3Ware 9650 SE RAID 控制器。有两个阵列，一个 RAID1，一个 RAID6。它运行 Xen 4.0，大约有 18 个 DomU。问题是我发现 IO 任务很容易互相饿死。当一个 DomU 生成大量 IO 时会发生这种情况，每次会阻塞其他 DomU 几分钟，但它也只是在dd运行时发生。

为了将 DomU 从繁忙的 RAID 阵列中移出，我使用了 dd。执行此操作时，我的 Nagios 不仅报告其他虚拟机无响应，而且我在 Dom0 上收到此通知：

[2015-01-14 00:38:07]  INFO: task kdmflush:1683 blocked for more than 120 seconds.
[2015-01-14 00:38:07]  "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
[2015-01-14 00:38:07]  kdmflush      D 0000000000000002     0  1683      2 0x00000000
[2015-01-14 00:38:07]   ffff88001fd37810 0000000000000246 ffff88001f742a00 ffff8800126c4680
[2015-01-14 00:38:07]   ffff88000217e400 00000000aae72d72 000000000000f9e0 ffff88000e65bfd8
[2015-01-14 00:38:07]   00000000000157c0 00000000000157c0 ffff880002291530 ffff880002291828
[2015-01-14 00:38:07]  Call Trace:
[2015-01-14 00:38:07]   [<ffffffff8106ce4e>] ? timekeeping_get_ns+0xe/0x2e
[2015-01-14 00:38:07]   [<ffffffff8130deb2>] ? io_schedule+0x73/0xb7
[2015-01-14 00:38:07]   [<ffffffffa0175bd6>] ? dm_wait_for_completion+0xf5/0x12a [dm_mod]
[2015-01-14 00:38:07]   [<ffffffff8104b52e>] ? default_wake_function+0x0/0x9
[2015-01-14 00:38:07]   [<ffffffffa01768c3>] ? dm_flush+0x1b/0x59 [dm_mod]
[2015-01-14 00:38:07]   [<ffffffffa01769b9>] ? dm_wq_work+0xb8/0x167 [dm_mod]
[2015-01-14 00:38:07]   [<ffffffff81062cfb>] ? worker_thread+0x188/0x21d
[2015-01-14 00:38:07]   [<ffffffffa0176901>] ? dm_wq_work+0x0/0x167 [dm_mod]
[2015-01-14 00:38:07]   [<ffffffff81066336>] ? autoremove_wake_function+0x0/0x2e
[2015-01-14 00:38:07]   [<ffffffff81062b73>] ? worker_thread+0x0/0x21d
[2015-01-14 00:38:07]   [<ffffffff81066069>] ? kthread+0x79/0x81
[2015-01-14 00:38:07]   [<ffffffff81012baa>] ? child_rip+0xa/0x20
[2015-01-14 00:38:07]   [<ffffffff81011d61>] ? int_ret_from_sys_call+0x7/0x1b
[2015-01-14 00:38:07]   [<ffffffff8101251d>] ? retint_restore_args+0x5/0x6
[2015-01-14 00:38:07]   [<ffffffff81012ba0>] ? child_rip+0x0/0x20

blkback我尝试了 deadline 和 cfq 调度程序。使用 CFQ 时，如果我将后端进程设置为实时 IO 优先级，DomU 的响应速度不会更快。

我给 Dom0 的 sched-cred 设置为 10000，因为它需要更高的权重来为 DomU 的所有 IO 提供服务（而在我的例子中，它没有做太多其他事情）。但无论我将其设置为多少，它都不会影响命令dd和kdmflush阻塞，因为那都是 Dom0。

这是tw_cli输出（刚刚有一个磁盘坏了，因此进行初始化。这无关紧要，因为问题已经存在很长时间了）：

Unit  UnitType  Status         %RCmpl  %V/I/M  Stripe  Size(GB)  Cache  AVrfy
------------------------------------------------------------------------------
u0    RAID-6    INITIALIZING   -       89%(A)  256K    5587.9    RiW    ON     
u2    RAID-1    OK             -       -       -       1862.63   RiW    ON     

VPort Status         Unit Size      Type  Phy Encl-Slot    Model
------------------------------------------------------------------------------
p1    OK             u0   1.82 TB   SATA  1   -            WDC WD2000FYYZ-01UL 
p2    OK             u0   1.82 TB   SATA  2   -            ST32000542AS        
p3    OK             u0   1.82 TB   SATA  3   -            WDC WD2002FYPS-02W3 
p4    OK             u0   1.82 TB   SATA  4   -            ST32000542AS        
p5    OK             u0   1.82 TB   SATA  5   -            WDC WD2003FYYS-02W0 
p6    OK             u2   1.82 TB   SATA  6   -            WDC WD2002FYPS-02W3 
p7    OK             u2   1.82 TB   SATA  7   -            WDC WD2002FYPS-02W3 

Name  OnlineState  BBUReady  Status    Volt     Temp     Hours  LastCapTest
---------------------------------------------------------------------------
bbu   On           Yes       OK        OK       OK       0      xx-xxx-xxxx

我觉得这确实很奇怪也很烦人。我感觉这是 RAID 控制器的一个怪癖。其他带有软件 RAID 的机器性能要好得多。

我希望有人能启发我。

答案1

答案竟然是我问过的一个相关问题的答案在哪个设备上更改调度设置。长话短说，由于某种原因，此服务器的设备配置为多路径，这意味着您不会更改 上的调度程序/dev/sdc，而是 上的/dev/dm-1（在我的情况下）。结果不言而喻，机器不再互相干扰：

在此处输入图片描述

确实，对于共享存储上的虚拟机来说，截止期限调度程序比 CFQ 效果好得多。

相关内容