Solucionar problemas de falta de memória em bancos de dados do Aurora MySQL
Quando uma instância de banco de dados do Aurora MySQL fica com pouca memória, o sistema operacional pode encerrar o processo do banco de dados, provocando uma reinicialização não planejada. Para ajudar a evitar essas reinicializações, o Aurora MySQL inclui recursos de gerenciamento de memória que monitoram a memória do sistema e realizam ações automáticas de recuperação quando a memória está baixa. Essas ações ajudam a evitar a indisponibilidade do banco de dados devido a esgotamento de memória.
Os seguintes parâmetros controlam esse comportamento:
-
aurora_enable_memory_management: disponível somente no Aurora MySQL SQL 8.4.-
Quando definido como
ON(padrão), o Aurora gerencia automaticamente as ações de recuperação de memória e o parâmetroaurora_oom_responseé ignorado. -
Defina como
OFFpara controlar manualmente as ações de recuperação por meio deaurora_oom_response.
-
-
aurora_oom_response: uma lista separada por vírgulas de ações de recuperação. Uma string vazia desabilita todas as ações. Disponível no Aurora MySQL versão 3. Disponível também no Aurora MySQL 8.4, mas é considerado somente quandoaurora_enable_memory_managementestá definido comoOFF.
Ações de resposta a OOM
As ações a seguir podem ser incluídas em aurora_oom_response, listadas das menos às mais agressivas.
| Ação | O que ela faz | Observações |
|---|---|---|
print |
Registra em log consultas e conexões que consomem muita memória no log de erros. Nenhuma consulta ou conexão é encerrada. | Disponível no Aurora MySQL versões 3 e 8.4. |
tune |
Reduz os caches internos de tabela (table_open_cache, table_definition_cache) para liberar memória. Os tamanhos do cache são restaurados quando a memória volta ao normal. As entradas anteriormente armazenadas em cache não são restauradas; novas entradas são adicionadas somente quando consultas subsequentes as acessam. |
Disponível no Aurora MySQL versões 3 e 8.4. Somente instâncias provisionadas. Não há suporte no Sem Servidor v2. |
tune_buffer_pool |
Reduz o grupo de buffers do InnoDB para liberar memória. O tamanho do grupo de buffers é restaurado quando a memória volta ao normal. As páginas anteriormente armazenadas em cache que foram removidas não são recarregadas automaticamente; novas páginas são armazenadas em cache somente quando consultas subsequentes as acessam. | Somente Aurora MySQL versão 3 (3.06 e posterior) e Aurora MySQL 8.4. Compatível com instâncias provisionadas com apenas 2 vCPUs. Não é compatível com o Sem Servidor v2. |
decline |
Rejeita novas consultas com um erro enquanto a memória está baixa. | Disponível no Aurora MySQL versões 3 e 8.4. |
kill_query |
Encerra a execução de consultas SELECT, começando com os maiores consumidores de memória, até que a memória volte ao normal. A DDL, outras DMLs e as transações não são afetadas. |
Disponível no Aurora MySQL versões 3 e 8.4. Mutuamente excludente com kill_connect: se ambos estiverem definidos, somente kill_connect será ativado. |
kill_connect |
Encerra as conexões de usuário, revertendo as respectivas transações ativas e encerrando as instruções DDL. | Veja abaixo o comportamento específico da versão. |
Importante
É necessário emparelhar tune_buffer_pool com kill_query ou kill_connect no valor do parâmetro aurora_oom_response. Sem um deles, o redimensionamento do grupo de buffers não ocorre mesmo quando tune_buffer_pool está incluído.
Comportamento kill_connect específico da versão
| Versão do Aurora MySQL | Comportamento |
|---|---|
| Aurora MySQL 3.04-Aurora MySQL 3.10 | Encerra as conexões de usuário para liberar memória suficiente e permitir que o banco de dados se recupere da pressão de memória. |
| Aurora MySQL 3.11 e posterior, Aurora MySQL 8.4 | Encerra as conexões de usuário para liberar memória suficiente e permitir que o banco de dados se recupere da pressão de memória. Também encerra qualquer conexão de usuário que tente alocar memória durante a pressão de memória. |
No Sem Servidor v2, o Aurora responde à pressão de memória aumentando a escala verticalmente primeiro das ACUs para fornecer memória adicional. Se a pressão de memória persistir enquanto o ajuste de escala estiver em andamento, o Aurora poderá encerrar as conexões existentes para recuperar a memória. O encerramento das conexões que tentam alocar memória ocorre somente quando a instância atinge o limite máximo de ACU configurado e não consegue escalar ainda mais.
Valores padrão por versão
O Aurora MySQL configura aurora_oom_response automaticamente com base na versão do mecanismo, no tipo de instância e na memória disponível.
No Aurora MySQL 8.4, quando aurora_enable_memory_management é ON (o padrão), o Aurora gerencia automaticamente as ações de recuperação de memória, e o valor aurora_oom_response não é usado. Quando definido como OFF, o Aurora usa o valor aurora_oom_response diretamente, que está vazio por padrão, o que significa que nenhuma ação de recuperação é realizada, a menos que você as configure explicitamente. A tabela de padrões a seguir é aplicável somente ao Aurora MySQL versão 3.
Limite de instância pequena: ≤ 2 GiB para as versões 3.04 e 3.05. ≤ 4 GiB para a versão 3.06 e posterior.
Limite de instância grande: ≤ 2 GiB para as versões 3.04 e 3.05. > 4 GiB para a versão 3.06 e posterior.
| Versão | Tamanho da instância | Provisionada | Sem Servidor v2 |
|---|---|---|---|
| Aurora MySQL 3.04-Aurora MySQL 3.05 | Pequena | print,tune | print |
| Grande | desabilitado | desabilitado | |
| Aurora MySQL 3.06 | Pequena | print,tune,decline,kill_connect | print |
| Grande | desabilitado | desabilitado | |
| Aurora MySQL 3.07 | Pequena | print,tune,decline,kill_connect | print |
| Grande | print | print | |
| Aurora MySQL 3.08 | Pequena | print,tune,tune_buffer_pool,decline,kill_connect | print |
| Grande | print | print | |
| Aurora MySQL 3.09-Aurora MySQL 3.10 | Pequena | print,tune,tune_buffer_pool,decline,kill_connect | print |
| Grande | print,decline,kill_connect | print,decline,kill_connect | |
| Aurora MySQL 3.11 e posterior | Pequena | print,tune,tune_buffer_pool,decline,kill_connect | print,decline,kill_connect |
| Grande | print,decline,kill_connect | print,decline,kill_connect |
Aurora Serverless v2
Não é possível realizar as ações tune e tune_buffer_pool no Aurora Sem Servidor v2. Todas as outras ações funcionam da mesma forma que nas instâncias provisionadas.
Os limites de memória se ajustam dinamicamente à medida que a instância escala as respectivas ACUs. A coluna Sem Servidor v2 na tabela de padrões acima mostra os padrões efetivos para cada versão.
Monitoramento
É possível monitorar a atividade de precaução de OOM por meio dos métodos a seguir.
Log de erros
Quando são realizadas ações de recuperação de memória, o Aurora MySQL grava mensagens no log de erros do banco de dados. O prefixo da mensagem varia de acordo com a versão e pode mudar em versões futuras:
Aurora MySQL versão 3: as mensagens são prefixadas com
OOM crash avoidance:.Aurora MySQL versão 8.4: as mensagens são prefixadas com
Aurora memory management:.
Essas mensagens incluem:
Pressão de memória detectada e recuperada: notificações com memória total e disponível.
Detalhes de consultas ou conexões encerradas para recuperação de memória.
Consultas candidatas identificadas pela ação
print.
Para visualizar o log de erros, consulte Logs de erro do Aurora MySQL.
Métricas do Amazon CloudWatch
As métricas do CloudWatch a seguir rastreiam a atividade de precaução de OOM em nível de instância.
| Métrica | Descrição | Disponível a partir de | Unidade |
|---|---|---|---|
AuroraMemoryHealthState | Indica o estado de integridade da memória. 0 significa íntegro (sem pressão de memória), 5 significa pressão de memória moderada e 10 significa pressão grave de memória. | Aurora MySQL 3.06.1 e posterior, Aurora MySQL 8.4 | Indicador |
AuroraMemoryNumDeclinedSqlTotal | O número incremental de consultas recusadas como parte de uma tentativa de evitar OOM. | Aurora MySQL 3.06.1 e posterior, Aurora MySQL 8.4 | Contagem |
AuroraMemoryNumKillConnTotal | O número incremental de conexões fechadas como parte de uma tentativa de evitar o OOM. | Aurora MySQL 3.06.1 e posterior, Aurora MySQL 8.4 | Contagem |
AuroraMemoryNumKillQueryTotal | O número incremental de consultas encerradas como parte de uma tentativa de evitar OOM. | Aurora MySQL 3.06.1 e posterior, Aurora MySQL 8.4 | Contagem |
AuroraMillisecondsSpentInOomRecovery | O tempo decorrido desde que a integridade da memória caiu abaixo do estado normal. | Aurora MySQL 3.08.0 e posterior, Aurora MySQL 8.4 | Milissegundos |
AuroraNumOomRecoverySuccessful | O número de vezes em que a integridade da memória foi restaurada ao estado normal. | Aurora MySQL 3.08.0 e posterior, Aurora MySQL 8.4 | Contagem |
AuroraNumOomRecoveryTriggered | O número de vezes em que a integridade da memória caiu abaixo do estado normal. | Aurora MySQL 3.08.0 e posterior, Aurora MySQL 8.4 | Contagem |
As seguintes métricas gerais do CloudWatch também são úteis para monitorar a pressão da memória:
| Métrica | Descrição | Unidade |
|---|---|---|
FreeableMemory | A quantidade de memória disponível. Relata o valor MemAvailable de /proc/meminfo. | Bytes |
SwapUsage | A quantidade de espaço de troca usada. | Bytes |
Para ver a lista completa de métricas em nível de instância do Aurora MySQL, consulte Métricas no nível da instância do Amazon Aurora.
Variáveis de status globais
As variáveis de status a seguir fornecem informações sobre o estado OOM (sem memória). Disponível no Aurora MySQL versão 3.06.0 e posterior.
| Variável | Descrição |
|---|---|
Aurora_oom_response | As ações de resposta a OOM no momento ativas para essa instância de banco de dados. |
aurora_oom_avoidance_recovery_state | Se a recuperação de OOM é ACTIVE ou INACTIVE. |
aurora_oom_status | Estado atual da integridade da memória do banco de dados: íntegra (sem pressão de memória), pressão de memória moderada ou pressão grave de memória. Disponível somente na versão 3. |
Para consultar: SHOW GLOBAL STATUS LIKE 'aurora_oom%';.
Para ver a lista completa de variáveis de status globais do Aurora MySQL, consulte Variáveis de status globais do Aurora MySQL.
Insights de Performance
Se o Insights de Performance estiver habilitado, você poderá usar métricas de memória no nível do sistema operacional para monitorar a pressão de memória e detectar eventos de OOM. As seguintes métricas estão disponíveis nos contadores os.memory e os.swap:
| Métrica | Descrição |
|---|---|
os.memory.outOfMemoryKillCount | O número de encerramentos OOM durante o último intervalo de coleta. Um valor diferente de zero indica que o sistema operacional encerrou um processo devido a esgotamento de memória, o que normalmente resulta na reinicialização do banco de dados. |
os.memory.total | A quantidade total de memória, em kilobytes. |
os.memory.free | A quantidade de memória não atribuída, em kilobytes. |
os.memory.active | A quantidade de memória atribuída, em kilobytes. |
os.memory.cached | A quantidade de memória utilizada para o armazenamento em cache da E/S no sistema de arquivos, em quilobytes. |
os.memory.dirty | A quantidade de páginas de memória modificadas, mas ainda não gravadas no armazenamento, em quilobytes. |
os.memory.inactive | A quantidade de páginas de memória usadas com menos frequência, em kilobytes. |
os.memory.db.residentSetSize | A quantidade de memória usada pelo processo de banco de dados (excluindo a memória compartilhada), em bytes. |
os.memory.db.cache | A quantidade de memória usada para cache de página pelo processo do banco de dados, em bytes. |
os.memory.db.swap | A quantidade de memória de troca usada pelo processo do banco de dados, em bytes. |
os.swap.in | A quantidade de memória transferida do disco, em quilobytes. |
os.swap.out | A quantidade de memória transferida para o disco, em quilobytes. |
É possível monitorar os.memory.outOfMemoryKillCount para detectar quando o sistema operacional encerrou o processo do banco de dados devido à falta de memória. Para ver a lista completa de contadores de sistema operacional, consulte Métricas de sistema operacional do Insights de Performance.
Performance Schema
Se performance_schema estiver habilitado, você poderá usar tabelas de resumo de memória para identificar quais componentes e conexões estão consumindo mais memória. Para obter mais informações, consulte Solução de problemas de uso de memória para bancos de dados Aurora MySQL.
