Задачи ввода-вывода легко истощают друг друга на 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 для виртуальных машин в общем хранилище.