Como posso solucionar problemas de pouca memória livre em um banco de dados do Amazon RDS para MySQL?

9 minuto de leitura
0

Estou executando uma instância do Amazon Relational Database Service (Amazon RDS) para MySQL. Vejo que minha memória disponível está baixa, meu banco de dados sem memória ou pouca memória está causando problemas de latência em minha aplicação. Como identifico a origem da utilização da memória e como posso solucionar problemas de pouca memória livre?

Breve descrição

No Amazon RDS para MySQL, você pode monitorar quatro status de memória:

  • Ativo: a memória que está sendo ativamente consumida pelos processos ou threads do banco de dados.
  • Buffer: um buffer é um espaço temporário na memória usado para armazenar um bloco de dados.
  • Memória livre: a memória que está disponível para uso.
  • Cache: o armazenamento em cache é uma técnica em que os dados são armazenados temporariamente na memória, permitindo a recuperação rápida dos dados.

Por padrão, quando você cria uma instância do Amazon RDS para MySQL, buffers e caches são alocados para melhorar as operações do banco de dados. O Amazon RDS para MySQL também tem um componente de memória interna (como key_buffers_size or query_cache_size) que cria tabelas temporárias internas para realizar determinadas operações.

Ao usar o Amazon RDS para MySQL, certifique-se de entender como o MySQL utiliza e aloca memória. Depois de identificar os componentes que estão usando memória, você pode procurar gargalos no nível da instância e do banco de dados. Em seguida, monitore essas métricas específicas e configure suas sessões para um desempenho ideal.

Resolução

Como o MySQL utiliza a memória

No Amazon RDS para MySQL, 80% a 90% da memória disponível em uma instância é alocada com os parâmetros padrão. Essa alocação é ideal para desempenho, mas se você definir parâmetros que usam mais memória, modifique outros parâmetros para usar menos memória para compensar.

Você pode calcular o uso aproximado de memória para sua instância de banco de dados RDS para MySQL da seguinte forma:

Maximum MySQL Memory Usage = innodb_buffer_pool_size + key_buffer_size + ((read_buffer_size + read_rnd_buffer_size + sort_buffer_size + join_buffer_size) X max_connections)

Grupos de buffer

Os buffers e caches globais incluem componentes como Innodb_buffer_pool_size, Innodb_log_buffer_size, key_buffer_size e query_cache_size. O parâmetro innodb_buffer_pool_size é a área de memória da RAM em que o innodb armazena em cache as tabelas do banco de dados e os dados relacionados ao índice. Um grupo de buffers maior requer menos operação de E/S desviada de volta para o disco. Por padrão, o innodb_buffer_pool_size utiliza no máximo 75% da memória disponível alocada para a instância de banco de dados do Amazon RDS:

innodb_buffer_pool_size = {DBInstanceClassMemory*3/4}

Certifique-se de revisar esse parâmetro primeiro para identificar a origem do uso da memória. Em seguida, considere reduzir o valor de innodb_buffer_pool_size modificando o valor do parâmetro em seu grupo de parâmetros personalizado.

Por exemplo, o DBInstanceClassMemory*3/4 padrão pode ser reduzido para *5/8 ou *1/2. Certifique-se de que o valor BufferCacheHitRatio da instância não seja muito baixo. Se o valor BufferCacheHitRatio for baixo, talvez seja necessário aumentar o tamanho da instância para obter mais RAM. Para obter mais informações, consulte Melhores práticas para configurar parâmetros para o Amazon RDS para MySQL, parte 1: Parâmetros relacionados ao desempenho.

Threads do MySQL

A memória também é alocada para cada thread do MySQL conectado a uma instância de banco de dados do MySQL. Os seguintes threads exigem memória alocada:

  • thread_stack
  • net_buffer_length
  • read_buffer_size
  • sort_buffer_size
  • join_buffer_size
  • max_heap_table_size
  • tmp_table_size

