contagem de segmentos mysql

Question

Nós temos um aplicativo da web que usa o apache e o mysql. Geralmente (de acordo com Munin) nossa contagem de threads do MySQL fica entre 2 e 4 em todos os momentos. No outro dia, nosso servidor quase parou. As requisições HTTP eram lentas ou não passavam, o SSH funcionava, mas demorava mais de 30 segundos para registrar as teclas digitadas, etc. Então, puxamos o Munin e a única coisa que está fora dos limites normais é a contagem de threads do Mysql. O uso da CPU estava abaixo de 1%, a carga estava abaixo de 1,0, muita RAM disponível.

Como mencionado anteriormente, a contagem de threads flutua em torno de 2 a 4. Na época de nossa desaceleração, ela havia aumentado para 14. Então, começo a bisbilhotar a Internet e vejo que, na maioria dos casos, você começará a ver uma contagem de encadeamentos maior quando você começa a executar consultas lentas. Se eu entendi corretamente, o pedido vem em que demora um pouco para processar, no momento em que outras solicitações estão chegando, então um novo segmento será criado para trabalhar na solicitação (sim?). Mas no momento da desaceleração, tivemos 0 consultas lentas.

Minha pergunta é: O que mais pode fazer com que o mysql crie threads adicionais. E esse aumento súbito nos threads possivelmente faria com que o servidor diminuísse? Para corrigir o problema, reiniciámos o apache e tudo voltou ao seu estado normal. Considerando os Vitals dos Servidores (CPU, RAM, Rede, etc) eram todos ideais, e a contagem de threads era a única coisa fora do lugar, isso parece ser a coisa mais lógica a ser considerada como causa possível.

Se for importante, estamos no Mysql 5.1.40. O servidor é o FreeBSD 7.2 e o servidor em questão está dentro de uma cadeia.

    

Answer 1

Dependendo do que o Apache está fazendo, muitos pedidos simultâneos para o Apache podem causar isso. Por exemplo, um CMS grande e desconfortável pode abrir uma conexão do MySQL no início, levar muito tempo para gerar uma página e não fechar a conexão até que ela termine.

FWIW, descobri que a pesquisa periódica das conexões atuais geralmente não mostra a imagem real. Você deve analisar max_used_connections . Infelizmente, esse valor é difícil de gerenciar:

Quando isso acontecer, dê uma olhada na saída de SHOW FULL PROCESSLIST; Veja se há muitos processos no estado de suspensão. Há pelo menos um bug que pode causar o travamento do MySQL em SHOW VARIABLES .

    

Answer 2

Em vez de usar:

mysql -e "show global status"|grep -i threads_connected

ou lsof

você pode considerar usar o procfs com utilitários comuns do GNU / Linux:

find /proc/'pidof mysqld'/fd/ -follow -type s | wc -l

    

Answer 3

Estou atrasado para a festa, mas resolvi um problema semelhante recentemente. Se você estiver usando o mecanismo de armazenamento MyISAM e houver uma operação de gravação, todas as outras solicitações de leitura terão que esperar até que o bloqueio no nível da tabela seja liberado. Se a consulta abranger várias tabelas, haverá duas complicações: 1. os resultados unidos não caberão todos na memória, e uma classificação de arquivo será chamada, o que significa mais E / S de disco. e 2. mais tabelas são bloqueadas, portanto, as consultas de leitura têm maior probabilidade de serem enfileiradas. Na maioria dos casos, o MySQL terminará a gravação e as leituras serão apagadas. Se o sistema operacional falhar ao liberar o bloqueio de um arquivo (isso acontece com mais frequência do que você esperaria), o encadeamento do MySQL ficará preso.