Optimizador PostgreSQL
Motor de rendimiento de producción para PostgreSQL

PostgreSQL (postgresql.conf) Hardware Tuner & Builder

Calcule y genere configuraciones optimizadas de postgresql.conf basadas en las especificaciones del hardware (shared_buffers, work_mem, effective_cache_size, max_connections).

Ejecución de cliente sin telemetría
Preajustes:
Entrada
Total System RAM (Memory)
GB RAM
Physical / Virtual CPU Cores
Núcleos
Conexiones
clientes
~41MB work_mem/conexión
RAM: 32GB•CPU: 8 Núcleos•Workload: web•Storage: nvme
# ----------------------------------------------------------------------
# PostgreSQL 17 Hardware-Tuned Configuration
# Target Profile: WEB | RAM: 32GB | CPU: 8 Cores | Storage: NVME
# Generated: 2026-01-01T00:00:00.000Z via ToolsAA Client-Side Tuner
# ----------------------------------------------------------------------

# CONNECTIONS & NETWORKING
max_connections = 200
# Note: Transaction pooler (PgBouncer) is assumed in front of PostgreSQL.

# MEMORY ALLOCATION
shared_buffers = 8GB
effective_cache_size = 24GB
maintenance_work_mem = 1.6GB
work_mem = 41MB
wal_buffers = 16MB
huge_pages = try

# CHECKPOINT & WAL ENGINE
checkpoint_completion_target = 0.9
checkpoint_timeout = 15min
min_wal_size = 2GB
max_wal_size = 16GB
wal_compression = zstd
synchronous_commit = on

# QUERY PLANNER & DISK I/O TUNING
random_page_cost = 1.05
effective_io_concurrency = 300
default_statistics_target = 100
jit = off

# PARALLEL QUERY WORKERS
max_worker_processes = 8
max_parallel_workers_per_gather = 4
max_parallel_workers = 8
max_parallel_maintenance_workers = 4

# TELEMETRY & DIAGNOSTICS
track_io_timing = on
track_functions = pl
log_min_duration_statement = 1000   # Log queries exceeding 1000ms
log_checkpoints = on
log_connections = on
log_disconnections = on
log_lock_waits = on
shared_buffers: 8GB•work_mem: 41MB•effective_cache: 24GB
Shared Buffers Allocation
8GB

Caché de memoria principal de PostgreSQL (~25% de la RAM física total).

Effective Cache Size
24GB

Caché de disco estimada del SO disponible para escaneos de índices (~75% RAM).

Parallel Query Pool
8 Workers

4 workers paralelos por nodo gather a través de 8 Núcleos

Ejecución Local de Conocimiento Cero

Todo el procesamiento, análisis y generación de código se ejecutan estrictamente en la memoria del navegador. Cero subidas a servidores externos.

Motor Reactivo de Submilisegundos

All data payloads remain strictly local with zero external server communication.

Production Ready Export

Clean, optimized output formats ready for immediate deployment.

Referencia técnica y guía de arquitectura

Guía de Desarrollo: Optimizador y Generador de Hardware para PostgreSQL (postgresql.conf) — Guía de referencia

Calcule y genere configuraciones optimizadas de postgresql.conf basadas en las especificaciones del hardware (shared_buffers, work_mem, effective_cache_size, max_connections).

Parámetros clave y controles

shared_buffersstring (memory_size)

Búfer de memoria compartida dedicado de PostgreSQL para almacenar en caché páginas de tablas e índices.

Por defecto: 25% de la RAM total del sistema (ej. 4 GB en un servidor de 16 GB)
work_memstring (memory_size)

Memoria asignada para operaciones internas de ordenación y tablas hash por nodo de consulta antes de escribir en disco temporal.

Por defecto: ((RAM total - shared_buffers) / (max_connections * 3)) ~ 16 MB - 64 MB
effective_cache_sizestring (memory_size)

Estimación utilizada por el planificador de consultas sobre la memoria disponible para caché de disco (PostgreSQL + caché del SO).

Por defecto: 50% - 75% de la RAM total del sistema (ej. 12 GB en 16 GB de RAM)
maintenance_work_memstring (memory_size)

Memoria máxima utilizada por operaciones de mantenimiento como VACUUM, CREATE INDEX y claves foráneas.

Por defecto: 5% - 10% de la RAM total del sistema (hasta 2 GB)
max_connectionsinteger

Número máximo de conexiones concurrentes de clientes permitidas por el motor de base de datos.

Por defecto: 100 (Predeterminado) / 20-50 detrás de PgBouncer

Consejos profesionales y mejores prácticas

Evite configurar max_connections en

Evite configurar max_connections en valores excesivos (> 200) directamente en postgresql.conf. Use un concentrador de conexiones como PgBouncer en modo transacción para mantener bajas las conexiones reales y asignar un work_mem sustancialmente mayor.

Ajuste de costes para discos SSD y NVMe

En discos SSD/NVMe modernos, reduzca random_page_cost del valor por defecto 4.0 a 1.1 y aumente effective_io_concurrency a 200. Esto indica al planificador que las lecturas aleatorias son casi tan rápidas como las secuenciales, priorizando los escaneos de índices.

