Alterando sua configuração de Databases for PostgreSQL

IBM Cloud® Databases for PostgreSQL configurações de fuso horário

O fuso horário para implementações IBM Cloud® Databases for PostgreSQL é sempre UTC (Coordenado Universal Time). Essa configuração não é configurável pelos clientes.

IBM Cloud® Databases for PostgreSQL configurações de memória

shared_buffers

• Padrão - 32000 (número de buffers de 8 KiB ou cerca de 262 MB)
• Valor máximo recomendado: 25% de RAM disponível
• Reinicia o banco de dados? - Sim

A alocação de memória recomendada para shared_buffers é 25% da RAM da implementação. Definir shared_buffers um valor mais alto pode resultar em problemas de memória que causam a falha do banco de dados e podem diminuir o desempenho do seu banco de dados, pois os dados provavelmente já estão armazenados no buffer pelo sistema operacional. Definir shared_buffers como igual, próximo de igual ou superior à quantidade de memória alocada impede que o banco de dados seja iniciado. A configuração especifica o número de buffers de memória compartilhada de 8 KiB.

Por exemplo, 1 GB de espaço de shared_buffers é 1048576 KiB e (1048576 KiB / 8 KiB) são 131072 buffers. Sua implementação pode usar RAM adicional para o armazenamento em cache e o desempenho, mesmo sem alocá-la para shared_buffers. Não é necessário configurar o banco de dados para usar toda a RAM alocada para uso de sua implementação.

Para as cargas de trabalho existentes ou durante o ajuste de escala de RAM, o aumento de memória para buffers compartilhados pode não ser o melhor curso de ação. Em vez disso, rastreie as taxas de acertos do cache de índice e de tabela. Se as taxas de acerto do cache estiverem na casa dos 90%, deixe o sistema operacional usar a memória em outras áreas, em vez de aumentá-la shared_buffers.

É possível usar essas consultas como o usuário admin ou como qualquer outro que tenha a função pg_monitor para rastrear as taxas de acertos do cache:

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 table_hit_ratio
FROM
  pg_statio_user_tables;

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 index_hit_ratio
FROM
pg_statio_user_indexes;

IBM Cloud® Databases for PostgreSQL configurações gerais

max_connections

• Padrão - 115
• Reinicia o banco de dados? - SIM
• Notas - Talvez seja necessário escalar antes de aumentar as conexões máximas.

max_locks_per_transaction

• Padrão-64
• Opções - Valor mínimo de 10
• Reinicia o banco de dados? - SIM

max_prepared_transactions

• Padrão - 50
• Reinicia o banco de dados? - SIM
• Observações - Definir o valor como 0 desativa o uso de transações preparadas e é recomendado, a menos que você precise usá-las.

synchronous_commit

• Padrão - local
• Reinicia o banco de dados - Não
• Opções - local, on ou off
• Notas - configurar synchronous_commit como Off aumenta a taxa de confirmação da transação em detrimento de uma perda de transações confirmadas caso ocorra um encerramento anormal. Com o synchronous_commit configurado como on, uma transação é confirmada apenas quando gravada no líder e em pelo menos uma réplica. Por isso, a configuração do on está disponível apenas em formações que foram submetidas a um ajuste de escala horizontal para pelo menos três membros. Antes de implementar essa alteração, consulte Alta disponibilidade.

effective_io_concurrency

• Padrão - 12
• Reinicia o banco de dados - Não
• Notas - Recomenda-se deixar essa configuração no padrão. Aumente-a apenas se você tiver feito o perfil de consultas SQL e tiver observado varreduras de heap de bitmap ineficientes. Como o IOPS está vinculado ao tamanho do disco, também não é recomendável aumentar essa configuração em discos padrão ou de tamanho menor.

deadlock_timeout

• Padrão - 10000
• Reinicia o banco de dados - Não
• Opções - Valor mínimo de 100
• Notas - O número de milissegundos que se deve esperar antes de verificar o conflito e a duração na qual as esperas de bloqueio são registradas. Logs disponíveis por meio da integração de criação de log. Configurar esse número com um valor muito baixo afeta negativamente o desempenho.

log_connections

• Padrão - off
• Reinicia o banco de dados - Não
• Opções - Valores de on ou off
• Notas - Definir este valor como on torna os registros detalhados. Ela também mostra as conexões da ferramenta de monitoramento à medida que extrai métricas a cada 60 segundos. Quando configurado como on, recomenda-se configurar o application_name no URI de conexão para manter uma visão geral nos logs, já que os endereços IP mostrados são os IPs internos do Kubernetes. Detalhes sobre como ajustar o URI de conexão podem ser encontrados na documentação PostgreSQL. Se configurado como off, não haverá mudança no comportamento da configuração padrão e nenhuma conexão será registrada. Os logs estão disponíveis por meio da integração de criação de log. Se on estiver configurado, os logs mostrarão linhas semelhantes a este exemplo, em que o nome do aplicativo é configurado como test-app:

