Noções Básicas de Capacidade

A capacidade do PostgreSQL é baseada em três recursos: CPU para execução de consultas e autovacuum, memória para shared_buffers e cache de página do SO, e I/O de disco para WAL e leituras de heap/índice. Dimensionamento correto para o formato da carga de trabalho (OLTP vs. relatórios), não o hábito genérico de "db.m5.large".

Receita

-- Snapshot rápido de capacidade
SELECT name, setting, unit
FROM pg_settings
WHERE name IN ('shared_buffers', 'work_mem', 'max_connections', 'effective_cache_size');
 
SELECT pg_size_pretty(pg_database_size(current_database())) AS db_size;
 
SELECT sum(calls) AS total_calls,
       round(sum(total_exec_time)::numeric, 1) AS total_ms
FROM pg_stat_statements;

# Host: iowait de CPU e latência de disco
vmstat 1 5
iostat -x 1 3

Quando usar isso:

Dimensionamento inicial da instância no RDS ou VM
Revisão trimestral antes das renovações
Latência alta, mas CPU baixa - suspeita de I/O ou bloqueios

Exemplo de Trabalho

Dimensionar um banco de dados de API OLTP de 2k TPS em 8 vCPUs / 32 GB de RAM.

-- Ponto de partida GUC orientado à memória (ajustar com teste de carga)
-- shared_buffers ~ 25% da RAM (8GB em 32GB)
ALTER SYSTEM SET shared_buffers = '8GB';
ALTER SYSTEM SET effective_cache_size = '24GB';
ALTER SYSTEM SET work_mem = '16MB';          -- cuidado: por nó de ordenação * conexões
ALTER SYSTEM SET maintenance_work_mem = '1GB';
ALTER SYSTEM SET max_connections = 200;        -- com PgBouncer, não 2000 pods de aplicativo
SELECT pg_reload_conf();

-- Sinal de demanda de CPU: backends ativos
SELECT count(*) FILTER (WHERE state = 'active') AS active,
       count(*) AS total
FROM pg_stat_activity
WHERE backend_type = 'client backend';

# Disco: manter 20% livre; WAL + dados em armazenamento de rede durável (gp3/io2)
df -h /var/lib/postgresql

O que isso demonstra:

shared_buffers e effective_cache_size guiam o planejador, não um cache mágico de tudo
work_mem escala com ordenações concorrentes; o pooler reduz a contagem real de backends
max_connections é um limite rígido - dimensionar com a matemática do PgBouncer
Contagem de sessões ativas vs. vCPU indica margem de CPU

Mergulho Profundo

Mapeamento de Recursos

Sintoma	Gargalo provável	Ajuste / ação
CPU alta, iowait baixo	Trabalho de consulta, índices ausentes	EXPLAIN, índices
iowait alto, CPU baixa	Latência de disco, cache frio	Armazenamento mais rápido, mais RAM
OOM / swap	`work_mem` × consultas, contagem de conexões	`work_mem` menor, pooler
Disco WAL cheio	Slots de replicação, rajadas de escrita	Limpeza de slots, autoscale de disco
Autovacuum atrasado	Transações longas, tabelas enormes	Particionamento, ajuste de vacuum

Heurística de Dimensionamento OLTP

Comece com 4-8 vCPUs para OLTP intermediário até que o teste de carga prove o contrário
RAM: 16-64 GB comuns; mais RAM ajuda na taxa de acertos do cache
Armazenamento: gp3 com IOPS de linha de base; aumente os IOPS quando pg_stat_bgwriter mostrar gargalos de escrita
Conexões: instâncias do aplicativo × tamanho do pool < max_connections × 0.8

Cadência de Revisão

Trimestral: crescimento da tabela, consultas principais, pico de conexões, previsão de disco, atraso da réplica.

Armadilhas

max_connections = 500 "para crescimento" - cada conexão consome RAM. Correção: PgBouncer; mantenha os backends do Postgres modestos.
work_mem = 256MB globalmente - 100 ordenações concorrentes podem causar OOM. Correção: padrão de 8-32MB; aumente por função para relatórios apenas.
Autoscale de CPU apenas em serverless - instâncias provisionadas precisam de redimensionamento manual ou política Aurora ACU.
Ignorar disco WAL e de backup - volume de dados cheio para escritas. Correção: alerte pontos de montagem separados.
Um tamanho de staging = prod - OK para versão principal; a classe da instância pode diferir se os formatos das consultas corresponderem.
Escalar CPU antes de corrigir varreduras sequenciais - 10x CPU perde para um índice btree. Correção: pg_stat_statements primeiro.

Alternativas