Configure checkpoint_completion_target

Configure checkpoint_completion_target = 0.9 y aumente max_wal_size a 16 GB - 32 GB en bases de datos con escrituras intensivas para distribuir la E/S a lo largo del intervalo del checkpoint y evitar caídas de rendimiento.

Cuando shared_buffers sea de 8 GB o

Cuando shared_buffers sea de 8 GB o más, active Huge Pages en Linux (vm.nr_hugepages) y establezca huge_pages = try en postgresql.conf para reducir fallos de caché TLB y sobrecarga del kernel.

Errores comunes y solución de problemas

El OOM Killer de Linux termina abruptamente procesos de PostgreSQL

Reduzca work_mem o disminuya max_connections. Recuerde que work_mem se asigna por cada operación de ordenación/hash dentro de una consulta, por lo que una consulta compleja puede consumir múltiples bloques de work_mem.

FATAL: could not create shared memory segment: Cannot allocate memory

Verifique los parámetros del kernel de Linux (sysctl vm.max_map_count) y la memoria física libre. Asegúrese de que shared_buffers no exceda la RAM disponible ni las cuotas de cgroups en contenedores.

Los registros muestran advertencias de puntos de control frecuentes (checkpoints are occurring too frequently)

Incremente max_wal_size (ej. de 1 GB a 16 GB) y amplíe checkpoint_timeout (ej. de 5 min a 15 min) para evitar checkpoints prematuros causados por la saturación de segmentos WAL.

Preguntas frecuentes (FAQ)

¿Por qué shared_buffers se limita típicamente al 25%-40% de la RAM en Linux?▼

PostgreSQL utiliza una arquitectura de doble caché donde shared_buffers interactúa estrechamente con la caché de páginas del kernel de Linux. Asignar más del 40% a menudo causa duplicación de datos, degrada la caché del sistema de archivos y agrava los picos de escritura durante los checkpoints.

¿Consume o reserva memoria física el parámetro effective_cache_size?▼

No. effective_cache_size es un parámetro estrictamente orientativo para el optimizador de consultas (planner). Permite estimar si los bloques de índices ya residen en la caché del sistema operativo sin reservar ni un solo byte de memoria real.

¿En qué se diferencia work_mem de maintenance_work_mem?▼

work_mem se asigna de forma dinámica por cada operación de ordenación o tabla hash durante las consultas habituales de los usuarios. En cambio, maintenance_work_mem solo se utiliza en tareas de mantenimiento como VACUUM, CREATE INDEX o REINDEX, permitiendo valores mucho más altos al ejecutarse pocas operaciones simultáneas.

¿Cómo debe variar la configuración entre cargas OLTP y OLAP (Data Warehouse)?▼

Los entornos OLTP con alta concurrencia requieren un work_mem contenido y control estricto de conexiones para garantizar baja latencia. Las cargas analíticas OLAP se benefician de un work_mem mucho más alto (ej. 256 MB - 1 GB) y mayor valor de max_parallel_workers_per_gather para procesar grandes volúmenes de datos en paralelo.

Herramientas y utilidades relacionadas

Todas las herramientas →
Guía de Desarrollo del Generador de Unidades Systemd (.timer y .service) de LinuxDesarrollo

Diseñe y genere unidades de temporizador (.timer) y servicios complementarios de systemd listos para producción con programación OnCalendar, intervalos OnBootSec, ejecución Persistent y demoras aleatorias.

Abrir herramienta→
Guía para Desarrolladores del Generador de Configuración TypeScript (tsconfig.json)Desarrollo

Genera configuraciones tsconfig.json modernas y robustas para Next.js, Node.js, Vite o librerías con modo estricto, alias de rutas y resolución de módulos.

Abrir herramienta→
Guía de Desarrollo: Generador de DDL CREATE TABLE de JSON a ClickHouseDesarrollo

Convierta documentos JSON de muestra en DDL de SQL para ClickHouse con motor MergeTree, tipos UInt/Int/Float/String/DateTime y mapeo de columnas Array/Nested.

Abrir herramienta→
Guía de Desarrollo: Generador de Esquema de Tabla Google BigQuery desde JSONDesarrollo

Infiere y convierte objetos JSON en esquemas de tabla para Google Cloud BigQuery con campos RECORD, STRING, INTEGER, NUMERIC y TIMESTAMP.

Abrir herramienta→
Guía para Desarrolladores: Generador de DDL CREATE TABLE de JSON a SnowflakeDesarrollo

Transforme esquemas y cargas útiles JSON en sentencias SQL CREATE TABLE para Snowflake listas para producción con tipos de datos VARIANT, VARCHAR, NUMBER, BOOLEAN y TIMESTAMP_NTZ.

Abrir herramienta→
Guía de Desarrollo: Generador de Variables y Locals de Terraform HCL desde JSON / YAMLDesarrollo

Convierta cargas útiles JSON y YAML en restricciones de tipo de variables Terraform HCL (type = object({...})), valores predeterminados, bloques locals y definiciones terraform.tfvars.

Abrir herramienta→