Consultas/instruções/transações de longa duração são às vezes inevitáveis em um ambiente MySQL. Em algumas ocasiões, uma consulta de longa duração pode ser um catalisador para um evento desastroso. Se você se preocupa com seu banco de dados, a otimização do desempenho da consulta e a detecção de consultas de longa duração devem ser realizadas regularmente. As coisas ficam mais difíceis quando várias instâncias em um grupo ou cluster estão envolvidas.
Ao lidar com vários nós, as tarefas repetitivas para verificar cada nó é algo que devemos evitar. O ClusterControl monitora vários aspectos do seu servidor de banco de dados, incluindo consultas. O ClusterControl agrega todas as informações relacionadas à consulta de todos os nós do grupo ou cluster para fornecer uma visão centralizada da carga de trabalho. Ali está uma ótima maneira de entender seu cluster como um todo com o mínimo de esforço.
Nesta postagem do blog, mostramos como detectar consultas de longa execução do MySQL usando o ClusterControl.
Por que uma consulta demora mais?
Em primeiro lugar, temos que saber a natureza da consulta, se espera-se que seja uma consulta de longa ou curta execução. Algumas operações analíticas e em lote devem ser consultas de longa duração, portanto, podemos ignorá-las por enquanto. Além disso, dependendo do tamanho da tabela, modificar a estrutura da tabela com o comando ALTER pode ser uma operação de longa duração.
Para uma transação de curto período, ela deve ser executada o mais rápido possível, geralmente em questão de subsegundos. Quanto mais curto melhor. Isso vem com um conjunto de regras de práticas recomendadas de consulta que os usuários devem seguir, como usar a indexação adequada na instrução WHERE ou JOIN, usar o mecanismo de armazenamento correto, selecionar os tipos de dados adequados, agendar a operação em lote fora do horário de pico, descarregar análises /reporting tráfego para réplicas dedicadas e assim por diante.
Há uma série de coisas que podem fazer com que uma consulta demore mais tempo para ser executada:
- Consulta ineficiente - Use colunas não indexadas durante a pesquisa ou junção, portanto, o MySQL leva mais tempo para corresponder à condição.
- Bloqueio de tabela - A tabela é bloqueada, por bloqueio global ou bloqueio de tabela explícito quando a consulta está tentando acessá-la.
- Deadlock - Uma consulta está aguardando para acessar as mesmas linhas bloqueadas por outra consulta.
- O conjunto de dados não cabe na RAM - Se os dados do conjunto de trabalho se encaixam nesse cache, as consultas SELECT geralmente serão relativamente rápidas.
- Recursos de hardware abaixo do ideal - podem ser discos lentos, reconstrução de RAID, rede saturada etc.
- Operação de manutenção - A execução do mysqldump pode trazer grandes quantidades de dados não utilizados para o buffer pool e, ao mesmo tempo, os dados (potencialmente úteis) que já estão lá serão despejados e liberados para o disco.
A lista acima enfatiza que não é apenas a consulta em si que causa todos os tipos de problemas. Há muitas razões que exigem olhar para diferentes aspectos de um servidor MySQL. Em alguns cenários de pior caso, uma consulta de longa duração pode causar uma interrupção total do serviço, como servidor inativo, falha do servidor e conexões no limite. Se você perceber que uma consulta demora mais do que o normal para ser executada, investigue-a.
Como verificar?
LISTA DE PROCESSOS
O MySQL fornece uma série de ferramentas internas para verificar a transação de longa duração. Em primeiro lugar, os comandos SHOW PROCESSLIST ou SHOW FULL PROCESSLIST podem expor as consultas em execução em tempo real. Aqui está uma captura de tela do recurso ClusterControl Running Queries, semelhante ao comando SHOW FULL PROCESSLIST (mas ClusterControl agrega todo o processo em uma visualização para todos os nós do cluster):
Como você pode ver, podemos ver imediatamente a consulta ofensiva logo na saída. Mas com que frequência olhamos para esses processos? Isso só é útil se você estiver ciente da transação de longa duração. Caso contrário, você não saberá até que algo aconteça - como as conexões estão se acumulando ou o servidor está ficando mais lento do que o normal.
Registro de consulta lenta
O log de consultas lentas captura consultas lentas (instruções SQL que levam mais de long_query_time segundos para executar) ou consultas que não usam índices para pesquisas (log_queries_not_using_indexes ). Este recurso não está habilitado por padrão e para habilitá-lo basta configurar as seguintes linhas e reiniciar o servidor MySQL:
[mysqld]
slow_query_log=1
long_query_time=0.1
log_queries_not_using_indexes=1O log de consultas lentas pode ser usado para localizar consultas que levam muito tempo para serem executadas e, portanto, são candidatas à otimização. No entanto, examinar um log de consulta longo e lento pode ser uma tarefa demorada. Existem ferramentas para analisar arquivos de log de consultas lentas do MySQL e resumir seu conteúdo como mysqldumpslow, pt-query-digest ou ClusterControl Top Queries.
O ClusterControl Top Queries resume a consulta lenta usando dois métodos - log de consulta lenta do MySQL ou Esquema de desempenho:
Você pode ver facilmente um resumo dos resumos de instrução normalizados, classificados com base em vários critérios:
- Anfitrião
- Ocorrências
- Tempo total de execução
- Tempo máximo de execução
- Tempo médio de execução
- Tempo de desvio padrão
Cobrimos esse recurso em detalhes nesta postagem do blog, Como usar o Monitor de consultas ClusterControl para MySQL, MariaDB e Percona Server.
Esquema de desempenho
O Performance Schema é uma ótima ferramenta disponível para monitorar os detalhes internos e de execução do MySQL Server em um nível inferior. As seguintes tabelas no Performance Schema podem ser usadas para localizar consultas lentas:
- events_statements_current
- eventos_statements_history
- events_statements_history_long
- events_statements_summary_by_digest
- events_statements_summary_by_user_by_event_name
- events_statements_summary_by_host_by_event_name
O MySQL 5.7.7 e superior inclui o esquema sys, um conjunto de objetos que ajuda os DBAs e desenvolvedores a interpretarem os dados coletados pelo Performance Schema em um formato mais facilmente compreensível. Os objetos de esquema Sys podem ser usados para casos de uso típicos de ajuste e diagnóstico.
O ClusterControl fornece orientadores, que são miniprogramas que você pode escrever usando o ClusterControl DSL (semelhante ao JavaScript) para estender os recursos de monitoramento do ClusterControl personalizados para suas necessidades. Há vários scripts incluídos com base no Esquema de desempenho que você pode usar para monitorar o desempenho da consulta, como espera de E/S, tempo de espera de bloqueio e assim por diante. Por exemplo, em Gerenciar -> Developer Studio , vá para s9s -> mysql -> p_s -> top_tables_by_iowait.js e clique no botão "Compilar e executar". Você deve ver a saída na guia Mensagens para as 10 principais tabelas classificadas por espera de E/S por servidor:
Há vários scripts que você pode usar para entender informações de baixo nível onde e por que a lentidão ocorre, como top_tables_by_lockwait.js , top_accessed_db_files.js e assim por diante.
ClusterControl - Detectando e alertando sobre consultas de longa duração
Com o ClusterControl, você obterá recursos adicionais poderosos que não encontrará na instalação padrão do MySQL. O ClusterControl pode ser configurado para monitorar proativamente os processos em execução, disparar um alarme e enviar uma notificação ao usuário se o limite de consulta longo for excedido. Isso pode ser configurado usando a Configuração de tempo de execução em Configurações:
Para pre1.7.1, o valor padrão para query_monitor_alert_long_running_query é falso. Incentivamos o usuário a habilitar isso definindo-o como 1 (verdadeiro). Para torná-lo persistente, adicione a seguinte linha em /etc/cmon.d/cmon_X.cnf:
query_monitor_alert_long_running_query=1
query_monitor_long_running_query_ms=30000Quaisquer alterações feitas na configuração de tempo de execução são aplicadas imediatamente e não é necessário reiniciar. Você verá algo assim na seção Alarmes se uma consulta exceder os limites de 30.000 ms (30 segundos):
Se você definir as configurações do destinatário de e-mail como "Entregar" para a categoria de gravidade DbComponent plus CRITICAL (conforme mostrado na captura de tela a seguir):
Você deve receber uma cópia deste alarme em seu e-mail. Caso contrário, ele pode ser encaminhado manualmente clicando no botão "Enviar e-mail".
Além disso, você pode filtrar qualquer tipo de recurso de lista de processos que corresponda a determinados critérios com expressão regular (regex). Por exemplo, se você deseja que o ClusterControl detecte consultas de longa duração para três usuários do MySQL chamados 'sbtest', 'myshop' e 'db_user1', faça o seguinte:
Quaisquer alterações feitas na configuração de tempo de execução são aplicadas imediatamente e não é necessário reiniciar.
Além disso, o ClusterControl listará todas as transações de deadlock junto com o status do InnoDB quando ele estava acontecendo em Performance -> Transaction Log :
Esse recurso não está habilitado por padrão, pois a detecção de deadlock afetará o uso da CPU nos nós do banco de dados. Para habilitá-lo, basta marcar a caixa de seleção "Ativar log de transações" e especificar o intervalo desejado. Para torná-lo persistente, adicione uma variável com valor em segundos dentro de /etc/cmon.d/cmon_X.cnf:
db_deadlock_check_interval=30Da mesma forma, se você quiser verificar o status do InnoDB, basta acessar Desempenho -> Status do InnoDB , e escolha o servidor MySQL na lista suspensa. Por exemplo:
Lá vamos nós - todas as informações necessárias são facilmente recuperáveis em alguns cliques.
Resumo
Transações de longa execução podem levar à degradação do desempenho, inatividade do servidor, conexões no máximo e deadlocks. Com o ClusterControl, você pode detectar consultas de longa duração diretamente da interface do usuário, sem a necessidade de examinar cada nó MySQL no cluster.
