Eventos de espera do Aurora MySQL

Os seguintes são alguns eventos de espera comuns para o Aurora MySQL.

nota

Para ter informações sobre como ajustar a performance do Aurora MySQL usando eventos de espera, consulte Ajustar o Aurora MySQL com eventos de espera.

Para obter informações sobre as convenções de nomenclatura usadas em eventos de espera do MySQL, consulte Performance Schema instrument naming conventions na documentação do MySQL.

cpu

O número de conexões ativas que estão prontas para execução é consistentemente maior que o número de vCPUs. Para ter mais informações, consulte cpu.

io/aurora_redo_log_flush

Uma sessão está mantendo dados no armazenamento do Aurora. Normalmente, esse evento de espera é para uma operação de E/S de gravação no Aurora MySQL. Para ter mais informações, consulte io/aurora_redo_log_flush.

io/aurora_respond_to_client

O processamento da consulta foi concluído e os resultados estão sendo retornados ao cliente da aplicação para as seguintes versões do Aurora MySQL: 2.10.2 e versões 2.10 posteriores, 2.09.3 e versões 2.09 posteriores, e 2.07.7 e versões 2.07 posteriores. Compare a largura de banda da rede da classe de instância de banco de dados com o tamanho do conjunto de resultados que está sendo retornado. Além disso, confira os tempos de resposta no lado do cliente. Se o cliente não responder e não conseguir processar os pacotes TCP, poderão ocorrer descartes de pacotes e retransmissões TCP. Essa situação afeta negativamente a largura de banda da rede. Nas versões inferiores às versões 2.10.2, 2.09.3 e 2.07.7, o evento de espera inclui incorretamente o tempo ocioso. Para aprender a ajustar seu banco de dados quando essa espera for proeminente, consulte io/aurora_respond_to_client.

io/file/csv/data

Threads estão gravando em tabelas no formato de valores separados por vírgula (CSV). Verifique o uso de sua tabela CSV. Uma causa típica desse evento é a definição de log_output em uma tabela.

io/file/sql/binlog

Um thread está aguardando um arquivo de log binário (binlog) que está sendo gravado em disco.

io/redo_log_flush

Uma sessão está mantendo dados no armazenamento do Aurora. Normalmente, esse evento de espera é para uma operação de E/S de gravação no Aurora MySQL. Para ter mais informações, consulte io/redo_log_flush.

io/socket/sql/client_connection

O programa mysqld está ocupado com a criação de threads para lidar com novas conexões de clientes de entrada. Para ter mais informações, consulte io/socket/sql/client_connection.

io/table/sql/handler

O mecanismo está aguardando acesso a uma tabela. Esse evento ocorre não importa se os dados estão armazenados em cache no grupo de buffer ou acessados no disco. Para ter mais informações, consulte io/table/sql/handler.

lock/table/sql/handler

Este evento de espera é um manipulador de eventos de espera de bloqueio de tabela. Para ter mais informações sobre eventos "átomo" e "molécula" no Performance Schema, consulte o tópico sobre Eventos "átomo" e "molécula" no Performance Schema, na documentação do MySQL.

synch/cond/innodb/row_lock_wait

Várias instruções de linguagem de manipulação de dados (DML) estão acessando as mesmas linhas de banco de dados simultaneamente. Para ter mais informações, consulte synch/cond/innodb/row_lock_wait.

synch/cond/innodb/row_lock_wait_cond

Várias instruções DML estão acessando as mesmas linhas de banco de dados simultaneamente. Para ter mais informações, consulte synch/cond/innodb/row_lock_wait_cond.

synch/cond/sql/MDL_context::COND_wait_status

Threads estão aguardando em um bloqueio de metadados de tabela. O mecanismo utiliza esse tipo de bloqueio para gerenciar o acesso simultâneo a um esquema de banco de dados e garantir a consistência dos dados. Para ter mais informações, consulte Optimizing locking operations na documentação do MySQL. Para aprender a ajustar seu banco de dados quando esse evento for proeminente, consulte synch/cond/sql/MDL_context::COND_wait_status.

synch/cond/sql/MYSQL_BIN_LOG::COND_done

Você habilitou o registro em log binário. Pode haver uma alta taxa de transferência de confirmações, alto número de transações fazendo confirmações ou réplicas lendo binlogs. Considere utilizar instruções em várias linhas ou instruções de empacotamento em uma única transação. No Aurora, use bancos de dados globais em vez da replicação de logs binários ou use os parâmetros aurora_binlog_*.

