Задачи ввода-вывода легко истощают друг друга на 3Ware 9650SE

У меня есть сервер (Debian 6 LTS) с RAID-контроллером 3Ware 9650 SE. Есть два массива, один RAID1, один RAID6. Он работает под управлением Xen 4.0, с около 18 DomU. Проблема в том, что я чувствую, что задачи ввода-вывода очень легко умирают друг от друга. Это происходит, когда один 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

Я пробовал оба крайних срока и cfq планировщики. С CFQ, это не делает DomU более отзывчивым, если я установлю blkback внутренние процессы с приоритетом ввода-вывода в реальном времени.

Я дал Dom0 кредитный балл 10000, так как он нуждается в большем весе, чтобы обслуживать все операции ввода-вывода DomU (и в моем случае больше ничего не делает). Но что бы я ни установил, это не должно влиять на 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 для виртуальных машин в общем хранилище.

Другие вопросы по тегам