PostgreSQL
Memoria y configuración del servidor
Parámetros de memoria y servidor como shared_buffers, work_mem, maintenance_work_mem, cache y checkpoints, ajustados según carga y recursos reales.
- Última actualización
- Actualizada
- Nivel
- Profundización
PostgreSQL
Parámetros de memoria y servidor como shared_buffers, work_mem, maintenance_work_mem, cache y checkpoints, ajustados según carga y recursos reales.
La configuración de PostgreSQL reparte memoria y trabajo entre muchas sesiones. Un valor que mejora una consulta aislada puede agotar el servidor cuando se multiplica por nodos, conexiones y procesos paralelos.
No existe un postgresql.conf universal. La configuración depende de:
Antes de ajustar, mide el cuello de botella.
Cache administrada por PostgreSQL:
shared_buffers
+ page cache del sistema operativo
→ datos potencialmente calientesNo debe ocupar toda la RAM. PostgreSQL también necesita memoria por backend, WAL, maintenance y OS cache.
En servidores dedicados suele iniciarse con una fracción moderada y ajustarse con evidencia; managed services pueden elegir defaults propios.
No reserva memoria. Informa al planner cuánto cache combinado podría estar disponible para estimar costes de índices. Un valor bajo puede desalentar index scans; uno irrealmente alto puede sobreestimarlos.
Límite base por operación de sort/hash, no por conexión:
query con 3 sorts + 2 hash nodes
→ puede consumir varias veces work_memY se multiplica por queries concurrentes y workers paralelos.
Señales de insuficiencia:
external merge.Pero un spill pequeño ocasional puede ser preferible a riesgo de OOM.
Para un reporte controlado:
SET LOCAL work_mem = '128MB';No lo eleves globalmente por una sola query.
Usado por VACUUM, CREATE INDEX y ALTER TABLE en operaciones compatibles. Puede ser mayor que work_mem, pero autovacuum workers tienen su propia consideración (autovacuum_work_mem) y varios procesos pueden ejecutarse a la vez.
Cada backend consume memoria y scheduler. Un valor alto no crea capacidad; permite más competencia.
Usa pooling y un presupuesto global. Reserva conexiones administrativas (superuser_reserved_connections o mecanismos modernos aplicables) para incidentes.
Parámetros relevantes:
max_wal_size / min_wal_size.checkpoint_timeout.checkpoint_completion_target.wal_buffers.synchronous_commit.Checkpoints frecuentes generan picos y más full-page images. Muy espaciados aumentan WAL/recovery. Ajusta según rate de WAL, storage y RTO.
Modelan coste relativo de acceso. SSD puede justificar menor random_page_cost, pero cambiarlo para forzar un plan oculta estadísticas/query/index incorrectos.
Calibra a nivel del sistema o tablespace con benchmarks y planes representativos.
Permite más solicitudes I/O concurrentes para operaciones compatibles, especialmente storage que soporta paralelismo. El valor adecuado depende de plataforma; en managed services puede estar limitado.
max_worker_processes.max_parallel_workers.max_parallel_workers_per_gather.Más workers pueden acelerar una query y reducir capacidad total. Reports paralelos compiten con OLTP.
Puede acelerar queries CPU-intensive largas, pero añade compile overhead. Para OLTP corto puede perjudicar. Revisa nodos y JIT en EXPLAIN antes de cambiar thresholds.
Global defaults:
Tablas grandes o de alta escritura suelen necesitar settings por tabla. Demasiado lento causa bloat; demasiado agresivo compite por I/O.
Defensa operacional:
statement_timeout
lock_timeout
idle_in_transaction_session_timeout
idle_session_timeoutConfigúralos por role/endpoint cuando workloads difieren. Un timeout global demasiado corto rompe migrations y backups; uno infinito permite runaway queries.
Además de settings:
Observa RSS y OOM, no solo valores configurados.
Pueden reducir overhead de page tables para shared memory grande. Su configuración depende del OS y despliegue; prueba arranque y reservas. Transparent Huge Pages pueden causar latencia en algunas plataformas y suelen evaluarse separadamente.
Considera:
No desactives fsync o full_page_writes para “benchmark” una configuración productiva.
ALTER ROLE reporting SET statement_timeout = '5min';
ALTER ROLE app_runtime SET statement_timeout = '5s';Los defaults pueden sobrescribirse con SET LOCAL. Documenta precedencia: compiled default, config file, ALTER SYSTEM, database, role, session y transaction.
Algunos parámetros aceptan reload; otros requieren restart. Consulta pg_settings.context:
SELECT name, setting, unit, context, pending_restart
FROM pg_settings
WHERE name = 'shared_buffers';No programes un cambio sin saber si necesita downtime.
Escribe en postgresql.auto.conf. Es útil, pero puede crear drift respecto a infraestructura como código. Define una fuente de verdad y registra quién cambió qué.
El proveedor puede:
No copies recomendaciones bare-metal sin adaptar.
max_connections=1000 para resolver pool errors.pg_settings.context y pending_restart.Consultas lentas y diagnóstico aplica un proceso de investigación desde el síntoma hasta la evidencia.