enviar dados
O estado de thread sending data indica que um thread está lendo e filtrando linhas de uma consulta para determinar o conjunto de resultados correto. O nome é enganoso porque implica que o estado está transferindo dados, e não coletando e preparando dados para envio posterior.
Versões compatíveis do mecanismo
Essas informações sobre estados de thread têm suporte para as seguintes versões:
-
Aurora MySQL versão 2 até 2.09.2
Contexto
Muitos estados de thread são de curta duração. Operações ocorrendo durante sending
data tendem a realizar um grande número de leituras em disco ou cache. Portanto, sending data geralmente é o estado de execução mais longa durante a vida útil de uma determinada consulta. Esse estado aparece quando o Aurora MySQL está fazendo o seguinte:
-
Lendo e processando linhas para uma instrução
SELECT -
Executando um grande número de leituras do disco ou da memória
-
Concluindo uma leitura completa de todos os dados de uma consulta específica
-
Lendo dados de uma tabela, um índice ou o trabalho de um procedimento armazenado
-
Classificando, agrupando ou ordenando dados
Depois que o estado sending data terminar de preparar os dados, o estado de thread writing to net indicará o retorno dos dados para o cliente. Normalmente, writing to net é capturado somente quando o conjunto de resultados é muito grande ou a latência de rede grave está retardando a transferência.
Possíveis causas do maior número de esperas
O surgimento de sending data por si só não indica um problema. Se a performance for ruim e você vir instâncias frequentes de sending data, as causas mais prováveis são as seguintes.
Consulta ineficiente
Na maioria dos casos, o que é responsável por esse estado é uma consulta que não está utilizando um índice apropriado para localizar o conjunto de resultados de uma determinada consulta. Por exemplo, considere uma consulta que está lendo uma tabela de 10 milhões de registros para todos os pedidos feitos na Califórnia e na qual coluna de estado não está indexada ou está mal indexada. No último caso, o índice pode existir, mas o otimizador o ignora devido à baixa cardinalidade.
Configuração do servidor abaixo do ideal
Se várias consultas aparecerem no estado sending data, o servidor de banco de dados pode estar indevidamente configurado. Especificamente, o servidor pode apresentar os seguintes problemas:
-
O servidor de banco de dados não possui capacidade de computação suficiente: E/S de disco, tipo e velocidade de disco, CPU ou número de CPUs.
-
O servidor está sem recursos alocados, como o grupo de buffers do InnoDB para tabelas do InnoDB ou o buffer de chaves para tabelas MyIsam.
-
Configurações de memória por thread, como
sort_buffer,read_bufferejoin_bufferconsomem mais RAM do que o necessário, deixando o servidor físico sem recursos de memória.
Ações
A diretriz geral é localizar consultas que retornem muitas linhas, verificando o Performance Schema. Se o registro em log de consultas que não usam índices estiver habilitado, você também poderá examinar os resultados dos logs lentos.
Tópicos
Habilite o Performance Schema se ele não estiver habilitado
O Performance Insights relata estados de thread somente quando instrumentos do Performance Schema não estão habilitados. Quando os instrumentos do Performance Schema estão habilitados, o Performance Insights relata eventos de espera. Os instrumentos do Performance Schema fornecem insights adicionais e melhores ferramentas quando você investiga possíveis problemas de performance. Portanto, convém habilitar o Performance Schema. Para obter mais informações, consulte Visão geral do Performance Schema para o Insights de Performance no Aurora MySQL.
Examinar configurações de memória
Examine as configurações de memória para os grupos de buffer primários. Certifique-se de que esses grupos sejam dimensionados adequadamente para a workload. Se o banco de dados utilizar várias instâncias de grupos de pool, certifique-se de que elas não estejam divididas em muitos grupos de buffer pequenos. Threads só podem utilizar um grupo de buffer de cada vez.
Certifique-se de que as seguintes configurações de memória utilizadas para cada thread sejam dimensionadas corretamente:
-
read_buffer
-
read_rnd_buffer
-
sort_buffer
-
join_buffer
-
binlog_cache
A menos que você tenha um motivo específico para modificar as configurações, use os valores padrão.
Examinar os planos de explicação para o uso de índices
Para consultas no estado de thread sending data, examine o plano para determinar se os índices apropriados são utilizados. Se uma consulta não estiver utilizando um índice útil, considere adicionar dicas como USE INDEX ou FORCE
INDEX. Dicas podem aumentar ou diminuir muito o tempo necessário para executar uma consulta. Portanto, tenha cautela antes de adicioná-las.
Verificar o volume dos dados retornados
Verifique as tabelas que estão sendo consultadas e a quantidade de dados que elas contêm. Alguns desses dados podem ser arquivados? Em muitos casos, a causa de tempos de execução de consultas ruins não é o resultado do plano de consulta, mas sim o volume de dados a serem processados. Muitos desenvolvedores são eficientes ao adicionar dados a um banco de dados, mas raramente consideram o ciclo de vida do conjunto de dados nas fases de design e de desenvolvimento.
Procure consultas que tenham boa performance em bancos de dados de baixo volume, mas que tenham performance ruim no seu sistema atual. Às vezes, os desenvolvedores que projetam consultas específicas podem não perceber que essas consultas estão retornando 350.000 linhas. Eles podem ter desenvolvido essas consultas em um ambiente de menor volume com conjuntos de dados menores do que os dos ambientes de produção.
Verificar se há problemas de simultaneidade
Verifique se várias consultas do mesmo tipo estão sendo executadas ao mesmo tempo. Algumas formas de consultas são executadas de maneira eficiente quando são executadas sozinhas. No entanto, se formas semelhantes de consultas forem executadas juntas ou em alto volume, elas poderão causar problemas de simultaneidade. Frequentemente, esses problemas são causados quando o banco de dados utiliza tabelas temporárias para renderizar resultados. Um nível restritivo de isolamento de transações também pode causar problemas de simultaneidade.
Se tabelas forem lidas e gravadas simultaneamente, o banco de dados pode estar utilizando bloqueios. Para ajudar a identificar períodos de baixa performance, examine o uso de bancos de dados por meio de processos em lote em larga escala. Para ver bloqueios e reversões recentes, examine a saída do comando SHOW ENGINE INNODB STATUS.
Verificar a estrutura das suas consultas
Verifique se as consultas capturadas desses estados usam subconsultas. Esse tipo de consulta costuma resultar em uma performance ruim, pois o banco de dados compila os resultados internamente e os substitui de volta na consulta para renderizar os dados. Esse processo é uma etapa adicional para o banco de dados. Em muitos casos, essa etapa pode resultar em uma performance ruim em uma condição de carregamento altamente simultânea.
Verifique também se as suas consultas usam um grande número de cláusulas ORDER BY e GROUP BY. Nessas operações, muitas vezes o banco de dados deve primeiro formar todo o conjunto de dados na memória. Em seguida, deve ordená-lo ou agrupá-lo de uma maneira específica antes de o retornar ao cliente.
