在3Ware 9650SE上IO任务容易相互饥饿

Question

我有一个服务器(Debian6LTS)与一个3Ware 9650 SE RAID控制器。有两个数组，一个RAID1，一个RAID6。它运行Xen 4.0，大约有18个DomUs。问题是，我的经验是IO任务很容易让彼此挨饿。当一个DomU生成大量IO，一次阻塞其他DomU几分钟，但在dd'ing时也会发生这种情况。

为了将DomU从繁忙的RAID数组中移出，我使用了dd。在这样做时，不仅我的Nagios报告其他VM没有响应，我还在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

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

我给了Dom0 10000的信誉，因为它需要一个更高的重量来服务所有DomU's的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的机器的性能要好得多。

我希望任何人都能启发我。

Answer 1

结果，我问了一个关于要更改计划设置的设备的相关问题，答案就出来了。长话短说，由于某种原因，这个服务器将其设备配置为多路径，这意味着您不会更改/dev/sdc上的调度程序，而是在/dev/dm-1上(在我的例子中)。结果本身就说明了，机器不再互相困扰：

事实上，对于共享存储上的虚拟机，最后期限调度程序比CFQ工作得好得多。