Eu tenho um guest do Xen PV, rodando o Ubuntu 10.04. Eu não corro o host subjacente. Kernel é o estoque fornecido pelo Ubuntu:
Linux nephos 2.6.32-21-server #32-Ubuntu SMP Fri Apr 16 09:17:34 UTC 2010 x86_64 GNU/Linux
Os servidores da máquina como um servidor LAMP web / DB com um monte de aplicativos web perl que desenvolvemos internamente. Desde que fomos ao ar e deixamos nossos usuários perderem na máquina na segunda-feira de manhã, uma vez por dia ele entrou em um estado em que não podemos reinicializá-lo a partir da linha de comando, scripts CGI não respondem, tempos de ping disparam e até comandos como ls falham em certos diretórios (possivelmente aqueles para os quais as gravações estão pendentes).
top mostra vários processos no estado D , a maioria denominada fleet.cgi ou doc.pl , que são nossas aplicações. As tentativas para kill ou kill -9 desses processos falham silenciosamente. sudo reboot retorna, alegando que a máquina está prestes a cair, mas nunca envia a mensagem de broadcast para outros usuários do shell que está prestes a fazê-lo, nem reinicializa a máquina.
Quando a máquina começa a travar, linhas como as seguintes aparecem no syslog:
Dec 14 12:05:45 nephos kernel: [71040.150212] INFO: task mysqld:2708 blocked for more than 120 seconds.
Dec 14 12:05:45 nephos kernel: [71040.150234] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
Dec 14 12:05:45 nephos kernel: [71040.150247] mysqld D ffff880002d4dbc0 0 2708 1 0x00000000
Dec 14 12:05:45 nephos kernel: [71040.150256] ffff8800fa5e9918 0000000000000286 0000000000015bc0 0000000000015bc0
Dec 14 12:05:45 nephos kernel: [71040.150264] ffff8800ec5883c0 ffff8800fa5e9fd8 0000000000015bc0 ffff8800ec588000
Dec 14 12:05:45 nephos kernel: [71040.150272] 0000000000015bc0 ffff8800fa5e9fd8 0000000000015bc0 ffff8800ec5883c0
Dec 14 12:05:45 nephos kernel: [71040.150280] Call Trace:
Dec 14 12:05:45 nephos kernel: [71040.150309] [<ffffffff8116d1d0>] ? sync_buffer+0x0/0x50
Dec 14 12:05:45 nephos kernel: [71040.150320] [<ffffffff815555c7>] io_schedule+0x47/0x70
Dec 14 12:05:45 nephos kernel: [71040.150325] [<ffffffff8116d215>] sync_buffer+0x45/0x50
Dec 14 12:05:45 nephos kernel: [71040.150330] [<ffffffff81555a9a>] __wait_on_bit_lock+0x5a/0xc0
Dec 14 12:05:45 nephos kernel: [71040.150334] [<ffffffff8116d1d0>] ? sync_buffer+0x0/0x50
Dec 14 12:05:45 nephos kernel: [71040.150339] [<ffffffff81555b78>] out_of_line_wait_on_bit_lock+0x78/0x90
Dec 14 12:05:45 nephos kernel: [71040.150347] [<ffffffff81084fe0>] ? wake_bit_function+0x0/0x40
Dec 14 12:05:45 nephos kernel: [71040.150353] [<ffffffff8116c1e7>] ? __find_get_block_slow+0xb7/0x130
Dec 14 12:05:45 nephos kernel: [71040.150357] [<ffffffff8116d396>] __lock_buffer+0x36/0x40
Dec 14 12:05:45 nephos kernel: [71040.150365] [<ffffffff81212164>] do_get_write_access+0x554/0x5d0
Dec 14 12:05:45 nephos kernel: [71040.150369] [<ffffffff8116cb57>] ? __getblk+0x27/0x50
Dec 14 12:05:45 nephos kernel: [71040.150374] [<ffffffff81212371>] journal_get_write_access+0x31/0x50
Dec 14 12:05:45 nephos kernel: [71040.150381] [<ffffffff811c5f9d>] __ext3_journal_get_write_access+0x2d/0x60
Dec 14 12:05:45 nephos kernel: [71040.150386] [<ffffffff811b7c7b>] ext3_reserve_inode_write+0x7b/0xa0
Dec 14 12:05:45 nephos kernel: [71040.150392] [<ffffffff8155748e>] ? _spin_unlock_irqrestore+0x1e/0x30
Dec 14 12:05:45 nephos kernel: [71040.150396] [<ffffffff811b7ccb>] ext3_mark_inode_dirty+0x2b/0x50
Dec 14 12:05:45 nephos kernel: [71040.150401] [<ffffffff811b7e71>] ext3_dirty_inode+0x61/0xa0
Dec 14 12:05:45 nephos kernel: [71040.150406] [<ffffffff81165c22>] __mark_inode_dirty+0x42/0x1e0
Dec 14 12:05:45 nephos kernel: [71040.150412] [<ffffffff81159f8b>] file_update_time+0xfb/0x180
Dec 14 12:05:45 nephos kernel: [71040.150422] [<ffffffff810f5300>] __generic_file_aio_write+0x210/0x470
Dec 14 12:05:45 nephos kernel: [71040.150430] [<ffffffff8114f49d>] ? __link_path_walk+0xad/0xf80
Dec 14 12:05:45 nephos kernel: [71040.150435] [<ffffffff810f55cf>] generic_file_aio_write+0x6f/0xe0
Dec 14 12:05:45 nephos kernel: [71040.150441] [<ffffffff8114311a>] do_sync_write+0xfa/0x140
Dec 14 12:05:45 nephos kernel: [71040.150446] [<ffffffff81084fa0>] ? autoremove_wake_function+0x0/0x40
Dec 14 12:05:45 nephos kernel: [71040.150453] [<ffffffff8100f392>] ? check_events+0x12/0x20
Dec 14 12:05:45 nephos kernel: [71040.150461] [<ffffffff81250946>] ? security_file_permission+0x16/0x20
Dec 14 12:05:45 nephos kernel: [71040.150466] [<ffffffff81143418>] vfs_write+0xb8/0x1a0
Dec 14 12:05:45 nephos kernel: [71040.150470] [<ffffffff81143db2>] sys_pwrite64+0x82/0xa0
Dec 14 12:05:45 nephos kernel: [71040.150477] [<ffffffff810131b2>] system_call_fastpath+0x16/0x1b
Instalei o pacote linux-virtual do Ubuntu para garantir que eu tenha um kernel adequado instalado, mas suas dependências foram satisfeitas pelo kernel que tenho atualmente. Eu estou em uma perda, onde mais para olhar aqui realmente. Sob carga normal, nada desagradável aparece em iotop , mas igualmente não estou ciente de nenhum aumento súbito de uso que provoque a falha - dito isto, a máquina tem rodado esses aplicativos com apenas 1/2 usuários por semanas, e está falhando agora que uma dúzia de pessoas está batendo neles o dia todo.
Eu só preciso de uma máquina com melhores recursos de E / S (ou para reduzir a necessidade de meus aplicativos para o mesmo) ou isso é algo que eu posso abordar com um pouco de sintonia?
Updated 15/12/2010 23:41: Se for útil (e eu suspeito que é um detalhe crucial), o convidado está executando sob paravirtualização.
Do bugzilla do Red Hat, mais uma indicação de que desativar o irqbalance off pode ser a solução alternativa e que uma correção está em 2.6.32.22
link (comentários 81 a 91)
comentário 91 links para as notas de lançamento para 2.6.32.22 (pesquisa inline para xen)