Alternativa	Usar Quando	Não Usar Quando
Teste de carga (k6, pgbench customizado)	Antes de um grande compromisso de hardware	Adivinhar o dimensionamento é aceitável (raro)
Escala vertical apenas	Margem < 30% e consulta ajustada	Já saturado de CPU com planos ruins
Réplica de leitura	Relatórios com muita leitura	Caminho de escrita saturado
Particionamento	Manutenção de tabela única muito grande	Tabelas pequenas, otimização prematura

FAQs

Quanto shared_buffers?

25% da RAM até ~8-16GB frequentemente citado; além disso, os retornos diminuem - o cache do SO é importante.

Quando a CPU é suficiente?

Sustentado < 60% com latência p95 dentro do SLO durante a hora de pico.

RAM ou disco mais rápido primeiro?

Se iowait alto e taxa de acertos do cache baixa, RAM; se a latência do SSD for alta com CPU baixa, nível de disco.

Créditos de burst na nuvem?

Instâncias classe T esgotam créditos sob carga Postgres constante - evite para OLTP de produção.

Quantas vCPUs por 1k TPS?

Altamente dependente da carga de trabalho - meça, não multiplique benchmarks de blog.

Incluir pooler de conexão no dimensionamento?

Sim - o pooler reduz os backends do Postgres; dimensionar a CPU do pooler levemente.

CPU do Autovacuum?

Picos durante o vacuum de tabelas grandes - deixe margem de CPU ou ajuste os limites de custo.

Vizinho barulhento multi-inquilino?

Um cluster por inquilino grande ou RLS com limites de recursos via bancos de dados separados.

Quando replataformar a classe da instância?

Quando CPU > 70% no pico por 2 semanas ou IOPS de armazenamento com estrangulamento consistente.

Documentar o dimensionamento onde?

ADR do serviço ou runbook com captura de tela das métricas de pico e SKU da instância.

Relacionado

Matemática de Conexão - pool × instâncias
Previsão de Crescimento de Armazenamento - planejamento de disco
Scale-Up vs Scale-Out - estratégias de escalonamento
Noções Básicas de Monitoramento - sinais de saturação
Melhores Práticas de Planejamento de Capacidade - lista de verificação de revisão

Versões da Pilha: Esta página foi escrita para PostgreSQL 18.4 (estável 18, manutenção 17), pgvector 0.8+, PgBouncer 1.x, Patroni 3.x, e PostGIS 3.5+.

Noções Básicas de Capacidade

Receita

-- Snapshot rápido de capacidade
SELECT name, setting, unit
FROM pg_settings
WHERE name IN ('shared_buffers', 'work_mem', 'max_connections', 'effective_cache_size');
 
SELECT pg_size_pretty(pg_database_size(current_database())) AS db_size;
 
SELECT sum(calls) AS total_calls,
       round(sum(total_exec_time)::numeric, 1) AS total_ms
FROM pg_stat_statements;

# Host: iowait de CPU e latência de disco
vmstat 1 5
iostat -x 1 3

Quando usar isso:

Dimensionamento inicial da instância no RDS ou VM
Revisão trimestral antes das renovações
Latência alta, mas CPU baixa - suspeita de I/O ou bloqueios

Exemplo de Trabalho

Dimensionar um banco de dados de API OLTP de 2k TPS em 8 vCPUs / 32 GB de RAM.

-- Ponto de partida GUC orientado à memória (ajustar com teste de carga)
-- shared_buffers ~ 25% da RAM (8GB em 32GB)
ALTER SYSTEM SET shared_buffers = '8GB';
ALTER SYSTEM SET effective_cache_size = '24GB';
ALTER SYSTEM SET work_mem = '16MB';          -- cuidado: por nó de ordenação * conexões
ALTER SYSTEM SET maintenance_work_mem = '1GB';
ALTER SYSTEM SET max_connections = 200;        -- com PgBouncer, não 2000 pods de aplicativo
SELECT pg_reload_conf();

-- Sinal de demanda de CPU: backends ativos
SELECT count(*) FILTER (WHERE state = 'active') AS active,
       count(*) AS total
FROM pg_stat_activity
WHERE backend_type = 'client backend';

# Disco: manter 20% livre; WAL + dados em armazenamento de rede durável (gp3/io2)
df -h /var/lib/postgresql

O que isso demonstra:

shared_buffers e effective_cache_size guiam o planejador, não um cache mágico de tudo
work_mem escala com ordenações concorrentes; o pooler reduz a contagem real de backends
max_connections é um limite rígido - dimensionar com a matemática do PgBouncer
Contagem de sessões ativas vs. vCPU indica margem de CPU

