thread do MySQL fica preso no estado final

3

Um dos nossos servidores de produção mestre de replicação está mostrando um comportamento muito estranho para o qual não consigo encontrar uma solução.

Alguns threads neste servidor ficam presos no estado 'end'. Isso acontece puramente aleatório, mas quando isso ocorre, o thread está sempre atualizando ou inserindo linhas em uma tabela. As tabelas nas quais a consulta está sendo executada são diferentes, mas estão sempre em tabelas MyISAM e em um intervalo de três tabelas diferentes.

Quando um encadeamento entra no estado final, todos os outros encadeamentos ficam com status bloqueado. E quando eu digo todos os tópicos, quero dizer tudo, até mesmo segmentos que não estão consultando o mesmo banco de dados ou tabela.

Os servidores da Web mantêm as consultas de enfileiramento no servidor de banco de dados sem obter uma resposta. Isso basicamente faz com que os servidores da web fiquem sem soquetes. Nesse momento, todos os pedidos para os domínios são negados. Os servidores de banco de dados não mostram nenhuma atividade de E / S ou processador durante o tempo em que o encadeamento está no estado 'final'. Quando esse problema ocorre, eu tenho que matar o thread manualmente. Mesmo isso não faz outra coisa que o seu status de comando mude para 'morto'. A maioria dos tópicos desaparecem após cerca de 100 segundos.

As tabelas nas quais os encadeamentos estão executando consultas quando elas vão no estado final variam em tamanho, mas são em torno de 20 a 100 MB. No momento em que esses problemas ocorrem, essas tabelas são atualizadas freqüentemente, mas não de maneiras extremas. Eu acho que as atualizações variam de 3 a 10 por segundo.

Algumas especificações sobre o servidor. O sistema operacional é o CentOS 5.4 com o MySQL 5.0.77-log. O processador é um AMD Opteron 2378, os discos rígidos são um conjunto RAID 1 + 0 de SSDs Corsair X32 de 32GB.

Estou pensando que os SSDs podem fazer parte da causa do problema, mas não consigo encontrar nenhum dado para confirmar isso. As unidades se apresentaram bastante estáveis por um tempo.

Eu li a documentação no guia de referência do MySQL sobre o General Thread States, que diz que durante o estado final o log binário e o cache de consulta são atualizados. Talvez isso tenha algo a ver com a causa do problema? Eu não diria quais diretivas de configuração poderiam fornecer uma solução de trabalho.

Eu não tentei desabilitar o cache de consulta e não consigo desativar a replicação, pois esse é um servidor de produção em execução. O fato de que este é um servidor de produção em execução faz com que eu seja cuidadoso ao alterar parâmetros, como as configurações de cache de consulta, a menos que eu tenha certeza de que isso resolverá o problema.

Eu não consegui reproduzir o problema com alguns dos meus scripts de teste. Ao ler, escrever e atualizar as tabelas que causam os problemas pesados, o problema não ocorre. A ocorrência deste problema é puramente aleatória.

    
por Reinoud van Santen 31.08.2010 / 13:43

1 resposta

2

Após uma investigação mais aprofundada, pareceu que foi o cache de consulta que causou o problema. Devido a um grande cache de consultas, o MySQL parece ficar confuso ao limpar o cache. Reduzir o cache de consultas de alguns GB para cerca de 512 MB resolveu o problema. Para informações detalhadas, consulte: link

    
por 07.09.2010 / 15:16

Tags