Recentemente, um de nossos servidores ficou sem memória e travou. Depois de revisar os muningráficos, parece que a única métrica (além do uso de memória) que atingiu o pico pouco antes da falha foi o MySQL throughput. No entanto, esperávamos ver um aumento correspondente no número MySQL queries, o que não aconteceu:
Gostaríamos de descobrir o que causou esse pico na taxa de transferência do MySQL. Aqui está a lista de logs do bin da falha:
101M Apr 17 01:27 drupal_master-bin.001270
106M Apr 17 03:00 drupal_master-bin.001271
101M Apr 17 04:05 drupal_master-bin.001272
104M Apr 17 05:53 drupal_master-bin.001273
104M Apr 17 06:39 drupal_master-bin.001274
101M Apr 17 07:02 drupal_master-bin.001275
104M Apr 17 07:22 drupal_master-bin.001276 # 100M filled up in 1 min
106M Apr 17 07:23 drupal_master-bin.001277
101M Apr 17 07:33 drupal_master-bin.001278
101M Apr 17 07:43 drupal_master-bin.001279
104M Apr 17 07:46 drupal_master-bin.001280
102M Apr 17 08:29 drupal_master-bin.001281
102M Apr 17 08:46 drupal_master-bin.001282
105M Apr 17 08:54 drupal_master-bin.001283
13M Apr 17 09:26 drupal_master-bin.001284 # crash of server around 09:50
# prior to crashing load went very high (we saw 45) and server was extremely slow (few min delay when typing in an SSH session)
101M Apr 17 10:54 drupal_master-bin.001285 # server up again, nothing wrong since then
Eu tenho procurado ferramentas para analisar esses logs bin. Até agora encontrei:
binlog-analyze.pl : me dá uma visão geral das consultas processadas, com detalhamento em select, insert, update.. (para sua informação, substituí select intopor selectno script, pois parecia errado).
$ mysqlbinlog /path/to/bin.log | binlog-analyze.pl -v
pt-query-digest : fornece estatísticas sobre o tamanho da consulta (min, max, avg...). Esse utilitário tem muitas opções, mas não sei o que procurar.
$ mysqlbinlog /path/to/bin.log | pt-query-digest
O que gostaríamos de descobrir é quais consultas geraram o aumento na saída do MySQL.
Alguém pode dar instruções sobre como revisar os logs bin do MySQL para identificar consultas que geram um aumento repentino na taxa de transferência do MySQL?
A análise de binlogs pode não fornecer uma imagem precisa porque os binlogs contêm consultas que foram concluídas e são inseridas nos logs binários como uma fila FIFO.
O que você realmente precisa procurar é a aparência do histograma de consultas em execução ativa. Em outras palavras, você precisa pegar a processlist no ato de revelar quais consultas e como era o desempenho quando as circunstâncias únicas surgiram.
Eu recomendo usar o pt-query-digest, mas você precisa usá-lo de maneira diferente. Em vez de fazer com que o resumo da consulta processe as entradas do log binário, processe a lista de processos AO VIVO !!!
Escrevi uma postagem anterior (24 de novembro de 2011) sobre como usar o pt-query-digest (minha postagem usa mk-query-digest ) como um substituto para o log de consulta lento (postei o script real que usei mais como para ler a saída do resumo da consulta): Efeitos de desempenho do log de consulta geral do MySQL . Meu post anterior foi baseado em um vídeo do YouTube mostrando como fazê-lo . Eu simplesmente me imitei usando mk-query-digest .
Você proibiu a troca? Caso contrário, o MySQL ficará lento (miseravelmente), mas não travará. A troca deve ser evitada, mas não evitada.
Você tem alguns afinadores muito altos? Consulte http://mysql.rjweb.org/doc.php/memory