Conceptos básicos de capacidad
La capacidad de PostgreSQL se basa en tres recursos: CPU para la ejecución de consultas y autovacuum, memoria para shared_buffers y la caché de páginas del sistema operativo, y E/S de disco para WAL y lecturas de heap/índices. Dimensiona correctamente según la forma de la carga de trabajo (OLTP vs. informes), no por el hábito genérico de "db.m5.large".
Receta
-- Instantánea rápida de capacidad
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 y latencia de disco
vmstat 1 5
iostat -x 1 3Cuándo recurrir a esto:
- Dimensionamiento inicial de instancias en RDS o VM
- Revisión trimestral antes de las renovaciones
- Latencia alta pero CPU baja - sospecha de E/S o bloqueos
Ejemplo práctico
Dimensiona una base de datos de API OLTP de 2k TPS en 8 vCPU / 32 GB de RAM.
-- Punto de partida de GUC orientado a memoria (ajustar con prueba de carga)
-- shared_buffers ~ 25% de RAM (8 GB en 32 GB)
ALTER SYSTEM SET shared_buffers = '8GB';
ALTER SYSTEM SET effective_cache_size = '24GB';
ALTER SYSTEM SET work_mem = '16MB'; -- cuidado: por nodo de ordenación * conexiones
ALTER SYSTEM SET maintenance_work_mem = '1GB';
ALTER SYSTEM SET max_connections = 200; -- con PgBouncer, no 2000 pods de aplicación
SELECT pg_reload_conf();-- Señal de demanda de CPU: backends activos
SELECT count(*) FILTER (WHERE state = 'active') AS active,
count(*) AS total
FROM pg_stat_activity
WHERE backend_type = 'client backend';# Disco: mantener un 20% libre; WAL + datos en almacenamiento de red duradero (gp3/io2)
df -h /var/lib/postgresqlLo que esto demuestra:
shared_buffersyeffective_cache_sizeguían al planificador, no son una caché mágica de todowork_memescala con ordenaciones concurrentes; el pooler reduce el número real de backendsmax_connectionses un límite estricto - dimensiona con las matemáticas de PgBouncer- El recuento de sesiones activas frente a las vCPU indica margen de CPU
Análisis detallado
Mapeo de recursos
| Síntoma | Cuello de botella probable | Perilla / acción |
|---|---|---|
| CPU alta, iowait bajo | Trabajo de consulta, índices faltantes | EXPLAIN, índices |
| iowait alto, CPU baja | Latencia de disco, caché fría | Almacenamiento más rápido, más RAM |
| OOM / swap | work_mem × consultas, recuento de conexiones | Menor work_mem, pooler |
| Disco WAL lleno | Ranuras de replicación, ráfagas de escritura | Limpieza de ranuras, escalado automático de disco |
| Autovacuum atrasado | Transacciones largas, tablas enormes | Partición, ajuste de vacuum |
Heurística de dimensionamiento OLTP
- Empezar con 4-8 vCPU para OLTP medio hasta que la prueba de carga demuestre lo contrario
- RAM: 16-64 GB común; más RAM ayuda a la tasa de aciertos de caché
- Almacenamiento: gp3 con IOPS de línea base; aumentar IOPS cuando
pg_stat_bgwritermuestre bloqueos de escritura - Conexiones: instancias de aplicación × tamaño del pool <
max_connections× 0.8
Cadencia de revisión
Trimestral: crecimiento de tablas, consultas principales, pico de conexiones, pronóstico de disco, latencia de réplica.
Trampas comunes
max_connections = 500"para crecimiento" - cada conexión consume RAM. Solución: PgBouncer; mantener los backends de Postgres modestos.work_mem = 256MBglobalmente - 100 ordenaciones concurrentes pueden causar OOM. Solución: 8-32 MB por defecto; aumentar por rol solo para informes.- La CPU se escala automáticamente solo en serverless - las instancias aprovisionadas requieren redimensionamiento manual o política de Aurora ACU.
- Ignorar el disco de WAL y copias de seguridad - el volumen de datos lleno detiene las escrituras. Solución: alertar puntos de montaje separados.
- Un tamaño de staging = prod - OK para versiones principales; la clase de instancia puede diferir si las formas de consulta coinciden.
- Escalar CPU antes de arreglar escaneos secuenciales - 10x CPU pierde ante un índice btree. Solución:
pg_stat_statementsprimero.
Alternativas
| Alternativa | Usar cuándo | No usar cuándo |
|---|---|---|
| Prueba de carga (k6, pgbench personalizado) | Antes de un compromiso de hardware importante | Aceptar dimensionamiento por suposición (raro) |
| Escalado vertical solamente | Margen < 30% y consulta ajustada | Ya saturado de CPU con planes incorrectos |
| Réplica de lectura | Informes con muchas lecturas | Ruta de escritura saturada |
| Particionamiento | Mantenimiento de tabla única muy grande | Tablas pequeñas, optimización prematura |
Preguntas frecuentes
¿Cuánta `shared_buffers`?
25% de RAM hasta ~8-16 GB se cita a menudo; más allá de eso los rendimientos disminuyen - la caché del SO importa.
¿Cuándo es suficiente la CPU?
Sostenido < 60% con latencia p95 dentro del SLO durante la hora pico.
¿RAM o disco más rápido primero?
Si el iowait es alto y la caché tiene pocos aciertos, RAM; si la latencia del SSD es alta con CPU baja, nivel de disco.
¿Créditos de ráfaga en la nube?
Las instancias de clase T agotan los créditos bajo carga constante de Postgres - evitar para OLTP en producción.
¿Cuántas vCPU por 1k TPS?
Depende mucho de la carga de trabajo - mide, no multipliques los benchmarks de blogs.
¿Incluir el agrupador de conexiones en el dimensionamiento?
Sí - el agrupador reduce los backends de Postgres; dimensiona la CPU del agrupador ligeramente.
¿CPU de Autovacuum?
Picos durante el vacuum de tablas grandes - deja margen de CPU o ajusta los límites de costos.
¿Vecino ruidoso multi-inquilino?
Un clúster por inquilino grande o RLS con límites de recursos a través de bases de datos separadas.
¿Cuándo cambiar la clase de instancia?
Cuando la CPU > 70% pico durante 2 semanas o las IOPS de almacenamiento se limitan consistentemente.
¿Dónde documentar el dimensionamiento?
ADR del servicio o runbook con captura de pantalla de métricas pico y SKU de instancia.
Relacionado
- Matemáticas de conexiones - pool × instancias
- Previsión de crecimiento de almacenamiento - planificación de disco
- Escalado vertical vs. Escalado horizontal - estrategias de escalado
- Conceptos básicos de monitorización - señales de saturación
- Mejores prácticas de planificación de capacidad - lista de verificación de revisión
Versiones de pila: Esta página se escribió para PostgreSQL 18.4 (estable 18, mantenimiento 17), pgvector 0.8+, PgBouncer 1.x, Patroni 3.x y PostGIS 3.5+.