Ir al contenido

Casos reales de Odoo sin pooler (y cómo fallan)

21 de junio de 2026 por
Casos reales de Odoo sin pooler (y cómo fallan)
Juan Manuel De Castro
| Todavía no hay comentarios

Empiece a escribir aqu

🧠 Por qué este capítulo importa

Muchos equipos:

  • saben que algo va mal

  • aplican parches

  • cambian parámetros

  • reinician servicios

Pero no entienden el patrón de fallo.

Aquí mostramos qué pasa realmente cuando Odoo corre sin pooler.


🧪 Caso 1 – “Funciona bien hasta que entran todos”

Escenario

  • Odoo con 10–15 usuarios

  • PostgreSQL directo

  • sin PgBouncer

Síntomas

  • mañana fluida

  • tarde lenta

  • cierre de día imposible

Qué pasa técnicamente

  • más usuarios → más workers ocupados

  • más transacciones abiertas

  • PostgreSQL saturado de conexiones

  • latencia en cascada

Solución típica (errónea)

max_connections = 300

Resultado

  • mejora temporal

  • vuelve a fallar

  • peor estabilidad


🧪 Caso 2 – “La CPU está libre, pero Odoo va mal”

Escenario

  • servidor potente

  • CPU al 15 %

  • RAM alta

Síntomas

  • formularios lentos

  • clicks sin respuesta

  • usuarios esperando

Qué pasa

  • PostgreSQL coordinando procesos

  • muchas conexiones idle

  • workers esperando locks

👉 El sistema no está ocupado, está bloqueado.


🧪 Caso 3 – “Todo se arregla reiniciando”

Escenario

  • Odoo lento

  • PostgreSQL con cientos de conexiones

Acción

systemctl restart odoo

Resultado

  • conexiones cerradas

  • memoria liberada

  • sistema “milagrosamente” rápido

Verdad incómoda

  • el reinicio solo limpió el desastre

  • el problema sigue intacto


🧪 Caso 4 – “Los crons matan el sistema”

Escenario

  • Odoo con crons pesados

  • sin PgBouncer

Síntomas

  • usuarios bloqueados

  • inventario lento

  • facturación imposible

Qué pasa

  • crons abren transacciones largas

  • conexiones retenidas

  • usuarios esperando pool

👉 Sin pooler, crons compiten directamente con usuarios.


🧪 Caso 5 – “Escala horizontal que no escala”

Escenario

  • varios Odoo detrás de un proxy

  • misma base PostgreSQL

  • sin PgBouncer

Resultado

  • conexiones multiplicadas

  • PostgreSQL colapsa antes

  • escalado inútil

👉 Escalar Odoo sin pooler empeora el problema.


🧠 El patrón común en todos los casos

Siempre aparece:

  • demasiadas conexiones reales

  • transacciones largas

  • memoria fragmentada

  • contención interna

Y siempre se intenta:

  • más hardware

  • más conexiones

  • más workers

👉 Todo menos arreglar la arquitectura.


🚀 Qué cambia con PgBouncer

En los mismos escenarios, con PgBouncer:

  • conexiones controladas

  • crons aislados

  • PostgreSQL estable

  • latencia predecible

No magia.

Arquitectura correcta.


🔗 Enlaces relacionados


📌 Conclusión

Odoo sin pooler:

  • puede funcionar

  • puede parecer estable

  • puede engañar

Hasta que:

  • crecen los usuarios

  • crecen los datos

  • llega la carga real

👉 PgBouncer no es una optimización avanzada.

👉 Es requisito mínimo para producción seria.

Capítulo Siguiente ->

Casos reales de Odoo sin pooler (y cómo fallan)
Juan Manuel De Castro 21 de junio de 2026
Compartir
Etiquetas
Archivo
Iniciar sesión dejar un comentario