synch/mutex/innodb/temp_pool_manager_mutex - Amazon Aurora
Versões compatíveis do mecanismoContextoPossíveis causas do maior número de esperasAções

synch/mutex/innodb/temp_pool_manager_mutex

O evento de espera synch/mutex/innodb/temp_pool_manager_mutex ocorre quando uma sessão está aguardando para adquirir um mutex para gerenciar o grupo de espaços para tabela temporários de sessão.

Versões compatíveis do mecanismo

Essas informações de eventos de espera têm suporte nas seguintes versões do mecanismo:

  • Aurora MySQL versão 3

Contexto

O Aurora MySQL versão 3.x e posterior usa temp_pool_manager_mutex para controlar várias sessões acessando o grupo temporário de espaços para tabela ao mesmo tempo. O Aurora MySQL gerencia o armazenamento por meio de um volume de cluster do Aurora para dados persistentes e armazenamento local para arquivos temporários. Um espaço para tabela temporário é necessário quando uma sessão cria uma tabela temporária no volume de cluster do Aurora.

Quando uma sessão solicita pela primeira vez um espaço para tabela temporário, o MySQL aloca espaços para tabela temporários da sessão do grupo compartilhado. Uma sessão pode conter até dois espaços para tabela temporários por vez para os seguintes tipos de tabela:

  • Tabelas temporárias criadas pelo usuário.

  • Tabelas temporárias internas geradas pelo otimizador

O mecanismo TempTable padrão usa o seguinte mecanismo de transbordamento para lidar com tabelas temporárias:

  • Armazena tabelas na RAM até o limite temptable_max_ram.

  • Muda para arquivos mapeados na memória no armazenamento local quando a RAM está cheia.

  • Usa o volume do cluster compartilhado quando os arquivos mapeados na memória atingem o limite temptable_max_mmap.

Depois que as tabelas temporárias excedem os limites da RAM e do armazenamento local, o MySQL as gerencia usando o espaço para tabela em disco.

Quando uma sessão exige uma tabela temporária em disco, o MySQL:

  • Procura espaços para tabela INACTIVE disponíveis no grupo para reutilização.

  • Criará dez espaços para tabela se não existirem espaços INACTIVE.

Quando uma sessão é desconectada, o MySQL:

  • Trunca os espaços para tabela temporários da sessão.

  • Marca-os como INACTIVE no grupo para reutilização.

  • Mantém o tamanho atual do grupo até a reinicialização do servidor.

  • Volta ao tamanho padrão do grupo (dez espaços para tabela) após a reinicialização.

Possíveis causas do maior número de esperas

Situações comuns que causam esse evento de espera:

  • Sessões simultâneas que criam tabelas temporárias internas no volume do cluster.

  • Sessões simultâneas que criam tabelas temporárias no volume do cluster.

  • Encerramento repentino de sessões que usam espaços para tabela ativos.

  • Expansão do grupo de espaços para tabela durante workloads com uso intenso de gravação.

  • Consultas simultâneas que acessam INFORMATION_SCHEMA.

Ações

Recomenda-se ações distintas, dependendo dos motivos do evento de espera.

Monitorar e otimizar o uso de tabelas temporárias

Para monitorar e otimizar o uso de tabelas temporárias, use um destes métodos:

  • Confira o contador Created_tmp_disk_tables no Insights de Performance para monitorar a criação de tabelas temporárias em disco no cluster do Aurora.

  • Execute este comando em seu banco de dados para monitorar diretamente a criação de tabelas temporárias: mysql> show status like '%created_tmp_disk%'.

nota

O comportamento da tabela temporária difere entre os nós de leitura e gravação do Aurora MySQL. Para obter mais informações, consulte Novo comportamento de tabela temporária no Aurora MySQL versão 3.

Depois de identificar as consultas que criam tabelas temporárias, siga estas etapas de otimização:

  • Use EXPLAIN para examinar os planos de execução de consultas e identificar onde e por que as tabelas temporárias estão sendo criadas.

  • Modifique as consultas para reduzir o uso de tabelas temporárias sempre que possível.

Se a otimização de consultas por si só não resolver os problemas de performance, pense em ajustar estes parâmetros de configuração:

  • temptable_max_ram: controla o uso máximo de RAM para tabelas temporárias.

  • temptable_max_mmap: define o limite para armazenamento de arquivos mapeados na memória.

  • tmp_table_size: aplica-se quando aurora_tmptable_enable_per_table_limit está habilitado (desabilitado por padrão).

Importante

Observe que determinadas condições de consulta sempre exigirão tabelas temporárias em disco, independentemente das configurações. Para acessar mais informações sobre o mecanismo de armazenamento TempTable, consulte Use the TempTable storage engine on Amazon RDS for MySQL and Amazon Aurora MySQL.

Analisar as consultas usando INFORMATION_SCHEMA

Quando você consulta tabelas INFORMATION_SCHEMA, o MySQL cria tabelas temporárias do InnoDB no volume do cluster. Cada sessão precisa de um espaço para tabela temporário para essas tabelas, o que pode causar problemas de performance durante o alto acesso simultâneo.

Para melhorar a performance:

  • Use PERFORMANCE_SCHEMA em vez de INFORMATION_SCHEMA sempre que possível.

  • Se você precisar usar INFORMATION_SCHEMA, reduza a frequência com que você executa essas consultas.

Aumentar o parâmetro innodb_sync_array_size

O parâmetro innodb_sync_array_size controla o tamanho da matriz de espera mutex/lock no MySQL. O valor padrão de 1 funciona para workloads gerais, mas aumentá-lo pode reduzir a contenção de threads durante a alta simultaneidade.

Quando sua workload mostra um número crescente de threads de espera:

  • Monitore o número de threads de espera em sua workload.

  • Defina innodb_sync_array_size igual ou superior à contagem de vCPUs da sua instância para dividir a estrutura de coordenação de threads e reduzir a contenção.

nota

Para determinar o número de vCPUs disponíveis em sua instância do RDS, consulte as especificações da vCPU em Tipos de instância do Amazon RDS.

Implementar um pool de conexões

O MySQL atribui um espaço para tabela dedicado a cada sessão que cria uma tabela temporária. Esse espaço para tabela permanece ativo até que a conexão com o banco de dados termine. Para gerenciar seus recursos com maior eficiência:

  • Implemente o agrupamento de conexões para limitar o número de espaços para tabelas temporários ativos.

  • Reutilize as conexões existentes em vez de criar outras para cada operação.