Cómo comprobar si Immich está limitado por la CPU, la memoria, la red o el almacenamiento

Prueba Immich con una operación repetible, correlaciona su latencia con las esperas de recursos y confirma el cuello de botella sospechado mediante una intervención controlada.

Una instantánea del panel no puede distinguir la actividad útil de la contención perjudicial. Mide un solo endpoint —como la aceptación de cargas, la visualización de miniaturas o la respuesta de la búsqueda inteligente— con medios y condiciones del cliente fijos, y luego cambia únicamente el recurso sospechado de limitar el rendimiento.

Define un endpoint y una línea base reproducible

Empieza por nombrar el endpoint en términos observables. «Immich va lento» no se puede probar, pero «las mismas veinte miniaturas de la cronología tardan cuatro segundos en aparecer después de reiniciar» sí. Fija el cliente, la ruta de red, la cuenta, el conjunto de fotos y la condición inicial para que las ejecuciones posteriores difieran únicamente en una variable intencionada.

El modelo de ruta de datos de Immich muestra que la carga, el procesamiento, la selección de la base de datos y la entrega de medios atraviesan dependencias diferentes. Una prueba centrada en la selección de resultados de búsqueda debe cronometrar por separado la lista de resultados y la representación de imágenes; de lo contrario, una consulta rápida seguida de lecturas de archivos lentas se informa como un retraso único e indiferenciado.

Ejecuta la línea base al menos tres veces y conserva tanto la mediana como el percentil útil más lento. Registra la profundidad de la cola, la CPU por contenedor, la presión de memoria, la actividad de intercambio, el rendimiento de red y las retransmisiones, la latencia del disco y la profundidad de la cola de E/S. Una afirmación sobre un cuello de botella debe hacer coincidir la señal del recurso con el retraso del endpoint.

Separa la saturación de CPU de la presión de memoria

Una ejecución limitada por la CPU mantiene el trabajo listo esperando tiempo de procesador, por lo que la latencia del endpoint debería seguir la saturación sostenida de los núcleos o la limitación térmica. Una ejecución limitada por la memoria puede mostrar, en cambio, recuperación de memoria, intercambio, terminaciones de contenedores o cargas repetidas de modelos. Ambas situaciones pueden hacer que los gráficos de CPU parezcan ocupados, pero sus intervenciones producen respuestas diferentes.

Una guía independiente de recursos de Immich reciente desglosa el uso entre el servidor, PostgreSQL, Redis y los componentes de aprendizaje automático, en lugar de tratar la RAM total como un único requisito. Esta perspectiva por servicio es importante porque puede coexistir memoria libre en el host con un límite de contenedor insuficiente, mientras que una caché de archivos grande no implica automáticamente una situación crítica.

Verifica la presión de CPU reduciendo la concurrencia de los trabajadores en segundo plano o asignando más CPU mientras mantienes constante la memoria. Verifica la presión de memoria eliminando la actividad de intercambio o aumentando un límite de memoria restringido sin cambiar el número de trabajadores. Si el endpoint no mejora de forma constante, descarta ese recurso como el límite principal de esta prueba.

Distingue el retraso de red del retraso de almacenamiento

Los límites de red y almacenamiento suelen aparecer juntos porque los medios remotos atraviesan ambos. Un enlace saturado limita los bytes transferidos por segundo, mientras que la contención del almacenamiento aumenta el tiempo de finalización de las lecturas o escrituras incluso en un enlace inactivo. Por tanto, probar únicamente desde un cliente remoto puede atribuir erróneamente la entrega lenta de archivos a la capa equivocada.

El análisis de SSD de Kingston destaca el trabajo en segundo plano, el comportamiento del firmware, el almacenamiento en caché y los comandos del host que afectan a la respuesta del almacenamiento más allá de la velocidad secuencial anunciada. En Immich, las numerosas operaciones pequeñas de miniaturas y bases de datos hacen que la latencia y el comportamiento de las colas sean más informativos que el resultado de ancho de banda de un único archivo grande.

Repite el endpoint desde un cliente local conectado por cable y luego desde la ruta remota habitual, sin cambiar el conjunto de datos del servidor. Lee por separado un conjunto representativo de archivos en el host y observa la latencia del dispositivo. Una mejora únicamente en el cliente local implica a la ruta de red; las esperas persistentes en el host implican al almacenamiento o a su punto de montaje.

-15% OFF

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

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

Usa una matriz de intervenciones para aceptar o rechazar cada causa

Escribe cuatro filas antes de realizar las pruebas: CPU, memoria, red y almacenamiento. Asigna a cada fila un síntoma esperado, una intervención específica y una condición de rechazo. Esto evita que el diagnóstico cambie después de ver los resultados y hace que un hallazgo negativo sea útil, en lugar de convertirse en un motivo para comprar varias actualizaciones a la vez.

Un informe de campo público sobre Immich con miniaturas retrasadas pese a disponer de un ancho de banda de Internet considerable demuestra por qué las especificaciones por sí solas son insuficientes. La evidencia relevante es si un cambio específico mueve el endpoint medido mientras se mantienen fijos el grupo de medios, el estado de la caché, las tareas, el cliente y la versión de la aplicación.

Acepta la CPU solo si aliviar la carga del procesador mejora la latencia; la memoria, solo si lo hace aliviar la recuperación de memoria; la red, solo si mejora al aliviar la ruta; y el almacenamiento, solo si disminuye la espera del dispositivo o del punto de montaje. Si dos intervenciones ayudan, repítelas en ambos órdenes porque el segundo cuello de botella puede hacerse visible únicamente después de eliminar el primero.