← Voltar ao blog

Planejador de capacidade PostgreSQL

Tuning PostgreSQL que respeita concorrência

Mais que presets: modele memória de work_mem sob carga, WAL, I/O, paralelismo e o ponto em que pooling é obrigatório.

1. Infraestrutura real

Use o limite de memória do container/VM.

2. Concorrência, não sockets

work_mem é calculado contra queries ativas.

3. Revisão antes de aplicar

Compare com pg_settings e EXPLAIN.

Versão, ambiente e carga

Capacidade e concorrência

Os valores abaixo controlam o orçamento e não substituem a observação de métricas reais.

Catálogo de tuning

Recomendações por parâmetro

O advisor sugere todos os grupos de GUCs de alto impacto. Itens de topologia, como slots e senders, devem ser confirmados contra a arquitetura real antes da aplicação.

work_mem

É o parâmetro mais perigoso de aumentar sem modelar operações e concorrência. Não use max_connections como sinônimo de queries pesadas simultâneas.

WAL & checkpoints

Mais WAL reduz pressão de checkpoints, mas exige capacidade de disco e atenção ao RPO. O plano ajusta o ponto inicial pela RAM e intensidade de escrita.

I/O & planner

effective_cache_size não reserva memória. Ele informa ao planner a expectativa de cache. random_page_cost e effective_io_concurrency precisam refletir o armazenamento real.

Do cálculo à operação real

Uma calculadora mostra o risco. O PG Monitoring mostra quando ele está acontecendo.

Use este plano como ponto de partida. Depois, conecte seu PostgreSQL para validar a configuração contra carga real, concorrência, I/O, WAL, autovacuum e comportamento das queries — continuamente, não apenas no dia do tuning.

Diagnóstico assistido: não solicitamos senha nem connection string por formulário, e-mail ou WhatsApp.

O que o SaaS acompanha no PostgreSQL

  • Memória, conexões, waits, I/O e saúde em tempo real
  • Queries lentas, planos, arquivos temporários e regressões
  • Autovacuum, bloat, locks, replicação e risco operacional
  • Recomendações de configuração com contexto de workload
  • Alertas e histórico para provar se a mudança melhorou

Perguntas frequentes

work_mem é por conexão?+

Não. work_mem é um limite por operação de sort ou hash, e uma query pode usar várias operações, workers paralelos e sessões concorrentes ao mesmo tempo.

effective_cache_size aloca memória?+

Não. É uma estimativa para o planner sobre cache disponível no PostgreSQL e no sistema operacional.

Por que não aumentar max_connections?+

Muitas conexões aumentam memória e contenção. Para grandes populações de clientes, PgBouncer normalmente é mais seguro do que elevar max_connections.

shared_buffers deve usar toda a RAM?+

Não. PostgreSQL depende do page cache do sistema operacional. Em hosts dedicados, 25% é um ponto inicial comum e valores acima de 40% raramente são o melhor ponto de partida.

Baseado na documentação oficial de consumo de recursos PostgreSQL. As sugestões são pontos iniciais: valide com pg_settings, pg_stat_database, pg_stat_statements, EXPLAIN (ANALYZE, BUFFERS) e métricas do host.

Fale conosco