Otimize o alto uso de memória em instâncias

Este documento aborda como identificar alto uso de memória para instâncias do Cloud SQL e fornece recomendações sobre como resolver problemas relacionados à memória.

Para saber como configurar o uso de memória para uma instância do Cloud SQL, consulte Práticas recomendadas para gerenciar o uso de memória .

Identificar alto uso de memória

As seções a seguir discutem cenários de alto uso de memória.

Use o Metrics Explorer para identificar o uso de memória

Você pode revisar o uso de memória da instância com a métrica database/memory/components.usage no Metrics Explorer .

Use o Query Insights para analisar e explicar o plano para consultas que consomem muitos recursos

O Query Insights ajuda a detectar, diagnosticar e prevenir problemas de desempenho de consultas em bancos de dados Cloud SQL. Ele fornece uma lista de consultas de longa execução, juntamente com o respectivo plano de explicação (documentação do PostgreSQL) . Revise o plano de explicação e identifique a parte da consulta que possui um método de varredura com alto uso de memória. Independentemente do tempo de execução da consulta, o Query Insights fornece o plano de explicação para todas as consultas. Identifique as consultas complexas que estão demorando mais para saber quais consultas estão bloqueando a memória por períodos mais longos.

Os métodos comuns de varredura do PostgreSQL que usam muita memória incluem o seguinte:

  • Varredura de heap de bitmap
  • Classificação rápida
  • Hash join ou Hash

Alto uso de memória e logs relevantes para instâncias habilitadas para Gemini

Se você tiver o Gemini habilitado, em vez de uma falha de falta de memória (OOM), que leva à inatividade do banco de dados, uma conexão que executa uma consulta com alto uso de memória é encerrada, evitando assim a inatividade do banco de dados. Para identificar a consulta padrão, você pode verificar os logs do banco de dados em busca das seguintes entradas:

  (...timestamp….) db=postgres, user=customer FATAL: terminating connection due to administrator command

O seguinte log do banco de dados Cloud SQL para PostgreSQL é exibido, capturando a consulta de alto uso de memória que foi encerrada para evitar o OOM. A consulta é uma versão normalizada da consulta original:

  db=postgres,user=customer LOG:  postgres process with PID 1734 for the query "SELECT COUNT(product) AS item_count FROM test_table WHERE product_type = $1 AND product LIKE $2 AND c6_2 IN ($3,$4,$5,$6,$7)" has been cancelled.

As notificações também são exibidas na página Instâncias do Cloud SQL para os seguintes eventos:

  • Utilização de memória da instância nas últimas 24 horas.
  • Lista de consultas normalizadas que foram canceladas nas últimas 24 horas.
  • Um link para a documentação do Google sobre otimização do uso de memória.

Alto uso de memória - Recomendações

As recomendações a seguir abordam os problemas comuns relacionados à memória. Se a instância continuar a usar uma quantidade alta de memória, é provável que ela acabe tendo um problema out of memory . Se as demandas de memória do PostgreSQL ou de outro processo fizerem com que o sistema fique sem memória, você verá uma mensagem de kernel Out of Memory nos logs do PostgreSQL e a instância do PostgreSQL será eventualmente interrompida. Por exemplo:

Out of Memory: Killed process 12345 (postgres)

