Hola a todos
Estoy ejecutando n8n con múltiples workers, y a medida que aumenta la concurrencia, estoy comenzando a pensar en la gestión de conexiones de PostgreSQL.
Mi arquitectura es aproximadamente:
Balanceador de carga
↓
Múltiples workers de n8n
↓
PostgreSQL
Mi preocupación es que si cada worker abre múltiples conexiones de base de datos, la base de datos podría eventualmente alcanzar su límite de conexiones, afectando el rendimiento y la estabilidad del flujo de trabajo.
Estoy considerando usar un agrupador de conexiones como PgBouncer, pero me gustaría entender cómo otros manejan esto en producción.
Para los que ejecutan PostgreSQL con implementaciones de n8n de alta concurrencia:
¿Cómo deciden la configuración correcta de max_connections?
¿Usan un agrupador de conexiones como PgBouncer, o es suficiente el comportamiento predeterminado de PostgreSQL?
¿Cómo monitorean el agotamiento de conexiones antes de que se convierta en un problema?
¿Han encontrado que aumentar el número de workers u optimizar las consultas tiene un impacto mayor en el rendimiento general de la base de datos?
Describe el problema/error/pregunta
¿Cuál es el mensaje de error (si hay alguno)?
Por favor, comparta su flujo de trabajo
(Seleccione los nodos en su lienzo y use los atajos de teclado CMD+C/CTRL+C y CMD+V/CTRL+V para copiar y pegar el flujo de trabajo.)
Comparta el resultado devuelto por el último nodo
Información sobre su configuración de n8n
versión de n8n:
Base de datos (predeterminada: SQLite):
Configuración de n8n EXECUTIONS_PROCESS (predeterminada: own, main):
Ejecutando n8n mediante (Docker, npm, n8n cloud, aplicación de escritorio):
Hola @Keira_Becky Un buen enfoque es optimizar el uso de conexiones antes de aumentar el límite de conexiones.
Enfoque recomendado
En lugar de aumentar continuamente max_connections, usa un pooler de conexiones como PgBouncer para reutilizar las conexiones existentes de manera eficiente.
n8n Workers
↓
PgBouncer
↓
PostgreSQL
Esto reduce la sobrecarga de conexiones y ayuda a PostgreSQL a manejar una concurrencia más alta de manera más eficiente.
Mejores prácticas
Usa pooling de conexiones para múltiples workers
Establece max_connections según la CPU y memoria de tu servidor
Monitorea conexiones activas, inactivas y en espera
Optimiza consultas lentas antes de agregar más workers
Mantén un ojo en: Conexiones activas
Conexiones inactivas
Tiempo de espera de conexión
Latencia de consultas
Uso de CPU y memoria
En producción, el pooling de conexiones y la optimización de consultas generalmente proporcionan mejor escalabilidad que simplemente aumentar el límite de conexiones de PostgreSQL.
En una implementación estándar de n8n, la fórmula no es simplemente workers * 1. Cada proceso trabajador puede mantener un grupo de conexiones.
La Lógica del Cálculo:
Instancia Principal: Necesita algunas conexiones para la IU, la API y el programador.
Trabajadores: Cada proceso trabajador típicamente mantiene un pequeño grupo. Si tienes 10 trabajadores y cada uno permite un grupo de 10, estás en 100 conexiones solo para trabajadores.
Sobrecarga: Postgres asigna memoria para cada conexión (aproximadamente 2-10MB dependiendo de work_mem). Establecer max_connections demasiado alto (por ejemplo, 5000) sin RAM suficiente hará que el SO elimine Postgres a través del eliminador OOM.
Recomendación: Comienza con max_connections = 200-500 para implementaciones de tamaño medio. Si excedes esto, no simplemente sigas aumentando el número; cambia a un agrupador.
PgBouncer es para entornos de producción de alta concurrencia.
El comportamiento predeterminado de PostgreSQL es «un proceso por conexión», lo que es costoso. PgBouncer actúa como un proxy ligero que gestiona un grupo de conexiones «reales» a la BD mientras permite miles de conexiones «virtuales» de trabajadores de n8n.
Hola @Keira_Becky
La palanca por proceso es DB_POSTGRESDB_POOL_SIZE, que tiene un valor predeterminado de 2, por lo que la huella es aproximadamente (procesos principales + workers + procesadores de webhook) multiplicado por ese valor, y debes dimensionar la base de datos en torno a esa cifra en lugar de estimar según el número de workers. Aumenta el valor por proceso solo cuando los workers realmente están esperando en el pool.
Escala ejecutando menos workers con mayor concurrencia en lugar de muchos workers con baja concurrencia; n8n recomienda 5 o superior por worker porque un gran número de workers con baja concurrencia agota el pool de conexiones y causa retrasos y fallos:
Depende de tu carga de trabajo, pero para la mayoría de aplicaciones de alta concurrencia, el agrupamiento de transacciones suele ser preferido porque permite que las conexiones se reutilicen de manera más eficiente y admite un número mayor de clientes concurrentes.
El agrupamiento de sesiones puede ser una mejor opción si tu aplicación depende de características específicas de la sesión, como tablas temporales o variables de sesión, ya que cada cliente mantiene la misma conexión de base de datos durante toda la sesión.
Antes de elegir un modo, te recomendaría probarlo en un entorno de ensayo y verificar que tus flujos de trabajo de n8n no dependan de comportamientos específicos de la sesión. Luego, monitorea el uso de conexiones, la latencia de consultas y el rendimiento general para confirmar que funciona como se esperaba.
En general, la mejor opción depende de cómo tu aplicación utiliza las conexiones de base de datos, por lo que vale la pena validarlo con cargas de trabajo similares a las de producción antes de realizar el despliegue.
