Como investigar o pico na taxa de transferência do MySQL?

3

Recentemente, um dos nossos servidores ficou sem memória e caiu. Depois de analisar os gráficos munin , parece que a única métrica (diferente do uso da memória) que atingiu o pico logo antes da falha foi o MySQL throughput . No entanto, esperávamos ver um aumento correspondente no número de MySQL queries , o que não aconteceu:

Além do gráfico abaixo, você pode ver que MySQL throughput atingiu um valor anormalmente alto, nem de perto nenhum outro valor alcançado anteriormente:

Estamoscompletamentenoescurosobrecomodevemosproceder,daíaperguntaabaixo:

Comorealizarumainvestigação"pós-morte" de um aumento no rendimento do MySQL?

    
por Max 19.04.2012 / 12:05

1 resposta

2

Uma consulta com um enorme conjunto de resultados causaria um pico semelhante sem ver um aumento correspondente na quantidade de consultas. Você tem algum monitoramento de E / S de disco? Deve haver um grande pico nisso também, se isso foi causado por uma consulta.

Infelizmente, um exame pós-morte é difícil sem general_log ativado. O log de erros não mostrará as consultas executadas com sucesso.

Indo adiante, o que eu fiz para tentar capturar esses problemas é manter uma janela de logs de consulta. Ative o general_log e configure o logrotate para manter um breve histórico de consultas. Se o desempenho for muito intenso, você também pode tentar usar uma ferramenta como o mk-query-digest junto com o tcpdump para capturar consultas.

    
por 27.04.2012 / 20:40