🚨 El reflejo automático cuando Odoo va lento
Cuando aparecen errores como:
FATAL: too many connections
latencia intermitente
Odoo “se queda pensando”
La reacción típica es:
max_connections = 500
👉 Parece lógico.
👉 Casi siempre es un error.
🧠 Por qué este ajuste es tan tentador
Porque:
el error menciona “conexiones”
el parámetro se llama max_connections
cambiarlo es fácil
PostgreSQL reinicia sin quejarse
Pero PostgreSQL no te avisa de que acabas de degradar el sistema.
🔌 Qué significa realmente max_connections
En PostgreSQL:
1 conexión = 1 proceso
cada proceso consume:
memoria
CPU
estructuras internas
Incluso una conexión idle:
no es gratis
reserva memoria
participa en scheduling
📉 El costo real por conexión
Dependiendo de la configuración:
5–15 MB por conexión (mínimo)
más work_mem
más buffers temporales
Ejemplo real:
300 conexiones × 10 MB ≈ 3 GB de RAM
Y eso sin hacer nada.
🧨 El efecto cascada en PostgreSQL
Al subir max_connections:
más procesos compiten por CPU
más context switching
más cache misses
peor latencia global
Resultado:
CPU baja, RAM alta, sistema lento.
⚠️ Odoo empeora este escenario
Odoo:
mantiene conexiones abiertas
retiene transacciones
no libera rápido
Entonces:
PostgreSQL no puede reciclar recursos
las conexiones se acumulan
la latencia se vuelve impredecible
❌ El falso “arreglo temporal”
A veces pasa esto:
subes max_connections
reinicias PostgreSQL
“funciona mejor”
unas horas después, vuelve a fallar
¿Por qué?
👉 Porque reiniciar libera memoria, no porque el ajuste sea correcto.
🧪 Ejemplo real comparativo
Sin PgBouncer
max_connections = 400
150 conexiones activas
RAM saturada
latencia variable
Con PgBouncer
max_connections = 100
20 conexiones reales
RAM estable
latencia consistente
👉 Menos conexiones = mejor rendimiento.
🧠 PostgreSQL prefiere pocas conexiones bien usadas
PostgreSQL escala mejor con:
pocas conexiones
bien reutilizadas
con pooling
No con:
cientos de procesos ociosos
memoria fragmentada
contención constante
🧩 Entonces, ¿qué sí es la solución?
No es:
más hardware
más workers
más conexiones
Es:
desacoplar conexiones lógicas de conexiones reales
Eso se logra con:
PgBouncer
pool_mode correcto
pools bien dimensionados
👉 Todo lo que estamos construyendo en este curso.
🔗 Enlaces relacionados
📌 Conclusión
Subir max_connections:
es fácil
parece lógico
casi siempre empeora el problema
En Odoo:
el problema no es el límite
es cómo se usan las conexiones
👉 PostgreSQL no necesita más conexiones.
👉 Necesita menos, mejor usadas.
👉 Siguiente capítulo recomendado
Cómo calcular el pool_size ideal de PgBouncer para Odoo
Ahí entramos en:
números reales
workers
usuarios concurrentes
crons
producción sin adivinanzas