Explica qué limita a Immich reproduciendo una carga de trabajo fija de subida, navegación, búsqueda o tarea en segundo plano, y correlacionando su tasa de finalización con la saturación de la CPU, la presión de memoria, la latencia del almacenamiento y el rendimiento de red durante el mismo intervalo.
Un porcentaje alto por sí solo no indica un cuello de botella: una CPU al máximo puede ser normal durante el aprendizaje automático, una RAM elevada puede corresponder a la caché del sistema de archivos y una subida lenta puede deberse al teléfono o a la red Wi-Fi. Mide desde el cliente hasta el contenedor y el host, registra el progreso de la cola y, después, cambia una sola restricción sospechosa y repite la prueba. El recurso cuyo alivio mejora la misma carga de trabajo es el límite determinante.
Construye una prueba y una línea temporal repetibles
Elige el síntoma que necesitas mejorar: ingerir un lote fijo de archivos multimedia, abrir originales sin caché, generar miniaturas, ejecutar Smart Search o transcodificar un video. Registra el inicio, el primer resultado utilizable, la finalización, los errores y el movimiento de la cola de tareas. Mezclar tareas produce gráficos de recursos sin aportar una decisión.
Una investigación de un usuario describe una implementación de Immich inusualmente lenta mientras buscaba pruebas sobre CPU, memoria, disco y red. Su enfoque de diagnóstico entre recursos resulta útil, pero tu prueba fija debe determinar la causa en tu servidor.
Repite la prueba una vez después de que las cachés se hayan calentado. Si la segunda ejecución es mucho más rápida, registra el estado de la caché en lugar de considerar que el hardware es inconsistente. Si ambas ejecuciones se detienen en la misma etapa, alinea esa marca de tiempo con las métricas del host y del contenedor y con la tarea responsable.
Identifica las señales de CPU y memoria
Una limitación de CPU muestra una carga ejecutable sostenida en los núcleos relevantes mientras la tarea avanza proporcionalmente; reducir la concurrencia puede mejorar la interacción, pero alargar el tiempo de vaciado. Si un hilo está al máximo mientras el uso total de CPU parece moderado, inspecciona la vista por proceso y por núcleo antes de suponer que queda capacidad disponible.
Una limitación de memoria requiere pruebas de presión: crecimiento de la memoria de intercambio, recuperación de memoria, fallos de página mayores, terminaciones por falta de memoria o reinicios del contenedor. Una memoria usada elevada con caché estable, sin intercambio y con una latencia normal no supera la prueba. Repite la ejecución con un trabajador de menor concurrencia o un modelo más pequeño y compara la finalización.
Un caso reportado de miniaturas en Immich v2.5.5 consumió una cantidad extrema de memoria en una implementación. El informe de memoria limitado a esa versión respalda comprobar la tarea que falla y la versión; no establece un requisito normal de RAM.
Separa la latencia del almacenamiento del rendimiento de red
Para el almacenamiento, observa la latencia del dispositivo, la profundidad de la cola, el rendimiento, el espacio disponible en el sistema de archivos y la disponibilidad de inodos mientras se ejecuta la tarea exacta. Un rendimiento bajo en megabytes por segundo aún puede indicar una limitación del almacenamiento cuando muchas operaciones pequeñas de base de datos y miniaturas esperan a un disco de alta latencia.
Para la red, mide tanto en el cliente como en el servidor y compara las rutas locales y remotas. Un enlace saturado, retransmisiones, reintentos de Wi-Fi o el límite de una VPN que coincidan con la transferencia indican una limitación de red. Si el tráfico de subida termina pero el procesamiento sigue lento, sigue la cola del lado del servidor.
La descripción general de ZimaSpace sobre servicios en hardware antiguo ofrece contexto para planificar el sistema; este diagnóstico debe basarse aun así en la latencia observada y la tasa de trabajo, no en etiquetas de antigüedad.
Alivia una restricción y verifica la misma carga de trabajo
Cambia una sola variable segura: reduce la concurrencia de una tarea, añade una prueba temporal de límite de memoria, mueve una copia de los datos activos a un almacenamiento más rápido o prueba con una red local cableada. Mantén comparables el conjunto de datos, las versiones y el estado de la caché. La mejora tanto de la finalización como de la métrica prevista supera la prueba causal.
No compres hardware basándote en un promedio durante inactividad o en un único pico. Merece la pena actualizar un recurso cuando controla repetidamente la carga de trabajo importante después de excluir errores de software, problemas de espacio libre y tareas programadas en competencia.
Revierte los cambios que trasladen el fallo a otra capa o alarguen las colas más allá del objetivo del servicio. Solicita asistencia con la definición de la carga de trabajo, las marcas de tiempo, las métricas por contenedor, la latencia del disco, las pruebas de red, el progreso de la cola y los registros si el sistema se detiene sin que ningún recurso muestre presión; ese patrón puede indicar un bloqueo, una dependencia o un fallo de la aplicación.
Soporte y Consejos
Más para leer

Cómo optimizar las conexiones de la base de datos de Immich para contenedores simultáneos
No aumentes primero max_connections. Mide las sesiones de Immich, suma la demanda total de todos los contenedores, conserva margen para la administración y ajusta...

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...

