Cómo programa Immich la indexación de búsqueda durante grandes importaciones de bibliotecas móviles

Durante una importación grande desde una biblioteca móvil, Immich puede aceptar recursos más rápido de lo que terminan todos los trabajos en segundo plano relacionados con la búsqueda, por lo que la actualización de la búsqueda puede retrasarse respecto a la finalización de la carga.

Ese retraso solo es un problema de programación cuando los trabajos necesarios están esperando, ejecutándose o compitiendo por recursos compartidos; no es automáticamente un fallo de búsqueda. El modelo útil es el de una canalización: los recursos entrantes generan trabajo, las colas absorben los picos, los trabajadores consumen esas colas y la base de datos recibe los resultados de los que dependen las búsquedas posteriores.

Las importaciones grandes generan distintos tipos de trabajos

Una migración móvil hace más que copiar bytes. Cada recurso aceptado puede generar trabajo adicional para miniaturas, metadatos, procesamiento de vídeo, búsqueda inteligente, rostros u otras funciones activadas. Como estos trabajos tienen costes y dependencias diferentes, una sola importación puede crear varios retrasos con distintas velocidades de procesamiento.

La solicitud de trabajos secuenciales muestra por qué los usuarios notan este comportamiento en hosts con recursos limitados: a veces los operadores quieren que las actividades pesadas se ejecuten de una en una en lugar de superponerse. Esa solicitud demuestra que existe competencia por los recursos, no que la ejecución secuencial sea la mejor opción para todos los servidores.

Mide cada cola según las llegadas, las finalizaciones y los fallos, en lugar de tratar el total pendiente como una sola carga de trabajo. Un gran retraso de miniaturas puede retrasar de forma distinta otros trabajos dependientes que un retraso de transcodificación de vídeo, y una cola que se reduce de forma constante tiene un significado diferente de otra que reintenta repetidamente los mismos elementos.

La prioridad de las colas no equivale al control global de los recursos

Un sistema puede dar prioridad o pausar determinados trabajos y, aun así, mantener activos otros tipos de tareas. Por eso, una herramienta de importación que reduce una clase de actividad en segundo plano no garantiza necesariamente una CPU inactiva, discos silenciosos o una actualización inmediata de la búsqueda. La política de programación y el consumo total de recursos están relacionados, pero no son idénticos.

Una versión de immich-go introdujo trabajos en segundo plano pausados durante las cargas para reducir conflictos. Ese comportamiento pertenece a ese importador y a esa versión, por lo que no debe generalizarse afirmando que todas las importaciones móviles de Immich pausan automáticamente los mismos trabajos.

El límite práctico es el progreso observable. Si las cargas continúan rápidamente mientras las colas relacionadas con la búsqueda permanecen pausadas intencionadamente, es natural que los recursos nuevos se puedan buscar más tarde. Si la cola está habilitada pero las finalizaciones siguen cerca de cero, la cuestión deja de ser la política de programación y pasa a ser un fallo del trabajador, de los recursos o específico del recurso.

La concurrencia puede aumentar el rendimiento y empeorar la capacidad de respuesta

Más trabajadores simultáneos pueden aumentar el número de trabajos completados por minuto hasta que una dependencia compartida se satura. A partir de ese punto, un paralelismo adicional puede aumentar la espera de la base de datos, la latencia del almacenamiento, la presión de memoria o los cambios de contexto. Así, el sistema termina el trabajo en segundo plano más rápido en promedio, mientras que las solicitudes interactivas sufren una latencia de cola más elevada.

Un informe de un usuario sobre colas de trabajos bloqueadas describe una biblioteca grande en la que reducir la concurrencia mejoró el progreso observado. Es una observación específica de una implementación, pero demuestra por qué la concurrencia debe probarse como una variable de la carga de trabajo y no tratarse como un indicador fijo de la capacidad del servidor.

Usa como control interactivo una búsqueda conocida de un álbum ya indexado. Si esa consulta sigue siendo rápida mientras se retrasa la cobertura de las fotos nuevas, la importación es principalmente un problema de actualización. Si incluso las consultas antiguas se ralentizan al mismo tiempo que aumentan la espera de la CPU, del almacenamiento o de la base de datos, la ventana de programación está consumiendo margen de capacidad interactiva.

-15% OFF

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

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

Una cola creciente no es automáticamente un fallo

La acumulación crece siempre que el trabajo llega más rápido de lo que los trabajadores pueden completarlo. Durante una importación histórica intencionada, esto es normal durante cierto tiempo. La señal de fallo no es la longitud máxima de la cola por sí sola, sino la combinación de finalizaciones estancadas, errores repetidos o una acumulación que no se vacía después de que cesen las llegadas.

Debates sobre importaciones grandes, como esta migración de 200.000 fotos, muestran cómo los operadores separan el rendimiento de la carga del procesamiento posterior. La experiencia de la comunidad es útil para identificar qué medir, pero no debe convertirse en una estimación de tiempo universal para otra biblioteca.

Este mecanismo deja de explicar los resultados de búsqueda ausentes cuando el trabajo pertinente ha terminado y el mismo usuario autorizado sigue sin poder recuperar un recurso conocido. En ese momento, revisa la relevancia de la consulta, los filtros, los permisos, el comportamiento del modelo o el procesamiento específico del recurso, en lugar de seguir ajustando la concurrencia de la importación.

Realiza una prueba de programación con dos líneas

Crea una línea fija para el contenido antiguo ya indexado y otra para una pequeña importación nueva. Antes de la importación, registra el tiempo de respuesta de una búsqueda antigua conocida. Durante la importación, registra esa misma búsqueda, la velocidad de carga, el número de trabajos pendientes y completados, los fallos, la presión de la CPU, la presión de memoria y la latencia del almacenamiento a intervalos regulares.

Usa el análisis de ZimaSpace sobre la ruta de datos de Immich para mantener diferenciadas las etapas de transferencia, procesamiento, almacenamiento y búsqueda. Un cuello de botella solo es procesable cuando coincide con la etapa cuyo objetivo de servicio no se está cumpliendo.

Acepta la programación cuando las búsquedas antiguas se mantengan dentro de lo tolerable en tu hogar, las colas de elementos nuevos sigan completándose y la acumulación se vacíe después de que cesen las llegadas. Reduce o reprograma la concurrencia en segundo plano solo cuando la prueba controlada demuestre que el mismo recurso compartido está retrasando tanto el uso interactivo como el progreso de la cola.