o disco trava durante a E / S ativa

3

Eu tenho o sistema operacional convidado XenServer (Ubuntu 10.10 lts) e ter um problema com a cópia enorme quantidade de arquivos do nfs para o disco local (cp -rp nfs: / dir / local / dir). Depois de algum tempo, o disco local trava e não consigo executar nenhuma operação de IO. nos arquivos de log eu vejo isso:

Oct 28 19:13:21 ls0 kernel: [1947885.457070] INFO: task cp:3904 blocked for more than 120 seconds.
Oct 28 19:13:21 ls0 kernel: [1947885.457075] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
Oct 28 19:13:21 ls0 kernel: [1947885.457081] cp            D ffff88002804dbc0     0  3904   2052 0x00000000
Oct 28 19:13:21 ls0 kernel: [1947885.457085]  ffff880273a91ae8 0000000000000286 0000000000015bc0 0000000000015bc0
Oct 28 19:13:21 ls0 kernel: [1947885.457090]  ffff880141bf4890 ffff880273a91fd8 0000000000015bc0 ffff880141bf44d0
Oct 28 19:13:21 ls0 kernel: [1947885.457095]  0000000000015bc0 ffff880273a91fd8 0000000000015bc0 ffff880141bf4890
Oct 28 19:13:21 ls0 kernel: [1947885.457099] Call Trace:
Oct 28 19:13:21 ls0 kernel: [1947885.457103]  [<ffffffff8121adcd>] do_get_write_access+0x31d/0x5e0
Oct 28 19:13:21 ls0 kernel: [1947885.457107]  [<ffffffff8100eb6d>] ? xen_force_evtchn_callback+0xd/0x10
Oct 28 19:13:21 ls0 kernel: [1947885.457110]  [<ffffffff8100f302>] ? check_events+0x12/0x20
Oct 28 19:13:21 ls0 kernel: [1947885.457113]  [<ffffffff810845c0>] ? wake_bit_function+0x0/0x40
Oct 28 19:13:21 ls0 kernel: [1947885.457117]  [<ffffffff8121b221>] jbd2_journal_get_write_access+0x31/0x50
Oct 28 19:13:21 ls0 kernel: [1947885.457121]  [<ffffffff81202388>] __ext4_journal_get_write_access+0x38/0x70
Oct 28 19:13:21 ls0 kernel: [1947885.457125]  [<ffffffff811d9004>] ext4_new_inode+0x234/0xb40
Oct 28 19:13:21 ls0 kernel: [1947885.457128]  [<ffffffff811f7908>] ? ext4_journal_start_sb+0xf8/0x130
Oct 28 19:13:21 ls0 kernel: [1947885.457132]  [<ffffffff811e6e40>] ext4_create+0xc0/0x150
Oct 28 19:13:21 ls0 kernel: [1947885.457137]  [<ffffffff8114ca63>] ? generic_permission+0x23/0xc0
Oct 28 19:13:21 ls0 kernel: [1947885.457141]  [<ffffffff8114e4f4>] vfs_create+0xb4/0xe0
Oct 28 19:13:21 ls0 kernel: [1947885.457144]  [<ffffffff8114e5e4>] __open_namei_create+0xc4/0x110
Oct 28 19:13:21 ls0 kernel: [1947885.457148]  [<ffffffff81151d8b>] do_filp_open+0xa6b/0xba0
Oct 28 19:13:21 ls0 kernel: [1947885.457162]  [<ffffffffa0084b3b>] ? nfs_attribute_timeout+0x1b/0x70 [nfs]
Oct 28 19:13:21 ls0 kernel: [1947885.457170]  [<ffffffffa0085fe6>] ? nfs_revalidate_inode+0x26/0x60 [nfs]
Oct 28 19:13:21 ls0 kernel: [1947885.457174]  [<ffffffff8114d80b>] ? getname+0x3b/0x240
Oct 28 19:13:21 ls0 kernel: [1947885.457178]  [<ffffffff8115d17a>] ? alloc_fd+0x10a/0x150
Oct 28 19:13:21 ls0 kernel: [1947885.457182]  [<ffffffff81140d99>] do_sys_open+0x69/0x170
Oct 28 19:13:21 ls0 kernel: [1947885.457185]  [<ffffffff81140ee0>] sys_open+0x20/0x30
Oct 28 19:13:21 ls0 kernel: [1947885.457189]  [<ffffffff810121b2>] system_call_fastpath+0x16/0x1b
A tarefa

pode ser "flush-202" "jbd2 / xvdc1-8" ... qualquer coisa envolvida nesta operação de cópia

Eu tentei alterar o agendador de IO (para o prazo), vm.dirty_ratio e vm.dirty_background_ratio. Nada ajuda

agora meu servidor tem um disco travado e posso executar alguma investigação:

~# grep -A 1 dirty /proc/vmstat 
nr_dirty 9598
nr_writeback 0

# vmstat 1
procs -----------memory---------- ---swap-- -----io---- -system-- ----cpu----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa
 0  1      0 3221016 301536 5558968    0    0     0    26   25   19  0  0 88 12
 0  1      0 3221008 301536 5558968    0    0     0     0   47   22  0  0 85 15
 0  1      0 3221008 301536 5558968    0    0     0     0   17   13  0  0 63 37
 0  1      0 3221008 301536 5558968    0    0     0     0   16   17  0  0 100  0
 0  1      0 3221008 301536 5558968    0    0     0     0   34   28  0  0 100  0
 0  1      0 3221008 301536 5558968    0    0     0     0   15   12  0  0 100  0
 0  1      0 3221008 301536 5558968    0    0     0     0   14   14  0  0 39 61
 0  1      0 3221008 301536 5558968    0    0     0     0   21   22  0  0 100  0
 0  1      0 3221008 301536 5558968    0    0     0     0   15   16  0  0 100  0




~# iostat -xm 1| grep xvdc
xvdc              0.02   519.33    0.03   53.36     0.00     0.40    15.21    28.55    8.22  17.60  93.98
xvdc              0.00     0.00    0.00    0.00     0.00     0.00     0.00    30.00    0.00   0.00 100.00
xvdc              0.00     0.00    0.00    0.00     0.00     0.00     0.00    30.00    0.00   0.00 100.00
xvdc              0.00     0.00    0.00    0.00     0.00     0.00     0.00    30.00    0.00   0.00 100.00
xvdc              0.00     0.00    0.00    0.00     0.00     0.00     0.00    30.00    0.00   0.00 100.00
xvdc              0.00     0.00    0.00    0.00     0.00     0.00     0.00    30.00    0.00   0.00 100.00
xvdc              0.00     0.00    0.00    0.00     0.00     0.00     0.00    30.00    0.00   0.00 100.00
xvdc              0.00     0.00    0.00    0.00     0.00     0.00     0.00    30.00    0.00   0.00 100.00

e há um gráfico de memória link

    
por A M 29.10.2010 / 07:30

2 respostas

2

A operação de cópia fica pendurada no mesmo arquivo / diretório todas as vezes?

Você tentou usar rsync em vez de cp ? Isso pode parecer estúpido, mas algumas vezes consegui copiar arquivos em situação semelhante. Eu não sei porque o PC pode fazer tudo parar ...

Outro culpado pode ser a combinação ext4 + nfs.

    
por 29.10.2010 / 09:24
0

poderia ser o seu hardware falhando. Você verificou valores SMART da unidade? Faça um teste bonnie ++ local ou apenas dd do disco para /dev/null .

    
por 29.10.2010 / 08:47