¿Qué hace que las búsquedas o consultas de Immich se ralenticen a medida que crecen los datos?
La búsqueda de Immich se ralentiza al crecer cuando los índices más grandes y los conjuntos de trabajo superan la capacidad eficiente de la caché, el filtrado o el almacenamiento, no simplemente porque existan más fotos.
Una biblioteca más grande incrementa varias cantidades a la vez: filas, embeddings, metadatos, miniaturas y posibles combinaciones de filtros. Diagnostica qué etapa se ralentiza, porque un almacenamiento de archivos más rápido no puede reparar una ruta de consulta deficiente, mientras que optimizar la base de datos no puede acelerar un montaje remoto de miniaturas.
El crecimiento amplía mucho más que la biblioteca original
Cada recurso añadido puede aportar filas de base de datos, metadatos extraídos, representaciones de búsqueda, rostros, miniaturas y contenido multimedia codificado. Estas estructuras crecen a ritmos diferentes y se consultan de distintas maneras. Por tanto, los terabytes de la biblioteca original no pueden predecir la latencia de búsqueda sin saber cuántas entidades consultables y objetos derivados atraviesa la solicitud.
El análisis de la ruta de datos de Immich de ZimaSpace separa el procesamiento en segundo plano, las representaciones consultables, la selección en la base de datos y el contenido multimedia entregado. Su lección práctica para diagnosticar consultas es que el crecimiento de la biblioteca modifica tanto el catálogo consultable como los archivos presentados después de obtener un resultado, lo que crea más de un posible retraso.
Registra el número de recursos, el tamaño de la base de datos, el tamaño del índice vectorial, el espacio ocupado por las miniaturas y la cardinalidad de los filtros usados con frecuencia en cada hito. Una serie temporal revela qué estructura crece junto con la latencia y evita atribuir a la selección en la base de datos un aumento no relacionado de los bytes de los vídeos originales.
Los índices vectoriales se vuelven sensibles al ajuste en memoria
La búsqueda semántica recorre un índice de representaciones en lugar de leer cada imagen original. A medida que crece ese índice, es posible que su grafo o sus páginas activas ya no permanezcan en la memoria. Los fallos aleatorios de caché convierten entonces el trabajo a velocidad de memoria en lecturas de almacenamiento, lo que hace que aumente la latencia de cola de forma más pronunciada de lo que sugiere el uso medio de la CPU.
Un análisis de ingeniería sobre la búsqueda vectorial en PostgreSQL explica que el rendimiento de HNSW puede degradarse cuando el grafo activo supera la memoria, porque el recorrido de acceso aleatorio se vuelve sensible a los fallos de caché. Las versiones de Immich y las implementaciones de índices pueden cambiar, así que usa esto como un mecanismo que se debe probar, no como una prescripción de configuración.
Mide una consulta semántica fija después de reiniciar, después de un calentamiento y después de acceder a regiones no relacionadas de la biblioteca. Compara las lecturas de la base de datos, el comportamiento de la caché y la latencia del dispositivo. Una mejora notable tras el calentamiento que desaparece al ampliar el conjunto de trabajo respalda la hipótesis de un ajuste insuficiente en memoria; las consultas uniformemente lentas apuntan a otro lugar.
Los filtros y los planes de consulta pueden cambiar con la cardinalidad
La fecha, la persona, el propietario, el álbum y otras condiciones cambian cuántos candidatos quedan antes o durante la clasificación. A medida que cambia la distribución de los datos, el mismo filtro visible puede seleccionar una fracción mucho mayor de la biblioteca. Por tanto, las estadísticas de la base de datos y las decisiones del plan pueden importar incluso cuando el término de búsqueda no cambia.
Una revisión de las limitaciones de pgvector señala que combinar la búsqueda vectorial con filtros de metadatos puede ser difícil y que las cargas vectoriales comparten la CPU, la memoria y la E/S de PostgreSQL con el trabajo transaccional. El artículo ofrece pruebas generales sobre PostgreSQL, por lo que respalda el mecanismo, pero no demuestra un plan de consulta específico de Immich.
Crea búsquedas emparejadas con y sin un filtro, usando conjuntos de resultados conocidos. Captura el tiempo de consulta en el servidor y la actividad de la base de datos, no solo la finalización en el navegador. Si crece el tiempo de selección mientras las miniaturas devueltas siguen cargándose rápido, céntrate en los planes, las estadísticas, el ajuste del índice y la contención, en lugar del almacenamiento multimedia.
Separa la selección de resultados de la representación de resultados
La interfaz puede parecer lenta después de que la base de datos ya haya seleccionado los identificadores de los recursos coincidentes. La representación aún requiere buscar las miniaturas, leer del almacenamiento, transferir la respuesta y decodificarla en el cliente. Un árbol de derivados cada vez mayor o un montaje remoto puede retrasar esta segunda fase mientras la consulta de búsqueda real sigue funcionando correctamente.
Un informe sobre una importación grande describe una lentitud generalizada en Immich mientras cientos de miles de trabajos de metadatos y miniaturas permanecían en cola. Demuestra una presión simultánea en segundo plano, no un límite universal de escala, y muestra por qué las pruebas de crecimiento deben ejecutarse tanto con las colas activas como después de que se hayan vaciado.
Usa los tiempos del navegador o las observaciones de la API para marcar por separado la finalización de la respuesta de resultados y la última miniatura visible. Repite una búsqueda conocida con las colas pausadas y después activas. Si se ralentiza la obtención de los identificadores, investiga las rutas de la base de datos y del índice; si solo se ralentizan las imágenes, inspecciona el almacenamiento de miniaturas, la entrega por red, la decodificación del cliente y las operaciones de E/S en segundo plano que compiten por los recursos.
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...
¿Por qué Immich se comporta de manera diferente después de reiniciar un contenedor?
Tras reiniciar Immich, es normal que se pierda temporalmente la caché; los cambios persistentes en el inicio de sesión, la base de datos o...