Mergulho Profundo

Mapeamento de Recursos

Sintoma	Gargalo provável	Ajuste / ação
CPU alta, iowait baixo	Trabalho de consulta, índices ausentes	EXPLAIN, índices
iowait alto, CPU baixa	Latência de disco, cache frio	Armazenamento mais rápido, mais RAM
OOM / swap	`work_mem` × consultas, contagem de conexões	`work_mem` menor, pooler
Disco WAL cheio	Slots de replicação, rajadas de escrita	Limpeza de slots, autoscale de disco
Autovacuum atrasado	Transações longas, tabelas enormes	Particionamento, ajuste de vacuum

Heurística de Dimensionamento OLTP

Comece com 4-8 vCPUs para OLTP intermediário até que o teste de carga prove o contrário
RAM: 16-64 GB comuns; mais RAM ajuda na taxa de acertos do cache
Armazenamento: gp3 com IOPS de linha de base; aumente os IOPS quando pg_stat_bgwriter mostrar gargalos de escrita
Conexões: instâncias do aplicativo × tamanho do pool < max_connections × 0.8

Cadência de Revisão

Trimestral: crescimento da tabela, consultas principais, pico de conexões, previsão de disco, atraso da réplica.

Armadilhas

max_connections = 500 "para crescimento" - cada conexão consome RAM. Correção: PgBouncer; mantenha os backends do Postgres modestos.
work_mem = 256MB globalmente - 100 ordenações concorrentes podem causar OOM. Correção: padrão de 8-32MB; aumente por função para relatórios apenas.
Autoscale de CPU apenas em serverless - instâncias provisionadas precisam de redimensionamento manual ou política Aurora ACU.
Ignorar disco WAL e de backup - volume de dados cheio para escritas. Correção: alerte pontos de montagem separados.
Um tamanho de staging = prod - OK para versão principal; a classe da instância pode diferir se os formatos das consultas corresponderem.
Escalar CPU antes de corrigir varreduras sequenciais - 10x CPU perde para um índice btree. Correção: pg_stat_statements primeiro.

Alternativas

Alternativa	Usar Quando	Não Usar Quando
Teste de carga (k6, pgbench customizado)	Antes de um grande compromisso de hardware	Adivinhar o dimensionamento é aceitável (raro)
Escala vertical apenas	Margem < 30% e consulta ajustada	Já saturado de CPU com planos ruins
Réplica de leitura	Relatórios com muita leitura	Caminho de escrita saturado
Particionamento	Manutenção de tabela única muito grande	Tabelas pequenas, otimização prematura

FAQs

Quanto shared_buffers?

25% da RAM até ~8-16GB frequentemente citado; além disso, os retornos diminuem - o cache do SO é importante.

Quando a CPU é suficiente?

Sustentado < 60% com latência p95 dentro do SLO durante a hora de pico.

RAM ou disco mais rápido primeiro?

Se iowait alto e taxa de acertos do cache baixa, RAM; se a latência do SSD for alta com CPU baixa, nível de disco.

Créditos de burst na nuvem?

Instâncias classe T esgotam créditos sob carga Postgres constante - evite para OLTP de produção.

Quantas vCPUs por 1k TPS?

Altamente dependente da carga de trabalho - meça, não multiplique benchmarks de blog.

Incluir pooler de conexão no dimensionamento?

Sim - o pooler reduz os backends do Postgres; dimensionar a CPU do pooler levemente.

CPU do Autovacuum?

Picos durante o vacuum de tabelas grandes - deixe margem de CPU ou ajuste os limites de custo.

Vizinho barulhento multi-inquilino?

Um cluster por inquilino grande ou RLS com limites de recursos via bancos de dados separados.

Quando replataformar a classe da instância?

Quando CPU > 70% no pico por 2 semanas ou IOPS de armazenamento com estrangulamento consistente.

Documentar o dimensionamento onde?

ADR do serviço ou runbook com captura de tela das métricas de pico e SKU da instância.

Relacionado

Matemática de Conexão - pool × instâncias
Previsão de Crescimento de Armazenamento - planejamento de disco
Scale-Up vs Scale-Out - estratégias de escalonamento
Noções Básicas de Monitoramento - sinais de saturação
Melhores Práticas de Planejamento de Capacidade - lista de verificação de revisão

Versões da Pilha: Esta página foi escrita para PostgreSQL 18.4 (estável 18, manutenção 17), pgvector 0.8+, PgBouncer 1.x, Patroni 3.x, e PostGIS 3.5+.

Noções Básicas de Capacidade

Buscar na documentação

Noções Básicas de Capacidade