Este tópico descreve as causas de um alto número de threads ativas em uma instância do ApsaraDB RDS for MySQL e fornece soluções.
Informações de contexto
O número de threads ativas (também conhecidas como conexões ativas) é uma métrica fundamental para medir a carga de trabalho de uma instância MySQL. Em uma instância saudável, o número de threads ativas costuma ser inferior a 10. Para instâncias de alta especificação e alto QPS, esse número pode chegar a 20 ou 30. Se a contagem atingir centenas ou até milhares, isso indica que as consultas SQL estão se acumulando e os tempos de resposta aumentam. Em casos graves, a instância pode parar de responder e deixar de processar solicitações SQL.
Verificar threads ativas
O console do ApsaraDB RDS fornece vários métodos para visualizar o número de threads ativas:
-
Monitoramento e alertas
Na página Monitoring and Alerts do console, clique na guia Standard Monitoring e, em seguida, clique em Standard View para visualizar as métricas de threads ativas da instância.
-
Database Autonomy Service (DAS)
Na página do console, clique na guia Dashboard para visualizar o status de conexão das sessões. Se o número de threads for muito alto, isso indica que as sessões da instância estão bloqueadas.
Acúmulo de SQL lento
-
Sintoma
Se o monitoramento mostrar um aumento nas threads ativas, execute primeiro o comando
show processlist;para verificar se há consultas SQL lentas. Um grande número de consultas que varrem muitas linhas costuma causar o aumento do número de threads ativas.Visualize as informações sobre SQL lento na página no console.
-
Resolução
Use o recurso SQL throttling ou encerre as sessões para reduzir o impacto das consultas SQL lentas.
Problemas no cache de tabelas
-
Sintoma
Se o cache de tabelas for insuficiente, um grande número de instruções SQL permanece no estado
Opening table. Isso geralmente ocorre quando o QPS é alto ou quando há um grande número de tabelas. -
Resolução
Aumente os valores do parâmetro table_open_cache (não requer reinicialização da instância) e do parâmetro table_open_cache_instances (requer reinicialização da instância).
Problemas de bloqueio de metadados (MDL)
-
Sintoma
Quando ocorre um bloqueio de metadados (MDL), um grande número de consultas SQL entra no estado
Waiting for table metadata lock. Durante as fasesprepareecommit, uma instrução DDL deve adquirir um MDL. Se a tabela tiver transações não confirmadas ou consultas SQL lentas, a operação DDL será bloqueada. Isso, por sua vez, bloqueia outras consultas SQL e, eventualmente, aumenta o número de threads ativas. -
Resolução
Para resolver esse problema, encerre as transações não confirmadas, as consultas SQL lentas ou a instrução DDL em execução.
Conflitos de bloqueio de linha
-
Sintoma
Um aumento nas métricas innodb_row_lock_waits e innodb_row_lock_time indica conflitos de bloqueio de linha.
Na página do console, clique na guia Dashboard para visualizar os itens de monitoramento em row lock.
-
Resolução
Execute o comando
show engine innodb status;para verificar se um grande número de sessões está no estadoLock wait. Se sim, a contenção de bloqueio de linha é grave. Para reduzir a contenção, otimize as atualizações de hotspots, diminua o tamanho das transações e confirme as transações rapidamente.