Cómo reducir el tiempo de inicio de Immich después de reiniciar

Si Immich tarda en estar utilizable únicamente después de reiniciar el servidor doméstico, mide qué dependencia está lista en último lugar antes de intentar «acelerar» la aplicación.

Un reinicio puede hacer que los montajes de almacenamiento, PostgreSQL, las rutas de red, el DNS u otros servicios aparezcan en un orden distinto al de un reinicio normal de Immich. La métrica útil no es cuándo Docker indica que se inició un contenedor, sino el tiempo transcurrido desde el arranque del host hasta que la base de datos acepta solicitudes reales, el almacenamiento necesario está montado, Immich deja de reintentar las dependencias y un cliente puede cargar la cronología. Registra esa secuencia una vez y elimina la espera o el bucle de reintentos real.

Mide la cronología de arranque antes de cambiar nada

Reinicia durante una ventana de mantenimiento y registra la hora de cuatro puntos: el host está accesible, el almacenamiento relacionado con Immich está montado, la base de datos está operativa e Immich se puede utilizar desde un cliente. Registra también las horas de inicio de los contenedores, los estados de salud, el número de reinicios y la primera línea de registro útil de cada servicio. Así, «el arranque parece lento» se convierte en un retraso acotado.

Compara el resultado con un reinicio normal de la pila cuando el host ya está completamente iniciado. Si Immich se reinicia rápido más tarde, pero solo es lento durante el arranque, el cuello de botella probablemente sea un problema de orden o una dependencia de disponibilidad externa a la aplicación. Si ambos casos son igual de lentos, investiga el trabajo de la base de datos, la latencia del almacenamiento, las migraciones o la presión sobre la CPU.

No optimices todas las capas a la vez. El resultado de esta etapa debe ser identificar el primer componente cuya disponibilidad se retrasa respecto al inicio de su contenedor o que obliga repetidamente a Immich a reintentar.

Comprueba que el almacenamiento esté listo antes de iniciar Immich

Confirma que todas las montajes vinculados y las rutas respaldadas por red existan y contengan los datos esperados antes de que se inicien los servicios de Immich. Un punto de montaje puede existir como un directorio local vacío mientras el disco real o el recurso compartido NAS aún no está disponible, lo que puede hacer que la aplicación se inicie sobre la vista del sistema de archivos incorrecta.

Si la base de datos o los archivos multimedia están en un almacenamiento que aparece tarde durante el arranque, haz que el servicio dependa de ese montaje a nivel del host o retrasa la pila hasta que se confirme que el montaje está presente. La prueba debe comprobar el sistema de archivos montado real o un marcador conocido, no solo que exista el nombre del directorio.

Después de ajustar la disponibilidad del almacenamiento, vuelve a reiniciar y compara las mismas marcas de tiempo. Un cambio satisfactorio elimina los reintentos o el comportamiento con rutas vacías sin cambiar la configuración de Immich en estado estable. Si el almacenamiento ya estaba listo bastante antes que la base de datos, pasa a la secuencia de dependencias en lugar de añadir temporizadores de espera arbitrarios.

Espera a que la base de datos esté operativa, no solo en ejecución

PostgreSQL puede tener un contenedor en ejecución antes de estar listo para aceptar la carga de trabajo de la aplicación, especialmente después de una detención incorrecta, un retraso del almacenamiento, una inicialización o una recuperación. Compara el cambio de estado de salud de la base de datos con los primeros errores de conexión de Immich en los registros de arranque.

Un orden de inicio sencillo puede lanzar un contenedor dependiente antes de que el servicio que necesita esté realmente listo. Cuando la versión de Compose y las definiciones de servicio lo permitan, las comprobaciones de dependencias basadas en el estado de salud pueden distinguir entre «contenedor iniciado» y «dependencia lista». Úsalas para eliminar ciclos de reconexión evitables en lugar de ocultar una dependencia lenta o poco saludable.

Mantén la comprobación de disponibilidad limitada y significativa. Una comprobación de la base de datos debe demostrar que puede aceptar la conexión que Immich necesita; no debe ejecutar una consulta costosa que añada su propio retraso. Cuando la disponibilidad de la base de datos preceda sistemáticamente al inicio de Immich, repite la prueba de reinicio del host antes de cambiar cualquier otra cosa.

-15% OFF

ZimaBoard 2 - Mini servidor doméstico para tu gran idea

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

Separa los bucles de reintento del trabajo de inicio legítimo

Si el almacenamiento y PostgreSQL están listos, pero Immich sigue tardando mucho más después de un reinicio, revisa los registros de la aplicación y de los trabajadores en busca de fallos de conexión repetidos, comprobaciones de salud fallidas, migraciones, inicialización de tareas o presión sobre los recursos. Los errores repetidos a intervalos fijos suelen indicar una espera; un uso sostenido de CPU o disco con progreso indica trabajo real de inicio.

El orden de las dependencias funciona mejor cuando se combina con comprobaciones de salud significativas en lugar de breves retrasos fijos. Un patrón de comprobación de salud de Compose puede ayudar a evitar que una aplicación compita con una base de datos o una caché que aún se está inicializando. Mantén las comprobaciones realistas; reducir los intervalos hasta que un servicio enfermo parezca saludable no mejora el arranque.

Si el número de reinicios aumenta durante el arranque, detén la avalancha e identifica la primera dependencia no disponible antes de ajustar la CPU, la memoria o los parámetros de inicio de la imagen. Una comprobación de dependencias en bucles de reinicio de contenedores ayuda a separar un prerrequisito lento de un problema dentro del propio Immich.

Reinicia de nuevo y verifica el tiempo hasta la disponibilidad real

Después de un cambio específico, realiza un reinicio completo del host y registra las mismas marcas de tiempo. Una mejora real debe acortar el intervalo entre la disponibilidad de la dependencia y un cliente de Immich utilizable, sin introducir nuevos bucles de reinicio, montajes ausentes ni errores en segundo plano.

Prueba algo más que la página de inicio de sesión web. Abre varias fotos antiguas, ejecuta una búsqueda, carga un vídeo representativo, confirma que un cliente móvil se conecta y sube un archivo prescindible para ejercitar las rutas de lectura y escritura. Para el uso doméstico, el servidor no está «iniciado» hasta que esas operaciones habituales funcionan.

Haz un segundo reinicio después de la primera prueba satisfactoria para asegurarte de que el resultado no se debió a la caché o a un evento puntual de sincronización de red. Si el arranque sigue siendo irregular, conserva los registros de arranque y concéntrate en el componente cuya disponibilidad varía entre ejecuciones. No ocultes la variabilidad con un retraso fijo más largo salvo que no exista una señal de disponibilidad mejor.