Além disso, o MySQL cria tabelas temporárias internas para realizar algumas operações. Essas tabelas são criadas inicialmente como tabelas baseadas em memória. Quando as tabelas atingem o tamanho especificado por tmp_table_size ou max_heap_table_size (o que tiver o menor valor), a tabela será convertida em uma tabela baseada em disco. Quando várias sessões criam tabelas temporárias internas, você pode ver aumentos na utilização da memória. Para reduzir a utilização da memória, evite usar tabelas temporárias em suas consultas.

Observação: quando você aumenta os limites tmp_table_size e max_heap_table_size, tabelas temporárias maiores podem ficar na memória. Para confirmar se uma tabela temporária implícita foi criada, use a variável created_tmp_tables. Para obter mais informações sobre essa variável, consulte created_tmp_tables no site do MySQL.

Operações JOIN e SORT

O uso da memória aumentará se vários buffers do mesmo tipo, como join_buffer_size ou sort_buffer_size, forem alocados durante uma operação JOIN ou SORT. Por exemplo, o MySQL aloca um buffer JOIN para realizar JOIN entre duas tabelas. Se uma consulta envolver JOINs de várias tabelas e todas as consultas exigirem um buffer JOIN, o MySQL alocará um buffer JOIN a menos do que o número total de tabelas. Configurar suas variáveis de sessão com um valor muito alto pode causar problemas se as consultas não forem otimizadas. Você pode alocar a memória mínima para variáveis no nível da sessão, como join_buffer_size, join_buffer_size e sort_buffer_size. Para mais informações, consulte Trabalhar com grupos de parâmetros do banco de dados.

Se você realizar inserções em massa em tabelas MYISAM, serão usados bytes de memória de bulk_insert_buffer_size. Para obter mais informações, consulte Práticas recomendadas para trabalhar com mecanismos de armazenamento do MySQL.

O Performance Schema

A memória pode ser consumida pelo Performance Schema se você habilitou o Performance Schema para Performance Insights no Amazon RDS para MySQL. Quando o Performance Schema está ativado, o MySQL aloca buffers internos quando a instância é iniciada e durante as operações do servidor. Para obter mais informações sobre como o Performance Schema utiliza a memória, consulte a documentação do MySQL para o Modelo de alocação de memória do Performance Schema.

Junto com as tabelas do Performance Schema, você também pode usar o esquema sys do MySQL. Por exemplo, você pode usar o evento performance_schema para mostrar quanta memória está alocada para buffers internos usados pelo Performance Schema. Ou você pode executar uma consulta como essa para ver quanta memória está alocada:

SELECT * FROM performance_schema.memory_summary_global_by_event_name WHERE EVENT_NAME LIKE 'memory/performance_schema/%';

Os instrumentos de memória estão listados na tabela setup_instruments, seguindo o formato "memory/code_area/instrument_name". Para ativar a instrumentação de memória, atualize a coluna HABILITADO dos instrumentos relevantes na tabela setup_instruments:

UPDATE performance_schema.setup_instruments SET ENABLED = 'YES' WHERE NAME LIKE 'memory/%';

Monitoramento do uso de memória em sua instância

Métricas do Amazon CloudWatch

Monitore as métricas do Amazon CloudWatch para DatabaseConnections, CPUUtilization, ReadIOPS e WriteIOPS quando a memória disponível estiver baixa.

Para DatabaseConnections, é importante observar que cada conexão feita com o banco de dados precisa de uma certa quantidade de memória alocada a ela. Portanto, um pico nas conexões do banco de dados pode causar uma queda na memória que pode ser liberada. No Amazon RDS, o limite flexível para max_connections é calculado assim:

{DBInstanceClassMemory/12582880}

Monitore se você está excedendo esse limite flexível verificando a métrica DatabaseConnections no Amazon CloudWatch.

