Eu tenho um servidor (Debian 6 LTS) com um controlador RAID 3Ware 9650 SE. Existem dois arrays, um RAID1, um RAID6. Ele roda Xen 4.0, com cerca de 18 DomUs. O problema é que eu percebi que as tarefas de IO facilmente matam umas às outras. Acontece quando um DomU gera muitos IO, bloqueando os outros por alguns minutos, mas também aconteceu durante ddo 'ing.
Para mover um DomU de uma matriz RAID ocupada, usei dd. Ao fazer isso, meu Nagios não apenas relatou que outras VMs não respondiam, mas também recebi este aviso no 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
Eu tentei agendadores de prazo e cfq. Com o CFQ, não torna um DomU mais responsivo se eu definir os blkbackprocessos de back-end para prioridade de E/S em tempo real.
Dei ao Dom0 um sched-cred de 10000, pois ele precisa de um peso maior para atender todos os IO dos DomU's (e no meu caso não faz muito mais). Mas o que quer que eu defina, não deve influenciar o ddcomando e o kdmflushbloqueado, já que é tudo Dom0.
Esta é a tw_clisaída (apenas tinha um disco quebrado, daí a inicialização. Não está relacionado, porque o problema existe há muito tempo):
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
Eu realmente acho isso bizarro e irritante. Tenho a sensação de que isso é uma peculiaridade do controlador RAID. Outras máquinas com RAID por software têm um desempenho muito melhor.
Espero que alguém possa me esclarecer.
A resposta acabou sendo a resposta a uma pergunta relacionada que fiz sobre qual dispositivo alterar as configurações de agendamento . Para encurtar a história, este servidor tem seus dispositivos configurados como multipath por algum motivo, e isso significa que você não altera o agendador em
/dev/sdc, mas em/dev/dm-1(no meu caso). Os resultados falam por si, as máquinas já não incomodam umas às outras:De fato, o agendador de prazo funciona muito melhor do que o CFQ para máquinas virtuais em armazenamento compartilhado.