Cómo optimizar las conexiones de la base de datos de Immich para contenedores simultáneos
Optimiza las conexiones de la base de datos de Immich midiendo la demanda total de sesiones entre todos los procesos de Immich y los demás clientes de PostgreSQL, en lugar de aumentar primero max_connections. La base de datos necesita suficientes sesiones para la carga de trabajo real, además de margen administrativo, pero una concurrencia excesiva puede aumentar el uso de memoria y la contención sin acelerar las consultas.
En un servidor doméstico con varios contenedores, registra las conexiones activas, inactivas y en espera junto con la latencia de las consultas, la CPU, la memoria y la latencia del almacenamiento durante el uso normal y durante un inicio simultáneo. Un error de “demasiados clientes” puede deberse a una configuración agregada, a otro servicio o a una avalancha de reinicios, incluso cuando un contenedor de Immich parezca tener una carga moderada.
Haz un inventario de todos los clientes de PostgreSQL antes de cambiar los límites
Enumera cada proceso o réplica del servidor de Immich, tarea de migración o mantenimiento, trabajo de copia de seguridad, herramienta de supervisión y aplicación no relacionada que se conecte a la misma instancia de PostgreSQL. Cuando sea práctico, asígnales usuarios de base de datos independientes para que pg_stat_activity muestre quién mantiene las sesiones. Registra el valor actual de max_connections y conserva una vía administrativa para responder ante incidentes.
Una discusión sobre “demasiados clientes” de Immich incluye un comentario del proyecto según el cual Immich utilizaba un grupo predeterminado de 10 en esa versión. Una discusión independiente de 2026 señala que varios trabajadores de Immich pueden mantener cada uno su propio grupo. Considera estas cifras como contexto de implementación específico de cada versión, no como un número que debas multiplicar a ciegas en futuras versiones. Si la base de datos ya está cerca de su límite de conexiones mientras Immich está inactivo, identifica al propietario de esas sesiones antes de ajustar Immich. Si hay pocas sesiones activas pero las consultas son lentas, el número de conexiones puede ser un síntoma de la latencia del almacenamiento o de las consultas, y no el principal cuello de botella.
Elabora un presupuesto de conexiones a partir de la concurrencia medida
Reserva sesiones para la administración de la base de datos, las herramientas de copia de seguridad y restauración, las migraciones y la supervisión.
Después, distribuye las conexiones restantes de la aplicación entre el número de procesos de Immich y otras aplicaciones que se ejecuten simultáneamente. El objetivo es que el grupo sea lo bastante grande para que el trabajo normal no espere innecesariamente, pero no mayor de lo que la base de datos pueda ejecutar de forma eficiente.
Un análisis del dimensionamiento de grupos de conexiones de PostgreSQL describe el grupo ideal como uno suficientemente grande para la demanda normal, pero tan pequeño como sea práctico, porque menos sesiones del servidor reducen la contención. Aplica ese principio a la demanda observada de Immich en lugar de copiar el tamaño de un grupo de conexiones de un servidor web utilizado para otra carga de trabajo.
Si la versión de Immich no expone un control compatible para el tamaño del grupo, no modifiques componentes internos únicamente para alcanzar una cifra objetivo. Controla lo que sí puedas: el número de réplicas de la aplicación, los clientes no relacionados, el momento de los reinicios, la coincidencia con las copias de seguridad y la capacidad de la base de datos. Vuelve a evaluar la configuración compatible cuando cambien las versiones.
Reduce la rotación de conexiones y las esperas de la base de datos antes de añadir más sesiones
Escalona el inicio de los contenedores para que Immich, las herramientas de análisis, los trabajos de copia de seguridad y otras aplicaciones no vuelvan a conectarse ni ejecuten migraciones todos a la vez. Usa comprobaciones de estado y disponibilidad que esperen a que PostgreSQL pueda utilizarse, pero evita los bucles de reintento demasiado frecuentes, que pueden crear una avalancha de conexiones mientras la base de datos aún se recupera.
La guía de ZimaSpace sobre la seguridad de una base de datos externa para Immich establece un límite importante: una vez que PostgreSQL se separa de la pila predeterminada, las responsabilidades relacionadas con la versión, las extensiones, los privilegios, las copias de seguridad y las reversiones pasan a ser explícitas. No introduzcas un proxy de conexiones ni otro servidor de base de datos únicamente para ocultar consultas lentas o un almacenamiento saturado.
Si muchas sesiones están inactivas y el número de aplicaciones es legítimamente alto, un agrupador de conexiones puede reducir las sesiones del servidor en algunas arquitecturas de PostgreSQL, pero solo después de probar la versión exacta de Immich, las migraciones, la semántica de las transacciones y el comportamiento de las instrucciones preparadas. El agrupamiento no sustituye la corrección de un cliente descontrolado ni de una base de datos sobrecargada.
Valida la configuración con cargas simultáneas, búsquedas, trabajos y reinicios
Construye un pico reproducible: ejecuta cargas representativas desde móviles, una búsqueda o exploración de contenido antiguo y la combinación habitual de trabajos en segundo plano mientras los demás contenedores previstos están activos. Registra el número de conexiones por usuario y estado, los errores de adquisición o de solicitudes, la latencia de las consultas, la CPU y la memoria de la base de datos y la latencia del disco. Después, repite la prueba tras un único cambio.
Una configuración aprobada mantiene las sesiones por debajo del límite de fallos con margen administrativo, evita los errores de “demasiados clientes”, mantiene la latencia de las consultas dentro del objetivo del hogar y permite que las colas se vacíen después del pico. Solo se justifican más conexiones cuando las solicitudes esperan realmente una sesión mientras la base de datos todavía dispone de capacidad de CPU, memoria y E/S.
Reinicia una vez la pila de aplicaciones y después el host para probar el mayor pico de conexiones. Si el fallo aparece únicamente durante el inicio, corrige el orden de arranque o el comportamiento de los reintentos en lugar de aumentar el límite permanente. Si las sesiones se acumulan con el tiempo, captura los usuarios y las consultas responsables y analiza ese patrón de fuga con las versiones y las pruebas del estado de las conexiones.
Productos recomendados
Soporte y Consejos
Más para leer
Cómo evitar trabajos o importaciones duplicados en Immich
Separa los trabajos repetidos de los recursos duplicados. Usa una única ruta de ingesta canónica, controla los reintentos y los cambios de ruta, y...
Cómo reparar Immich después de que su volumen de base de datos se llene
Nunca elimines el WAL de PostgreSQL para liberar espacio. Detén las escrituras de Immich, conserva el estado de la base de datos, añade capacidad...
¿Por qué Immich recrea los archivos faltantes con el propietario incorrecto?
Immich no debería recrear silenciosamente los originales de origen que falten. Identifica el tipo de archivo regenerado y el programa que lo escribió, y...
