Conceitos essenciais para ajuste do Aurora MySQL
Antes de ajustar seu banco de dados Aurora MySQL, certifique-se de conhecer quais são os eventos de espera e estados de thread e por que eles estão ocorrendo. Analise também a arquitetura básica de memória e disco do Aurora MySQL ao utilizar o mecanismo de armazenamento InnoDB. Para acessar um diagrama de arquitetura útil, consulte o Manual de referência do MySQL
Tópicos
Eventos de espera do Aurora MySQL
Um evento de espera indica um recurso pelo qual uma sessão está aguardando. Por exemplo, o evento de espera io/socket/sql/client_connection indica que um thread está no processo de lidar com uma nova conexão. Os recursos comuns que uma sessão aguarda incluem:
-
Acesso com thread único a um buffer, por exemplo, quando uma sessão está tentando modificar um buffer
-
Uma linha que está bloqueada por outra sessão
-
Uma leitura de arquivo de dados
-
Uma gravação em arquivo de log
Por exemplo, para satisfazer uma consulta, a sessão pode realizar uma varredura de tabela completa. Se esses dados ainda não estiverem na memória, a sessão aguardará a conclusão da E/S do disco. Quando os buffers são lidos na memória, talvez a sessão precise aguardar, pois outras sessões estão acessando os mesmos buffers. O banco de dados registra as esperas utilizando um evento de espera predefinido. Esses eventos estão agrupados em categorias.
Por si só, um evento de espera não mostra um problema de performance. Por exemplo, se os dados solicitados não estão na memória, é necessário ler dados do disco. Se uma sessão bloquear uma linha para uma atualização, outra sessão aguardará que essa linha seja desbloqueada para poder atualizá-la. Uma confirmação exige a conclusão da gravação em um arquivo de log. Esperas são componentes integrais do funcionamento normal de um banco de dados.
Em geral, muitos eventos de espera indicam um problema de performance. Nesses casos, é possível utilizar os dados dos eventos de espera para determinar onde as sessões estão perdendo tempo. Por exemplo, se um relatório que é normalmente executado em minutos passou a demorar várias horas, é possível identificar os eventos de espera que mais contribuem para o tempo de espera total. Se você puder determinar as causas dos principais eventos de espera, às vezes pode aplicar alterações que melhoram a performance. Por exemplo, se a sua sessão está aguardando uma linha que foi bloqueada por outra sessão, é possível encerrar a sessão responsável pelo bloqueio.
Estados de threads do Aurora MySQL
Um estado geral de thread é um valor State associado ao processamento geral de consultas. Por exemplo, 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.
É possível utilizar estados de thread para ajustar o Aurora MySQL de maneira semelhante a como você utiliza eventos de espera. Por exemplo, ocorrências frequentes de sending data em geral indicam que uma consulta não está utilizando um índice. Para saber mais sobre estados de thread, consulte o tópico sobre Estados gerais de thread
Quando você utiliza o Performance Insights, uma das seguintes condições é verdadeira:
-
O Performance Schema está habilitado: o Aurora MySQL mostra eventos de espera em vez do estado de thread.
-
O Performance Schema não está habilitado: o Aurora MySQL mostra o estado de thread.
Convém configurar o Performance Schema para gerenciamento automático. O Performance Schema fornece insights adicionais e melhores ferramentas para investigar possíveis problemas de performance. Para obter mais informações, consulte Visão geral do Performance Schema para o Insights de Performance no Aurora MySQL.
Memória do Aurora MySQL
No Aurora MySQL, as áreas de memória mais importantes são o grupo de buffer e o buffer de logs.
Tópicos
Grupo de buffer
O Grupo de buffer é a área de memória compartilhada na qual o Aurora MySQL armazena dados de tabela e índice em cache. As consultas podem acessar dados utilizados com frequência diretamente da memória sem fazer a leitura do disco.
O grupo de buffer está estruturado como uma lista vinculada de páginas. Uma página pode incluir várias linhas. O Aurora MySQL utiliza um algoritmo menos utilizado recentemente (LRU) para deixar páginas fora do grupo.
Para obter mais informações, consulte os tópicos sobre Grupo de buffer
Processos do Aurora MySQL
O Aurora MySQL utiliza um modelo de processos muito diferente do Aurora PostgreSQL.
Servidor MySQL (mysqld)
O servidor MySQL é um único processo de sistema operacional denominado mysqld. Ele não gera processos adicionais. Portanto, um banco de dados Aurora MySQL utiliza mysqld para realizar a maior parte do trabalho.
Quando o servidor MySQL é iniciado, ele escuta conexões de rede de clientes MySQL. Quando um cliente se conecta ao banco de dados, o mysqld abre um thread.
Threads
Os threads do gerenciador de conexões associam cada conexão de cliente a um thread dedicado. Esse thread gerencia a autenticação, executa instruções e retorna os resultados ao cliente. O Gerenciador de conexões cria novos threads quando necessário.
O cache de threads é o conjunto de threads disponíveis. Quando uma conexão é encerrada, o MySQL retorna o thread ao cache de threads quando este não está cheio. A variável de sistema thread_cache_size determina o tamanho do cache de threads.
Pool de threads
O pool de threadsconsiste em vários grupos de threads. Cada grupo gerencia um conjunto de conexões de clientes. Quando um cliente se conecta ao banco de dados, o pool de threads atribui as conexões aos grupos de threads de maneira bidirecional. O pool de threads separa conexões e threads. Não há relação fixa entre conexões e os threads que executam instruções delas recebidas.