Além disso, verifique a pressão da memória monitorando as métricas do CloudWatch para SwapUsage, além de FreeableMemory. Se você perceber que uma grande quantidade de troca é usada e tem pouca FreeableMemory, sua instância pode estar sob alta pressão de memória. A alta pressão da memória afeta o desempenho do banco de dados. É uma prática recomendada manter os níveis de pressão da memória abaixo de 95%. Para obter mais informações, consulte Por que minha instância do Amazon RDS está usando memória de troca quando eu tenho memória suficiente?

Monitoramento avançado

Para monitorar a utilização de recursos em uma instância de banco de dados, ative o Monitoramento avançado. Em seguida, defina uma granularidade de um ou cinco segundos (o padrão é 60 segundos). Com o Monitoramento avançado, você pode monitorar a memória ativa e que pode ser liberada em tempo real.

Você também pode monitorar os threads que estão consumindo o máximo de CPU e memória listando os threads da sua instância de banco de dados:

mysql> select THREAD_ID, PROCESSLIST_ID, THREAD_OS_ID from performance_schema.threads;

Em seguida, mapeie o thread_OS_ID para o thread_ID:

select p.* from information_schema.processlist p, performance_schema.threads t
where p.id=t.processlist_id and t.thread_os_id=<Thread ID from EM processlist>;

Solução de problemas de pouca memória que pode ser liberada

Se você estiver enfrentando problemas de pouca memória que pode ser liberada, considere as seguintes dicas de solução de problemas:

  • Verifique se você tem recursos suficientes alocados em seu banco de dados para executar suas consultas. Com o Amazon RDS, a quantidade de recursos alocados depende do tipo de instância. Além disso, certas consultas, como procedimentos armazenados, podem consumir uma quantidade ilimitada de memória durante a execução.
  • Evite transações de longa duração dividindo consultas grandes em consultas menores.
  • Para visualizar todas as conexões e consultas ativas em seu banco de dados, use o comando SHOW FULL PROCESSLIST. Se você observar uma consulta de longa duração com operações JOIN ou SORTS, precisará de RAM suficiente para que o otimizador calcule o plano. Além disso, se você identificar uma consulta que precisa de uma tabela temporária, você deve ter memória adicional para alocar para a tabela.
  • Para visualizar transações de longa duração, estatísticas de utilização de memória e bloqueios, use o comando SHOW ENGINE INNODB STATUS. Examine a saída e verifique as entradas BUFFER POOL AND MEMORY. A entrada BUFFER POOL AND MEMORY fornece informações sobre alocação de memória para o InnoDB, como “Memória total alocada”, “Tabelas de hash internas” e “Tamanho do grupo de buffers”. O InnoDB Status também ajuda a fornecer informações adicionais sobre travas, bloqueios e deadlocks.
  • Se sua carga de trabalho frequentemente encontrar deadlocks, modifique o parâmetro innodb_lock_wait_timeout em seu grupo de parâmetros personalizados. O InnoDB depende da configuração innodb_lock_wait_timeout para reverter transações quando ocorre um deadlock.
  • Para otimizar o desempenho do banco de dados, certifique-se de que suas consultas estejam ajustadas adequadamente. Caso contrário, você poderá enfrentar problemas de desempenho e tempos de espera prolongados.
  • Use o Insights de Performance do Amazon RDS para ajudar você a monitorar instâncias de banco de dados e identificar qualquer consulta problemática.
  • Monitore as métricas do Amazon CloudWatch, como utilização de CPU, IOPS, memória e uso de troca, para que a instância não seja controlada.
  • Defina um alarme do CloudWatch na métrica FreeableMemory para que você receba uma notificação quando a memória disponível atingir 95%. É uma prática recomendada manter pelo menos 5% da memória da instância livre.
  • Atualize regularmente sua instância para uma versão secundária do MySQL mais recente. Versões secundárias mais antigas têm maior probabilidade de conter bugs relacionados a vazamentos de memória.

Informações relacionadas

Visão geral do monitoramento do Amazon RDS

Por que minha instância de banco de dados do Amazon RDS está usando memória de troca quando eu tenho memória suficiente?

AWS OFICIAL
AWS OFICIALAtualizada há 2 anos