Gerador de Configuração PostgreSQL Online

Como funciona o cálculo de tuning do PostgreSQL

A calculadora segue as recomendações da documentação oficial e da comunidade PostgreSQL para determinar cada parâmetro.

Memória: shared_buffers, effective_cache_size e work_mem

O shared_buffers é configurado como 25% da RAM total, conforme recomendado pela documentação oficial do PostgreSQL. Valores maiores podem causar contenção com o cache do sistema operacional. O effective_cache_size (75% da RAM) orienta o query planner sobre quanta memória está disponível para cache, influenciando a escolha entre index scan e sequential scan.

O work_mem é calculado dividindo a memória restante pelo número de conexões multiplicado por um fator de segurança (3x para OLTP, 1.5x para Data Warehouse), evitando que operações simultâneas de sort e hash consumam toda a RAM.

Disco: random_page_cost e effective_io_concurrency

Em servidores com SSD ou NVMe, o random_page_cost cai de 4.0 para 1.1 porque leituras aleatórias são quase tão rápidas quanto sequenciais. Isso faz o planner preferir index scans. O effective_io_concurrency sobe para 200 em SSDs, permitindo ao PostgreSQL disparar múltiplas leituras em paralelo.

Conexões e paralelismo

Aplicações Web/OLTP tipicamente precisam de mais conexões (200) com menos work_mem por conexão, enquanto Data Warehouses usam menos conexões (40) com mais memória por query. O número de parallel workers é calculado com base nos CPUs disponíveis, limitado a 8 workers conforme a prática recomendada.

Guia de parâmetros do postgresql.conf

Referência rápida de cada parâmetro calculado por esta ferramenta de tuning PostgreSQL.

`shared_buffers`

Memória dedicada ao cache interno do PostgreSQL. 25% da RAM total é o ponto de equilíbrio entre performance do banco e cache do SO.

`effective_cache_size`

Estimativa da memória total disponível para cache (SO + PostgreSQL). Ajuda o planner a decidir entre index scan e sequential scan. 75% da RAM é uma estimativa conservadora.

`work_mem`

Memória por operação de sort/hash por conexão. Calculado para evitar que o total de conexões simultâneas ultrapasse a RAM disponível.

`maintenance_work_mem`

Memória para operações de manutenção (VACUUM, CREATE INDEX). Valor mais alto acelera essas operações sem impacto no dia a dia.

`max_connections`

Número máximo de conexões simultâneas. Mais conexões = menos work_mem por conexão. Para aplicações web com connection pooling, 200 é um bom ponto de partida.

`random_page_cost`

Custo estimado de leitura aleatória de página. Em SSDs, cai para 1.1 (quase igual a leitura sequencial), incentivando o uso de índices.

`effective_io_concurrency`

Quantas operações de I/O o PostgreSQL pode disparar em paralelo. SSDs suportam muito mais concorrência (200) que HDDs (2).

`wal_buffers`

Memória para buffers de Write-Ahead Log. 16MB é suficiente para a maioria das cargas de trabalho.

`checkpoint_completion_target`

Fração do intervalo entre checkpoints em que a escrita deve ser completada. 0.9 distribui a escrita ao longo do tempo, reduzindo picos de I/O.

`default_statistics_target`

Nível de detalhe das estatísticas coletadas pelo ANALYZE. Valores maiores melhoram o planner para queries complexas (data warehouse) mas aumentam tempo de ANALYZE.

Perguntas frequentes sobre tuning PostgreSQL

Dúvidas comuns de DBAs e desenvolvedores sobre configuração e otimização de performance do PostgreSQL.

O que é shared_buffers e por que 25% da RAM?

shared_buffers é a memória dedicada ao cache interno do PostgreSQL. 25% da RAM é o valor recomendado pela documentação oficial — valores maiores podem causar contenção de memória com o cache do sistema operacional.

Qual a diferença entre work_mem e maintenance_work_mem?

work_mem é alocado por operação de sort/hash em cada conexão (pode multiplicar rapidamente). maintenance_work_mem é usado em operações de manutenção como VACUUM, CREATE INDEX e ALTER TABLE — normalmente precisa de mais memória mas roda com menos frequência.

SSD vs HDD: qual o impacto real na configuração?

Em SSDs, random_page_cost cai de 4.0 para 1.1 (leitura aleatória é quase tão rápida quanto sequencial) e effective_io_concurrency sobe de 2 para 200, permitindo ao PostgreSQL disparar mais leituras em paralelo.

Essa configuração resolve todos os problemas de performance?

Não. A configuração do postgresql.conf resolve cerca de 30% dos problemas. Os outros 70% são queries mal escritas, índices faltando, modelo de dados inadequado e falta de monitoramento — problemas que exigem análise especializada.

Posso aplicar essas configurações em produção diretamente?

Recomendamos testar primeiro em ambiente de homologação. Alguns parâmetros como shared_buffers exigem restart do PostgreSQL. Parâmetros como work_mem podem ser ajustados sem restart (reload). Sempre tenha um plano de rollback.

Como saber se preciso de mais do que tuning de configuração?

Se após o tuning o sistema continua lento, o problema está nas queries ou na arquitetura. Sinais: queries com sequential scan em tabelas grandes, locks frequentes, conexões idle in transaction, e alto uso de CPU mesmo com pouca carga.

Serviços de performance para quem precisa ir além do tuning

Configuração é o primeiro passo. Para resolver gargalos estruturais, conheça nossos serviços especializados.

Configure seu servidor