Immich en un servidor doméstico multiaplicación: cómo los recursos compartidos cambian los resultados
Los resultados de Immich cambian en un servidor con varias aplicaciones porque los contenedores comparten una capacidad finita de CPU, memoria, almacenamiento y red, pese a tener límites de procesos separados.
Una búsqueda de fotos puede ser rápida al mediodía y lenta durante la copia de seguridad, el análisis o la transcodificación de otra aplicación. La configuración de Immich no cambió, pero sí lo hicieron el presupuesto de recursos disponible y el contenido de la caché; por eso, una explicación útil debe incluir toda la carga de trabajo del host.
Los contenedores separan procesos, no la capacidad física
Los contenedores proporcionan espacios de nombres y límites controlables, pero en última instancia se ejecutan en los mismos procesadores y normalmente acceden al mismo controlador de memoria, discos e interfaces de red. Un servicio de Immich puede mantenerse dentro de su propio límite mientras espera detrás de trabajo no relacionado en un dispositivo físico compartido o en el planificador del kernel.
Un informe práctico sobre Immich en varios contenedores describe un host de bajo consumo que ejecuta docenas de contenedores con un uso habitual moderado de CPU. Eso no garantiza resultados idénticos en otros entornos; demuestra por qué el número de servicios por sí solo es una evidencia débil y por qué es necesario observar en el host el trabajo que se ejecuta simultáneamente.
Haz un inventario de todos los servicios vecinos programados o intermitentes: copias de seguridad, análisis multimedia, descargas, bases de datos y transcodificaciones de vídeo. Registra sus horas de inicio junto con la latencia de Immich. La correlación no demuestra causalidad, pero una coincidencia repetida permite identificar una pausa controlada o un experimento de reprogramación para comprobar la interferencia sospechada.
La competencia por la memoria cambia la permanencia en caché
Immich funciona mejor cuando las páginas de la base de datos, las miniaturas y los datos de los modelos que se usan con frecuencia permanecen en la memoria. Un servicio vecino que amplía su conjunto de trabajo puede expulsar esas páginas sin provocar un evento de falta de memoria. La siguiente solicitud debe pagar entonces el coste de acceder al almacenamiento o cargar el modelo, algo que no ocurría mientras los datos estaban en caché.
El análisis de Kingston sobre la memoria de servidores explica que una capacidad suficiente reduce la dependencia de un almacenamiento más lento en aplicaciones que requieren mucha memoria. Aplicado a este caso, el punto no es que todo servidor doméstico necesite memoria empresarial; es que la pérdida de caché puede convertir una solicitud de Immich aparentemente idéntica en una carga de trabajo físico diferente.
Compara la actividad de la caché de páginas, el uso de swap, los fallos mayores y las lecturas del almacenamiento antes y después de que se inicie el servicio vecino. Si pausarlo restaura el comportamiento de las solicitudes en caché sin cambiar Immich, la permanencia en memoria es un factor relevante. Un porcentaje elevado de RAM utilizada, por sí solo, no es suficiente como indicador, porque una caché saludable del sistema de archivos consume intencionadamente la memoria que de otro modo estaría inactiva.
Las colas de almacenamiento vinculan servicios no relacionados
Una copia de seguridad puede transmitir archivos grandes mientras Immich realiza operaciones pequeñas en la base de datos y las miniaturas. Aunque el ancho de banda agregado siga por debajo del máximo anunciado por la unidad, la espera en cola puede aumentar el tiempo de finalización de las solicitudes sensibles a la latencia. El almacenamiento montado en red añade otro planificador y otra ruta de red a la misma cadena de competencia.
El artículo de ZimaSpace sobre la ruta de datos de Immich muestra que la selección de resultados y la visualización de los archivos multimedia son pasos separados con dependencias diferentes. Esta distinción ayuda a identificar la vinculación con el almacenamiento: unos identificadores de resultados rápidos seguidos de miniaturas retrasadas apuntan a una fase posterior de la ruta que una selección de base de datos lenta en sí misma.
Mide la latencia del dispositivo y la profundidad de la cola por punto de montaje mientras reproduces la misma solicitud. Pausa únicamente el servicio vecino que sospeches que realiza muchas operaciones de E/S y repite la prueba una vez estabilizadas las cachés. Si la mejora se mantiene en varias ejecuciones alternas, está justificado separar la programación o el almacenamiento; si no, vuelve a las hipótesis de CPU, memoria o red.
Usa una prueba de aislamiento basada en pausar y repetir
Elige un punto de acceso fijo, como cargar la misma ventana de la cronología o ejecutar una búsqueda inteligente conocida, y define las condiciones de caché fría o caliente. Registra tres ejecuciones con la combinación completa de servicios. Después, pausa un servicio vecino candidato sin reiniciar Immich y repite la misma secuencia del cliente y el mismo intervalo de observación.
Un informe sobre la fuerte competencia de Immich durante el procesamiento posterior a una actualización describe otro servicio de fotos que no podía completar las cargas mientras el host estaba ocupado. Se trata de una configuración concreta, no de un límite universal, pero demuestra que una cola de tareas en segundo plano que funciona correctamente puede consumir suficiente capacidad compartida para perjudicar a otro servicio interactivo.
Acepta que existe interferencia únicamente cuando la pausa produce un cambio de latencia repetible y la espera del recurso correspondiente disminuye junto con ella. Después, prueba una mitigación limitada: reducir la concurrencia, establecer una ventana horaria, aplicar una cuota de CPU, reservar memoria o separar el almacenamiento. Conserva la configuración para poder revertir los cambios, porque aislar un servicio vecino puede dejar al descubierto un segundo límite.
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...