synch/mutex/innodb/aurora_lock_thread_slot_futex

Várias instruções DML estão acessando as mesmas linhas de banco de dados simultaneamente. Para ter mais informações, consulte synch/mutex/innodb/aurora_lock_thread_slot_futex.

synch/mutex/innodb/buf_pool_mutex

O grupo de buffer não é suficientemente grande para armazenar o conjunto de dados de trabalho. Ou a workload acessa páginas de uma tabela específica, resultando na contenção no grupo de buffer. Para ter mais informações, consulte synch/mutex/innodb/buf_pool_mutex.

synch/mutex/innodb/fil_system_mutex

O processo está esperando ter acesso ao cache de memória do espaço de tabelas. Para ter mais informações, consulte synch/mutex/innodb/fil_system_mutex.

synch/mutex/innodb/trx_sys_mutex

Operações estão verificando, atualizando, excluindo ou adicionando IDs de transações no InnoDB de maneira consistente ou controlada. Essas operações exigem uma chamada mutex trx_sys que é rastreada pela instrumentação do Performance Schema. Elas incluem o gerenciamento do sistema de transações quando o banco de dados é iniciado ou encerrado, reversões, limpezas de ações desfazer, acesso para leitura de linhas e cargas de grupos de buffer. A alta carga do banco de dados com um alto número de transações resulta no surgimento frequente desse evento de espera. Para ter mais informações, consulte synch/mutex/innodb/trx_sys_mutex.

synch/mutex/mysys/KEY_CACHE::cache_lock

O mutex keycache->cache_lock controla o acesso ao cache de chaves para tabelas MyISAM. Embora o Aurora MySQL não permita o uso de tabelas MyISAM para armazenar dados persistentes, elas são usadas para armazenar tabelas temporárias internas. Considere conferir os contadores de status created_tmp_disk_tables ou created_tmp_tables, porque em determinadas situações, as tabelas temporárias são gravadas no disco quando não cabem mais na memória.

synch/mutex/sql/FILE_AS_TABLE::LOCK_offsets

O mecanismo obtém esse mutex quando abre ou cria um arquivo de metadados de tabela. Quando esse evento de espera ocorre excessivamente, significa que o número de tabelas criadas ou abertas aumentou.

synch/mutex/sql/FILE_AS_TABLE::LOCK_shim_lists

O mecanismo obtém esse mutex ao executar operações como reset_size,detach_contents ou add_contents na estrutura interna que controla tabelas abertas. O mutex sincroniza o acesso ao conteúdo das listas. Quando esse evento de espera ocorre com alta frequência, indica uma súbita mudança no conjunto de tabelas anteriormente acessadas. O mecanismo precisa acessar novas tabelas ou descartar o contexto relacionado a essas tabelas.

synch/mutex/sql/LOCK_open

O número de tabelas que estão sendo abertas pelas suas sessões excede o tamanho do cache de definição de tabelas ou do cache de abertura de tabelas. Aumente o tamanho desses caches. Para ter mais informações, consulte Como o MySQL abre e fecha tabelas.

synch/mutex/sql/LOCK_table_cache

O número de tabelas que estão sendo abertas pelas suas sessões excede o tamanho do cache de definição de tabelas ou do cache de abertura de tabelas. Aumente o tamanho desses caches. Para ter mais informações, consulte Como o MySQL abre e fecha tabelas.

synch/mutex/sql/LOG

Neste evento de espera, há threads aguardando um bloqueio de log. Por exemplo, um thread pode aguardar um bloqueio para gravar no arquivo de log de consultas lentas.

synch/mutex/sql/MYSQL_BIN_LOG::LOCK_commit

Neste evento de espera, há um thread aguardando para adquirir um bloqueio com a intenção de confirmar no log binário. A contenção do log binário pode ocorrer em bancos de dados com uma taxa de alteração muito alta. Dependendo da versão do MySQL, há alguns bloqueios usados para proteger a consistência e durabilidade do log binário. No RDS para MySQL, os logs binários são usados para a replicação e para o processo de backup automatizado. No Aurora MySQL, os logs binários não são necessários para a replicação ou backups nativos. Por padrão, eles estão desabilitados, mas podem ser habilitados e usados para replicação externa e captura de dados de alterações. Para ter mais informações, consulte The binary log na documentação do MySQL.

sync/mutex/sql/MYSQL_BIN_LOG::LOCK_dump_thread_metrics_collection

Se o registro em log binário estiver habilitado, o mecanismo obterá esse mutex ao imprimir métricas de threads de despejo ativo no log de erros do mecanismo e no mapa de operações interno.