O caso mais comum em que se observa um problema de OOM é com um valor mais alto de work_mem e um grande número de conexões ativas. Portanto, se você estiver enfrentando OOMs frequentes ou quiser evitá-los na sua instância do Cloud SQL para PostgreSQL, considere seguir estas recomendações:

  • Definir work_mem

    Consultas que usam ordenação rápida são mais rápidas do que aquelas que usam ordenação por mesclagem externa. No entanto, a primeira opção pode levar ao esgotamento da memória. Para resolver esse problema, defina o valor work_mem como razoável o suficiente para equilibrar as operações de ordenação que ocorrem na memória e no disco. Você também pode considerar definir work_mem no nível da sessão em vez de defini-lo para uma instância inteira.

  • Monitore as sessões ativas

    Cada conexão utiliza uma determinada quantidade de memória. Use a seguinte consulta para verificar a contagem de conexões ativas:

      SELECT
    state,
    usename,
    count(1)
  FROM
    pg_stat_activity
  WHERE
    pid <> pg_backend_pid()
  GROUP BY
    state,
    usename
  ORDER BY
    1;

    Se você tiver um grande número de sessões ativas, analise a causa raiz desse alto número; por exemplo, bloqueios de transações.

  • Definir shared_buffers

    Se shared_buffers for definido como um valor mais alto, considere diminuir o valor de shared_buffers para que a memória possa ser usada para outras operações, como work_mem , ou para estabelecer novas conexões.

    Taxa de acerto do cache

    O PostgreSQL geralmente tenta manter os dados que você acessa com mais frequência no cache. Quando os dados são solicitados por um cliente, se já estiverem armazenados em cache em buffers compartilhados, eles são fornecidos diretamente ao cliente. Isso é chamado de acerto de cache . Se os dados não estiverem presentes em buffers compartilhados, eles serão primeiro buscados em buffers compartilhados de um disco e, em seguida, fornecidos ao cliente. Isso é chamado de erro de cache . A taxa de acerto de cache mede quantas solicitações de conteúdo o cache processou em comparação com as solicitações recebidas. Execute a seguinte consulta para verificar a taxa de acerto de cache para as solicitações de tabela na instância do PostgreSQL:

    SELECT
  sum(heap_blks_read) as heap_read,
  sum(heap_blks_hit)  as heap_hit,
  sum(heap_blks_hit) / (sum(heap_blks_hit) + sum(heap_blks_read)) as ratio
FROM
  pg_statio_user_tables;

    Execute a seguinte consulta para verificar a taxa de acertos do cache para as solicitações de índice na instância do PostgreSQL:

      SELECT
    sum(idx_blks_read) as idx_read,
    sum(idx_blks_hit)  as idx_hit,
    (sum(idx_blks_hit) - sum(idx_blks_read)) / sum(idx_blks_hit) as ratio
  FROM
    pg_statio_user_indexes;

    Geralmente, 95 a 99% de taxa de acerto de cache é considerado um bom valor.

  • Habilitar páginas enormes: O Cloud SQL para PostgreSQL tem huge_pages habilitado por padrão para melhor gerenciamento de memória. Recomendamos que você o habilite. Para saber mais sobre huge_pages , consulte a documentação do PostgreSQL .

  • Definir max_locks_per_transaction

    O valor max_locks_per_transaction indica o número de objetos do banco de dados que podem ser bloqueados simultaneamente. Na maioria dos casos, o valor padrão de 64 é suficiente. No entanto, se você estiver lidando com um conjunto de dados grande, poderá acabar com excesso de tarefas (OOMs). Considere aumentar o valor de max_locks_per_transaction para um valor alto o suficiente para evitar OOMs.

    O valor de max_locks_per_transaction deve ser max_locks_per_transaction * ( max_connections + max_prepared_transactions ) objetos. Isso significa que, se você tiver 300 mil objetos e o valor de max_connections for 200, então max_locks_per_transaction deverá ser 1500.

  • Definir max_pred_locks_per_transaction

    A transação pode falhar se você tiver clientes que acessam muitas tabelas diferentes em uma única transação serializável. Nesse cenário, considere aumentar max_pred_locks_per_transaction para um valor razoavelmente alto. Assim como max_locks_per_transaction , max_pred_locks_per_transaction também usa memória compartilhada, portanto, não defina um valor excessivamente alto.

  • Se o uso de memória ainda estiver alto e você achar que essas consultas são tráfego legítimo, considere aumentar o número de recursos de memória na sua instância para evitar falhas ou tempo de inatividade do banco de dados.

O que vem a seguir