Cómo cambia la latencia del almacenamiento las copias de seguridad de fotos familiares en Immich

Eva Wong es la Redactora técnica y manitas residente en ZimaSpace. Una geek de toda la vida con pasión por los homelabs y el software de código abierto, se especializa en traducir conceptos técnicos complejos en guías accesibles y prácticas. Eva cree que el autoalojamiento debe ser divertido, no intimidante. A través de sus tutoriales, empodera a la comunidad para desmitificar las configuraciones de hardware, desde construir su primer NAS hasta dominar los contenedores Docker.

La latencia del almacenamiento ralentiza Immich cuando las lecturas o escrituras necesarias tienen que esperar, especialmente cuando las importaciones compiten con la actividad de la base de datos y la navegación en dispositivos compartidos.

Dos teléfonos hacen una copia de seguridad de un viaje de fin de semana mientras otro miembro de la familia recorre álbumes antiguos en el mismo NAS. Los archivos grandes siguen copiándose a una velocidad respetable, pero las miniaturas aparecen de forma irregular y algunas solicitudes se quedan en pausa. La cuestión importante es si la espera del almacenamiento afecta a esas operaciones concretas, no si la unidad puede alcanzar una alta velocidad de transferencia secuencial.

Las transferencias rápidas pueden coexistir con lecturas pequeñas lentas

El rendimiento describe cuántos bytes se transfieren a lo largo del tiempo; la latencia describe cuánto tarda una operación en completarse. Un disco puede entregar eficazmente un flujo secuencial grande y, al mismo tiempo, procesar con menos rapidez pequeñas lecturas dispersas. La navegación en Immich y el estado de la aplicación no siempre se parecen a una única copia de archivos continua, por lo que ambas observaciones pueden coexistir.

El análisis del rendimiento del host examina la espera del dispositivo y el comportamiento de la cola junto con el rendimiento, no solo un único porcentaje de utilización. Mediciones como la latencia de las solicitudes, la profundidad de la cola, la espera de la CPU y los tiempos de la aplicación resultan útiles en conjunto. Su interpretación depende de la pila de almacenamiento, especialmente cuando debajo del volumen indicado hay virtualización, caché o varios dispositivos.

Como ejemplo simplificado, veinte operaciones dependientes que tardan 5 milisegundos cada una consumen 100 milisegundos antes de contar cualquier otro trabajo. A 0,5 milisegundos cada una, consumen 10 milisegundos. Las solicitudes reales pueden ejecutar operaciones simultáneamente o utilizar cachés, por lo que esto explica la espera acumulada, pero no predice el tiempo de respuesta medido de Immich.

Los distintos roles de los datos llegan al almacenamiento de forma diferente

Una carga original añade bytes multimedia; la preparación en segundo plano lee entradas y escribe derivados; la navegación recupera recursos de visualización; la base de datos gestiona registros y consultas de la aplicación. El mismo conjunto físico puede atenderlos a todos, pero sus tamaños de solicitud y patrones de acceso son diferentes. Por tanto, un cambio en el almacenamiento puede ayudar mucho más a una etapa que a otra.

Una instalación de Immich documentada de primera mano colocó PostgreSQL en un SSD y mantuvo los archivos multimedia y las miniaturas en discos duros. Esa configuración mixta documentada demuestra que los roles del almacenamiento pueden separarse; no demuestra que la disposición sea óptima ni cuantifica una mejora de velocidad gracias al SSD. Usa estos ejemplos para identificar a qué rol se refiere una observación antes de generalizar a partir de la lista de hardware.

Para las copias de seguridad familiares, distingue entre los originales aceptados y las vistas previas y registros consultables completamente preparados. Unas escrituras más rápidas de los originales no eliminarán un cuello de botella de inferencia, y una base de datos rápida no garantiza que una lectura de imagen en frío sea rápida. El punto final relevante es la acción doméstica cuyo tiempo se mide, incluidas todas sus etapas necesarias.

Las importaciones convierten el almacenamiento compartido en una cola de espera

Durante una importación, las escrituras en segundo plano y las lecturas interactivas pueden entrar en la misma cola del dispositivo. Más trabajos simultáneos pueden aumentar la cantidad de trabajo en espera incluso cuando crece el rendimiento agregado. El coste visible suele aparecer en algunas solicitudes muy largas, algo que un promedio puede ocultar mientras la mayoría de las miniaturas de la cronología siguen cargándose con normalidad.

La solicitud de almacenamiento separado para las miniaturas surgió explícitamente del deseo de usar almacenamiento rápido para los recursos de navegación generados y almacenamiento masivo para los originales. Esto demuestra que existen prioridades de acceso distintas, no que toda instalación necesite unidades separadas. El beneficio real depende de dónde esperan actualmente las solicitudes y de si el nivel propuesto modifica esa espera.

Este mecanismo deja de explicar la ralentización cuando la latencia del dispositivo permanece estable, pero el cliente se bloquea durante la decodificación, la red reintenta las transferencias o la inferencia sigue saturada. Mover los datos únicamente porque el uso de la CPU es bajo puede entonces pasar por alto la causa. El almacenamiento compartido es una dependencia posible, no un veredicto automático para cada pausa durante las importaciones.

Relaciona la espera del disco con una acción familiar

Elige una acción familiar repetible, como abrir el mismo álbum o cargar una muestra fija. Registra su duración en un host inactivo y durante una importación representativa, junto con la latencia del dispositivo, el comportamiento de la cola, los tiempos de la base de datos y los fallos. Mantén sin cambios la cuenta, la ruta de red, la configuración multimedia y el cliente para que la comparación tenga un significado claro.

La misma distinción del recorrido crítico aparece en el análisis del almacenamiento de servidores domésticos compartidos: la persistencia en segundo plano no implica que toda acción visible espere una escritura en disco. Este principio entre aplicaciones ayuda a enmarcar la observación, pero los tiempos de Home Assistant no son pruebas de rendimiento de Immich. El flujo de fotos debe demostrar por sí mismo la conexión entre la espera del almacenamiento y el retraso visible para el usuario.

Considera el almacenamiento una explicación respaldada cuando sus esperas más largas coincidan de forma constante con la etapa retrasada y otra condición controlada modifique ambas. Si solo la primera lectura en frío es lenta, regístralo por separado de la contención sostenida. Detente en la dependencia identificada; este análisis del mecanismo no requiere pruebas de carga destructivas en la biblioteca de fotos de producción.

Centro de Tecnología e IA

Más para leer

Get More Builds Like This

Stay in the Loop

Get updates from Zima - new products, exclusive deals, and real builds from the community.

Stay in the Loop preferences

We respect your inbox. Unsubscribe anytime.