sync/mutex/sql/MYSQL_BIN_LOG::LOCK_inactive_binlogs_map

Se o registro em log binário estiver habilitado, o mecanismo obterá esse mutex ao adicionar, excluir ou pesquisar na lista de arquivos binlog atrás do mais recente.

sync/mutex/sql/MYSQL_BIN_LOG::LOCK_io_cache

Se o registro em log binário estiver habilitado, o mecanismo obterá esse mutex durante operações de cache de E/S para binlog do Aurora: alocar, redimensionar, liberar, gravar, ler, limpar e acessar informações do cache. Se esse evento ocorrer com frequência, significa que o mecanismo está acessando o cache em que os eventos de log binário são armazenados. Para reduzir tempos de espera, reduza confirmações. Tente agrupar várias instruções em uma só transação.

synch/mutex/sql/MYSQL_BIN_LOG::LOCK_log

Você habilitou o registro em log binário. Pode haver uma alta taxa de transferência de confirmações, muitas transações fazendo confirmações ou réplicas lendo binlogs. Considere utilizar instruções em várias linhas ou instruções de empacotamento em uma única transação. No Aurora, use bancos de dados globais em vez da replicação de logs binários ou use os parâmetros aurora_binlog_*.

synch/mutex/sql/SERVER_THREAD::LOCK_sync

O mutex SERVER_THREAD::LOCK_sync é obtido durante o agendamento, o processamento ou a inicialização de threads para gravações em arquivos. A ocorrência excessiva desse evento de espera indica aumento na atividade de gravação no banco de dados.

synch/mutex/sql/TABLESPACES:lock

O mecanismo obtém o mutex TABLESPACES:lock durante as operações de espaço de tabela a seguir: criar, excluir, truncar e estender. A ocorrência excessiva desse evento de espera indica alta frequência de operações de espaço de tabela. Um exemplo é carregar muitos dados no banco de dados.

synch/rwlock/innodb/dict

Neste evento de espera, há threads aguardando um rwlock mantido no dicionário de dados InnoDB.

synch/rwlock/innodb/dict_operation_lock

Neste evento de espera, há threads aguardando bloqueios nas operações do dicionário de dados InnoDB.

synch/rwlock/innodb/dict sys RW lock

É acionado ao mesmo tempo um alto número de instruções de linguagem de controle de dados (DCLs) simultâneas no código de linguagem de definição de dados (DDLs). Reduza a dependência da aplicação por DDLs durante suas atividades regulares.

synch/rwlock/innodb/index_tree_rw_lock

Muitas instruções de linguagem de manipulação de dados (DML) estão acessando as mesmas linhas de objetos de banco de dados simultaneamente. Tente utilizar instruções com várias linhas. Além disso, disperse a workload por objetos de banco de dados diferentes. Por exemplo, implemente o particionamento.

synch/sxlock/innodb/dict_operation_lock

É acionado ao mesmo tempo um alto número de instruções de linguagem de controle de dados (DCLs) simultâneas no código de linguagem de definição de dados (DDLs). Reduza a dependência da aplicação por DDLs durante suas atividades regulares.

synch/sxlock/innodb/dict_sys_lock

É acionado ao mesmo tempo um alto número de instruções de linguagem de controle de dados (DCLs) simultâneas no código de linguagem de definição de dados (DDLs). Reduza a dependência da aplicação por DDLs durante suas atividades regulares.

synch/sxlock/innodb/hash_table_locks

A sessão não foi capaz de encontrar páginas no grupo de buffer. O mecanismo precisa ler um arquivo ou modificar a lista com utilização menos recente (LRU) para o grupo de buffer. Considere aumentar o tamanho do cache do buffer e melhorar caminhos de acesso para consultas relevantes.

synch/sxlock/innodb/index_tree_rw_lock

Muitas instruções de linguagem de manipulação de dados (DML) estão acessando as mesmas linhas de objetos de banco de dados simultaneamente. Tente utilizar instruções com várias linhas. Além disso, disperse a workload por objetos de banco de dados diferentes. Por exemplo, implemente o particionamento.

Para ter mais informações sobre como solucionar problemas de eventos de espera de sincronização, consulte Why is my MySQL DB instance showing a high number of active sessions waiting on SYNCH wait events in Performance Insights? (Por que minha instância de banco de dados do MySQL está mostrando um grande número de sessões ativas aguardando eventos de espera SYNCH no Performance Insights?).