2021-03-01 10:27:56 UTC [[unknown]] [00000] [708]: [2-1] user=admin,db=ibmclouddb,client=127.0.0.1 LOG:  connection authorized: user=admin database=ibmclouddb application_name=test-app SSL enabled (protocol=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384, bits=256, compression=off)

log_disconnections

• Padrão - off
• Reinicia o banco de dados - Não
• Opções - Valores de on ou off
• Notas - Definir este valor como on torna os registros detalhados. Ele também mostrará as desconexões das ferramentas de monitoramento, pois extrai métricas a cada 60 segundos. Quando configurado como on, recomenda-se configurar o application_name no URI de conexão para manter uma visão geral nos logs, já que os endereços IP mostrados são os IPs internos do Kubernetes. Detalhes sobre como ajustar o URI de conexão podem ser encontrados na documentação PostgreSQL. Se configurado como off, não haverá mudança no comportamento da configuração padrão e nenhuma desconexão será registrada. Os logs estão disponíveis por meio da integração de criação de log. Se on estiver configurado, os logs mostrarão linhas semelhantes a este exemplo, em que o nome do aplicativo é configurado como test-app:

2021-03-01 10:27:56 UTC [test-app] [00000] [708]: [3-1] user=admin,db=ibmclouddb,client=127.0.0.1 LOG:  disconnection: session time: 0:00:00.793 user=admin database=ibmclouddb host=127.0.0.1 port=50638

log_min_duration_statement

• Padrão - 100
• Reinicia o banco de dados - Não
• Opções - Valor mínimo de 100
• Notas - As instruções que demoram mais tempo que o número especificado de milissegundos são registradas.

tcp_keepalives_idle

• Padrão - 111
• Reinicia o banco de dados - Não

tcp_keepalives_interval

• Padrão - 15
• Reinicia o banco de dados - Não

tcp_keepalives_count

• Padrão - 6
• Reinicia o banco de dados - Não

IBM Cloud® Databases for PostgreSQL Configurações de WAL

archive_timeout

• Padrão - 1800
• Reinicia o banco de dados - Não
• Opções - Valor mínimo de 300
• Notas - O número de segundos que se deve esperar antes de forçar uma alternância para o próximo arquivo WAL. Se o número de segundos tiver passado e tiver havido atividade do banco de dados, o servidor será alternado para um novo segmento. Limita efetivamente o período de tempo que os dados podem permanecer desarquivados.

As próximas três configurações (wal_level, max_replication_slots e max_wal_senders) permitem o uso do plug-in de decodificação lógica wal2json. Se você não estiver usando este plug-in, deixe essas configurações no padrão.

wal_level

• Padrão - replica
• Reinicia o banco de dados - SIM
• Notas - Controla o nível de WAL. Os valores permitidos são replica ou logical. Defina como logical para usar a decodificação lógica. Se você não estiver usando a decodificação lógica, usar logical aumentará o tamanho de WAL, que tem várias desvantagens e nenhuma vantagem real.

max_replication_slots

• Padrão - 10
• Reinicia o banco de dados - SIM
• Notas - O número máximo de slots de replicação definidos simultaneamente. O número padrão e o mínimo de slots é 10. Sua implementação reserva 20 slots para uso interno para propósitos de alta disponibilidade (HA). Para usar slots, é necessário configurar o valor acima de 20 e ter um slot por consumidor. Adicione um slot extra sobre o mínimo por consumidor esperado. Usar wal2json e não aumentar max_replication_slots pode afetar a alta disponibilidade e as réplicas somente leitura. Se você não estiver usando wal2json, deixe essa configuração como padrão.

max_wal_senders

• Padrão - 12
• Reinicia o banco de dados - SIM
• Notas - O número máximo de processos do emissor WAL em execução simultânea. O padrão, e mínimo, é 12. É necessário um wal_sender por consumidor. Sua implementação reserva 20 slots para uso interno para propósitos de alta disponibilidade (HA). Você precisa definir o valor acima de 20 e é recomendável adicionar mais um wal_sender acima do mínimo por consumidor esperado. Usar wal2json e não aumentar max_wal_senders pode afetar a alta disponibilidade e as réplicas somente leitura. Se você não estiver usando wal2json, deixe essa configuração como padrão.