¿Por qué Immich provoca actividad repetida del disco durante la noche?

Immich puede generar actividad repetida en el disco durante la noche porque el mantenimiento programado, las tareas de la base de datos, los trabajos multimedia en cola o los reintentos continúan después de que las personas dejan de usar la biblioteca.

Que haya tranquilidad en el hogar no significa que el servidor esté inactivo. La pregunta útil es si el mismo proceso y trabajo explican las lecturas o escrituras a la misma hora. Correlaciona primero la actividad y luego decide si se trata de trabajo esperado, de ponerse al día con una acumulación o de un bucle que debería detenerse.

Relaciona el pico de disco con la hora antes de cambiar nada

Empieza con tres noches de marcas de tiempo en lugar de una sola observación ruidosa. Registra cuándo aumenta la E/S de bloques, qué dispositivo está ocupado, si predominan las lecturas o las escrituras y si el patrón comienza casi a la misma hora. Una hora de inicio repetible apunta a un programador; un patrón irregular sugiere más bien llegadas, reintentos u otro contenedor.

Las implementaciones de Immich pueden programar copias de seguridad de la base de datos y tareas orientadas a la integridad durante las horas de menor uso, por lo que un pico de madrugada puede ser deliberado. No desactives un trabajo solo porque activa los discos. Comprueba primero si después de la ventana de actividad aparece una copia de seguridad correspondiente, un resultado de mantenimiento o la finalización de una cola.

El diagnóstico adyacente de ZimaSpace sobre el trabajo en segundo plano de Immich durante las horas de inactividad utiliza la misma regla de las marcas de tiempo: relaciona el síntoma visible con el proceso y el trabajo antes de tratar la “inactividad” como un estado de fallo.

Separa las escrituras de PostgreSQL de las lecturas multimedia

Los cambios en el estado de la aplicación Immich pueden mantener activo PostgreSQL incluso cuando no se abre ninguna foto nueva. Los puntos de control de la base de datos, el registro de escritura anticipada, las tareas relacionadas con vacuum y las actualizaciones habituales de la aplicación tienen una firma de E/S diferente de la exploración de miles de archivos multimedia. Identifica la ruta o el dispositivo que recibe el tráfico antes de culpar a la biblioteca de fotos.

El análisis de observabilidad de PostgreSQL en el análisis de pg_stat_io explica por qué deben separarse las lecturas, las escrituras, la actividad del backend, el comportamiento del comprobador y las escrituras en segundo plano. Usa esta distinción para preguntar si el dispositivo de la base de datos está ocupado porque se persisten transacciones útiles o porque algo está generando actividad repetitiva.

Si las escrituras de la base de datos son pequeñas y periódicas mientras los discos multimedia permanecen inactivos, el comportamiento puede corresponder a tareas normales de mantenimiento de la base de datos. Si el mismo archivo de la base de datos recibe escrituras intensas y sostenidas mientras ningún trabajo avanza, conserva los registros e inspecciona las consultas responsables o el bucle de reinicio en lugar de trasladar toda la biblioteca a un almacenamiento más rápido.

Comprueba si las colas en segundo plano realmente avanzan

Abre la vista de trabajos y compara el trabajo pendiente, activo, fallido y completado antes y después de la ventana nocturna. La generación de miniaturas, el procesamiento de vídeos, la extracción de metadatos, las tareas de aprendizaje automático o el trabajo con una biblioteca importada pueden mantener legítimamente activo el almacenamiento después de un cambio importante. Una acumulación que disminuye demuestra que se está avanzando de forma útil.

Un informe reciente de la comunidad sobre lecturas sostenidas sin explicación muestra el límite diagnóstico opuesto: las lecturas continuas muy elevadas sin trabajo esperado merecen investigación, en lugar de aceptarse como “lo que hace Immich”. Considera la velocidad indicada como un caso concreto, no como una referencia.

Si los mismos pocos trabajos fallan y vuelven a entrar en la cola, la actividad del disco puede repetirse sin generar avances. Captura el primer error y un recurso afectado, y luego aísla ese tipo de trabajo. No borres todas las colas ni vuelvas a generar toda la biblioteca antes de determinar si el bucle se debe a un archivo, permisos, latencia del almacenamiento o una dependencia del servicio.

-15% OFF

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

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

Atribuye la E/S a un proceso en lugar de adivinar por el ruido de las unidades

Utiliza la supervisión de E/S a nivel del host durante la próxima recurrencia para identificar el proceso que lee o escribe en el dispositivo. Después relaciona ese proceso con el servidor de Immich, PostgreSQL, el aprendizaje automático, una herramienta de copias de seguridad, el antivirus, una comprobación del sistema de archivos u otro contenedor no relacionado. Los indicadores luminosos de las unidades y el ruido de los ventiladores no pueden proporcionar esa información de propiedad.

Un flujo de trabajo práctico con iotop demuestra el método centrado en el proceso. Registra varias muestras porque un impulso breve puede desaparecer entre observaciones; el objetivo es capturar el proceso durante la misma ventana en la que aparece el síntoma.

Si Immich no es el principal responsable de la E/S, deja de cambiar la configuración de Immich y sigue el proceso real. Si el responsable es PostgreSQL, Immich o un trabajador relacionado, correlaciona sus registros y el progreso de los trabajos con la muestra de E/S. Así, “el servidor hace ruido todas las noches” se convierte en un componente y un desencadenante concretos.

Define el límite entre el trabajo nocturno normal y un fallo

Considera normal la actividad cuando comienza cerca de un horario conocido o de un cambio reciente en la biblioteca, completa trabajo útil, no deja un recuento de fallos creciente y devuelve la latencia del almacenamiento y la profundidad de la cola a los valores habituales. Registra la duración normal para tener un punto de comparación ante futuros aumentos.

Un debate histórico de Immich sobre las escrituras frecuentes de la base de datos demuestra por qué puede existir cierta actividad de la base de datos sin una acción visible del usuario. Como las versiones y las implementaciones cambian, utiliza el caso solo para justificar la medición separada de la base de datos, no para declarar normales todas las escrituras persistentes.

Escala el problema cuando la E/S continúa después de que las colas se detienen, se repiten los mismos errores, la latencia del almacenamiento afecta al uso diurno, el espacio libre disminuye inesperadamente o el patrón aumenta noche tras noche. Conserva las marcas de tiempo, la E/S de los procesos, los recuentos de trabajos, los registros relevantes, el espacio libre del sistema de archivos y un desencadenante reproducible antes de realizar cambios invasivos.