Otimizar uso alto de memória em instâncias

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

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

Identificar o uso elevado da memória

Usar o Metrics Explorer para identificar o uso da memória

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

Usar Query Insights para analisar o plano de explicação de consultas que consomem muitos recursos

O Query Insights ajuda a detectar, diagnosticar e evitar problemas de desempenho relacionados aos bancos de dados do Cloud SQL. O Query Insights oferece uma lista de consultas de longa duração com o plano de explicação (documentação do PostgreSQL). Revise o plano de explicação e identifique a parte da consulta que tem um método de verificação de alto uso da memória. Independentemente do ambiente de execução da consulta, o Query Insights apresenta 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 durações maiores.

Os métodos comuns de verificação do PostgreSQL que usam muita memória incluem:

Verificação de heap de bitmap
Classificação rápida
Hash ou mesclagem de hash

Alto uso da memória e registros relevantes para instâncias com o Gemini ativado

Se o Gemini estiver ativado, em vez de uma falha por falta de memória (OOM, na sigla em inglês), que leva à inatividade do banco de dados, uma conexão que executa uma consulta com alto uso da memória será encerrada, evitando a inatividade do banco de dados. Para identificar a consulta padrão, verifique os registros do banco de dados quanto às seguintes entradas:

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

O seguinte registro do banco de dados do Cloud SQL para PostgreSQL é exibido e captura a consulta de alto uso da memória que foi encerrada para evitar 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.

Na página Instâncias do Cloud SQL, as notificações dos eventos a seguir também são exibidas:

Uso da 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 como otimizar o uso da memória.

Uso de memória alto: recomendações

As recomendações a seguir abordam os problemas comuns relacionados à memória. Se a instância continuar usando uma quantidade alta de memória, isso terá uma chance alta de acabar causando 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 do kernel Out of Memory nos registros do PostgreSQL e a instância do PostgreSQL será interrompida. Exemplo:

Out of Memory: Killed process 12345 (postgres)

A instância mais comum com um problema de OOM é quando há um valor maior de work_mem com um número alto de conexões ativas. Portanto, se você encontrar OOMs frequentes ou quiser evitar OOMs na sua instância do Cloud SQL para PostgreSQL, siga estas recomendações:

Definir work_mem

As consultas que usam a ordenação rápida são mais velozes do que aquelas que usam a ordenação de fusão externa. No entanto, a primeira pode levar ao esgotamento da memória. Para resolver esse problema, defina o valor work_mem razoável o suficiente para equilibrar as duas operações de ordenação que acontecem na memória e no disco. Considere também definir a work_mem no nível da sessão, em vez de defini-la para uma instância inteira.
Monitorar as sessões ativas

Cada conexão usa uma certa quantidade de memória. Use a consulta a seguir 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 número grande de sessões ativas, analise a causa raiz desse número alto, como bloqueios de transação.
Definir shared_buffers

Se shared_buffers for definido com um valor maior, diminua 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.

Proporção de ocorrência em cache

Em geral, o PostgreSQL tenta manter no cache os dados acessados com mais frequência. Quando os dados forem solicitados por um cliente, se eles já estiverem armazenados em cache com buffers compartilhados, eles serão fornecidos diretamente ao cliente. Isso é chamado de ocorrência em cache. Se os dados não estiverem presentes em buffers compartilhados, primeiro eles serão buscados em buffers compartilhados de um disco e, em seguida, fornecidos ao cliente. Isso é chamado de ausência no cache. A proporção de ocorrência em cache mede quantas solicitações de conteúdo o cache processou em comparação com as solicitações recebidas. Execute a consulta a seguir para verificar a proporção de ocorrência em cache em relação às 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 consulta a seguir para verificar a proporção de ocorrência em cache em relação às 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, uma proporção de ocorrência em cache com valor de 95 a 99% é considerada boa.
Ativar páginas enormes Por padrão, o Cloud SQL para PostgreSQL tem huge_pages ativado para melhorar o gerenciamento de memória. Recomendamos que você o ative. Para saber mais sobre o huge_pages, consulte a documentação do PostreSQL.
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á ter OOMs. Considere aumentar o valor de max_locks_per_transaction alto o suficiente para evitar OOMs.

Observação: o bloqueio no nível do objeto ocorre na memória em uma transação em andamento. Aumentar o valor de max_prepared_transactions muito alto pode fazer com que a instância do banco de dados solicite mais memória compartilhada.

O valor de max_locks_per_transaction precisa 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, max_locks_per_transaction será 1.500.
Definir max_pred_locks_per_transaction

A transação pode falhar quando você tem clientes que usam várias 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 a memória compartilhada. Portanto, não defina um valor excessivamente alto.
Se o uso da memória ainda for alto e você achar que as consultas são tráfego legítimo, considere aumentar o número de recursos de memória na sua instância para evitar falha ou inatividade do banco de dados.