Solucionar problemas de falta de memória em bancos de dados do Aurora MySQL - Amazon Aurora

Solucionar problemas de falta de memória em bancos de dados do Aurora MySQL

O parâmetro de nível de instância aurora_oom_response do Aurora MySQL pode habilitar a instância de banco de dados a monitorar a memória de sistema consumida por várias instruções e conexões. Se o sistema estiver com pouca memória, ele poderá executar uma lista de ações para tentar liberar essa memória. Ele faz isso em uma tentativa de evitar uma reinicialização do banco de dados devido a problemas de falta de memória (OOM). O parâmetro no nível da instância usa uma string de ações separadas por vírgula que uma instância de banco de dados realiza quando sua memória está baixa. O parâmetro aurora_oom_response é compatível com o Aurora MySQL versões 2 e 3.

Os valores a seguir e as combinações deles podem ser usados para o parâmetro aurora_oom_response. Uma string vazia significa que não há ações a serem realizadas e desativa efetivamente o recurso, deixando o banco de dados propenso a reinicializações de OOM.

  • decline: recusa novas consultas quando a instância de banco de dados tem pouca memória.

  • kill_connect: fecha as conexões de banco de dados que estão consumindo grande quantidade de memória e encerra as transações atuais e as declarações de linguagem de definição de dados (DDL). Essa resposta não é compatível com o Aurora MySQL versão 2.

    Consulte mais informações em KILL statement na documentação do MySQL.

  • kill_query: encerra as consultas em ordem decrescente de consumo da memória até a memória da instância superar o limite mínimo. As instruções DDL não são encerradas.

    Consulte mais informações em KILL statement na documentação do MySQL.

  • print: imprime apenas as consultas que consomem uma grande quantidade de memória.

  • tune – ajusta os caches de tabela internos para liberar parte da memória de volta para o sistema. O Aurora MySQL diminui a memória usada para caches, como table_open_cache e table_definition_cache em condições de pouca memória. Por fim, o Aurora MySQL define seu uso de memória de volta ao normal quando o sistema deixa de ter pouca memória.

    Consulte mais informações em table_open_cache e table_definition_cache na documentação do MySQL.

  • tune_buffer_pool: diminui o tamanho do pool de buffer para liberar alguma memória e disponibilizá-la para o servidor de banco de dados processar conexões. Essa resposta é compatível com o Aurora MySQL versão 3.06 e posterior.

    É necessário emparelhar tune_buffer_pool com kill_query ou kill_connect no valor do parâmetro aurora_oom_response. Caso contrário, o redimensionamento do pool de buffer não ocorrerá, mesmo quando você incluir tune_buffer_pool no valor do parâmetro.

Nas versões do Aurora MySQL anteriores à 3.06, para classes de instância de banco de dados com memória menor ou igual a 4 GiB, quando a instância está sob pressão de memória, as ações padrão incluem print, tune, decline e kill_query. Para classes de instância de banco de dados com memória maior que 4 GiB, o valor do parâmetro ficará vazio por padrão (desabilitado).

No Aurora MySQL versão 3.06 e posterior, para classes de instância de banco de dados com memória menor ou igual a 4 GiB, o Aurora MySQL também fecha as conexões que mais consomem memória (kill_connect). Em relação a classes de instância de banco de dados com memória maior que 4 GiB, o valor do parâmetro padrão é print.

Se você costuma ter problemas de falta de memória, o uso da memória pode ser monitorado usando tabelas de resumo de memória quando performance_schema estiver habilitado.

Em relação a métricas do Amazon CloudWatch relacionadas a OOM, consulte Métricas no nível da instância do Amazon Aurora. Em relação a variáveis de status global relacionadas a OOM, consulte Variáveis de status globais do Aurora MySQL.