¿Cuántas tareas simultáneas puede gestionar Immich antes de que se deteriore la capacidad de respuesta de las búsquedas?
Immich no tiene un número de tareas universalmente seguro; las búsquedas se degradan cuando los trabajadores simultáneos saturan el recurso que también necesitan las solicitudes interactivas.
Dos servidores pueden ejecutar el mismo número de trabajos de miniaturas, metadatos y aprendizaje automático, y aun así producir latencias de búsqueda muy diferentes. Por tanto, el límite útil es la carga de trabajo mixta máxima que mantiene un objetivo de respuesta interactiva definido mientras la cola sigue vaciándose.
El número de tareas no describe la carga de trabajo
Un valor de concurrencia solo indica cuántos trabajadores se permiten, no mide directamente la presión. La generación de miniaturas, la transcodificación de vídeo, la extracción de metadatos y la inferencia de aprendizaje automático realizan diferentes cantidades de trabajo de cómputo y almacenamiento. Cuatro trabajos ligeros de metadatos pueden mantener la interfaz receptiva, mientras que dos trabajos de vídeo pueden sobrecargar mucho más el mismo host.
Un informe de la comunidad sobre un uso elevado de CPU por parte del aprendizaje automático describe cómo se redujeron los trabajos simultáneos después de una gran importación, lo que disminuyó la carga y prolongó el tiempo de finalización. Esa observación respalda el equilibrio central: una menor concurrencia protege la capacidad de respuesta en primer plano al permitir que el trabajo pendiente se procese más lentamente, no al eliminar el trabajo subyacente.
Trata cada cola como una clase de carga de trabajo. Registra qué trabajos están activos, qué tipo de contenido procesan y si hay aceleración disponible. Un total seguro derivado de archivos JPEG pequeños no puede transferirse a fotos RAW o vídeos largos, porque el trabajo representado por cada espacio ha cambiado.
Las búsquedas se degradan en el primer punto de saturación compartido
La búsqueda interactiva atraviesa varias capas compartidas: la solicitud llega a la aplicación, la base de datos selecciona los resultados, se leen las miniaturas y un cliente las muestra. Los trabajadores en segundo plano pueden competir en más de una capa. La primera capa saturada se convierte en el límite práctico de concurrencia, aunque todos los contenedores sigan funcionando correctamente.
Un debate sobre el rendimiento de Immich describe una carga retrasada de miniaturas en un host con un ancho de banda nominal adecuado, lo que ilustra por qué la velocidad del enlace por sí sola no puede identificar el cuello de botella. La planificación de CPU, las lecturas de la base de datos, la latencia del sistema de archivos y la entrega al cliente siguen siendo posibilidades hasta que las mediciones indiquen qué espera aumenta durante la solicitud lenta.
La utilización debe analizarse junto con la latencia. Una CPU muy utilizada con una latencia de búsqueda estable puede representar una saturación productiva, mientras que un uso moderado de CPU junto con un aumento de la espera del disco puede identificar una cola de almacenamiento. La presión de memoria importa cuando la recuperación de memoria o el intercambio añaden latencia, no simplemente porque el sistema operativo utilice la RAM disponible como caché.
La capacidad de búsqueda puede retrasarse sin que las consultas sean lentas
Una consulta rápida puede devolver una colección buscable incompleta cuando los recursos nuevos aún no han terminado de indexarse. A la inversa, todos los elementos pueden estar ya indexados mientras las consultas son lentas porque el acceso a la base de datos o al almacenamiento está en contención. Llamar a ambas condiciones «degradación de la búsqueda» oculta dos resultados finales diferentes y lleva a ajustar la concurrencia de forma incorrecta.
La explicación de ZimaSpace sobre la ruta de datos de Immich separa la aceptación de cargas, la disponibilidad de vistas previas y la recuperación semántica como resultados finales distintos. Esa distinción es esencial durante las pruebas de carga: la marca de tiempo en que llega un archivo no puede sustituir a la marca de tiempo en que su representación pasa a estar disponible para las búsquedas.
Registra dos tiempos para una cohorte de importación fija. Uno mide la latencia de las consultas interactivas frente a fotos de control ya indexadas; el otro mide el tiempo hasta que las fotos recién importadas aparecen en búsquedas predeterminadas. El primero protege la experiencia del usuario activo, mientras que el segundo muestra el coste de rendimiento de reducir la concurrencia.
Encuentra el límite con una prueba escalonada, no con una suposición
Crea un lote de contenido representativo y elige tres búsquedas fijas que devuelvan recursos conocidos. Comienza con un trabajador en cada cola activa, ejecuta la importación y registra la latencia mediana y de cola lenta de las búsquedas, la velocidad de vaciado de la cola, la CPU, la presión de memoria, el rendimiento de red y la espera del almacenamiento durante el mismo periodo de observación.
La guía general sobre cuellos de botella recomienda correlacionar los cambios en la carga de trabajo con las esperas de CPU, memoria, disco, red y dependencias, en lugar de seleccionar el gráfico que parezca más ocupado. Aumenta solo un control de concurrencia por ejecución. Repetir la misma secuencia de búsquedas y la misma cohorte de contenido permite identificar la variable modificada.
Detente en el primer paso en que no se cumpla el objetivo de latencia de cola lenta de las búsquedas, el servidor comience a usar memoria de intercambio, la espera del almacenamiento permanezca elevada, aparezcan errores o la cola en segundo plano deje de obtener un rendimiento útil. Repite el paso anterior después de un reinicio en frío y de nuevo con el sistema en estado activo. Ese paso inferior y reproducible es el límite defendible para esta carga de trabajo.
Productos recomendados
Centro de Tecnología e IA
Más para leer
¿Qué es el estado de Immich y qué partes deben conservarse?
El estado de Immich incluye los originales, las relaciones de la base de datos, la identidad, la configuración y los derivados; conserva cada elemento...
¿Cómo gestiona Immich la autenticación en sesiones locales y remotas?
Immich utiliza identidad del lado del servidor con sesiones de cliente, mientras que los encabezados del proxy, los orígenes y las redirecciones de OIDC...
¿Qué hace que las búsquedas o consultas de Immich se ralenticen a medida que crecen los datos?
El crecimiento de Immich puede ampliar los índices, expulsar las páginas activas, complicar los filtros y retrasar la entrega de contenido multimedia; separa estas...
