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

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.

Explica qué limita a Immich reproduciendo una carga de trabajo fija de subida, navegación, búsqueda o tarea en segundo plano, y correlacionando su tasa de finalización con la saturación de la CPU, la presión de memoria, la latencia del almacenamiento y el rendimiento de red durante el mismo intervalo.

Un porcentaje alto por sí solo no indica un cuello de botella: una CPU al máximo puede ser normal durante el aprendizaje automático, una RAM elevada puede corresponder a la caché del sistema de archivos y una subida lenta puede deberse al teléfono o a la red Wi-Fi. Mide desde el cliente hasta el contenedor y el host, registra el progreso de la cola y, después, cambia una sola restricción sospechosa y repite la prueba. El recurso cuyo alivio mejora la misma carga de trabajo es el límite determinante.

Construye una prueba y una línea temporal repetibles

Elige el síntoma que necesitas mejorar: ingerir un lote fijo de archivos multimedia, abrir originales sin caché, generar miniaturas, ejecutar Smart Search o transcodificar un video. Registra el inicio, el primer resultado utilizable, la finalización, los errores y el movimiento de la cola de tareas. Mezclar tareas produce gráficos de recursos sin aportar una decisión.

Una investigación de un usuario describe una implementación de Immich inusualmente lenta mientras buscaba pruebas sobre CPU, memoria, disco y red. Su enfoque de diagnóstico entre recursos resulta útil, pero tu prueba fija debe determinar la causa en tu servidor.

Repite la prueba una vez después de que las cachés se hayan calentado. Si la segunda ejecución es mucho más rápida, registra el estado de la caché en lugar de considerar que el hardware es inconsistente. Si ambas ejecuciones se detienen en la misma etapa, alinea esa marca de tiempo con las métricas del host y del contenedor y con la tarea responsable.

Identifica las señales de CPU y memoria

Una limitación de CPU muestra una carga ejecutable sostenida en los núcleos relevantes mientras la tarea avanza proporcionalmente; reducir la concurrencia puede mejorar la interacción, pero alargar el tiempo de vaciado. Si un hilo está al máximo mientras el uso total de CPU parece moderado, inspecciona la vista por proceso y por núcleo antes de suponer que queda capacidad disponible.

Una limitación de memoria requiere pruebas de presión: crecimiento de la memoria de intercambio, recuperación de memoria, fallos de página mayores, terminaciones por falta de memoria o reinicios del contenedor. Una memoria usada elevada con caché estable, sin intercambio y con una latencia normal no supera la prueba. Repite la ejecución con un trabajador de menor concurrencia o un modelo más pequeño y compara la finalización.

Un caso reportado de miniaturas en Immich v2.5.5 consumió una cantidad extrema de memoria en una implementación. El informe de memoria limitado a esa versión respalda comprobar la tarea que falla y la versión; no establece un requisito normal de RAM.

Separa la latencia del almacenamiento del rendimiento de red

Para el almacenamiento, observa la latencia del dispositivo, la profundidad de la cola, el rendimiento, el espacio disponible en el sistema de archivos y la disponibilidad de inodos mientras se ejecuta la tarea exacta. Un rendimiento bajo en megabytes por segundo aún puede indicar una limitación del almacenamiento cuando muchas operaciones pequeñas de base de datos y miniaturas esperan a un disco de alta latencia.

Para la red, mide tanto en el cliente como en el servidor y compara las rutas locales y remotas. Un enlace saturado, retransmisiones, reintentos de Wi-Fi o el límite de una VPN que coincidan con la transferencia indican una limitación de red. Si el tráfico de subida termina pero el procesamiento sigue lento, sigue la cola del lado del servidor.

La descripción general de ZimaSpace sobre servicios en hardware antiguo ofrece contexto para planificar el sistema; este diagnóstico debe basarse aun así en la latencia observada y la tasa de trabajo, no en etiquetas de antigüedad.

Alivia una restricción y verifica la misma carga de trabajo

Cambia una sola variable segura: reduce la concurrencia de una tarea, añade una prueba temporal de límite de memoria, mueve una copia de los datos activos a un almacenamiento más rápido o prueba con una red local cableada. Mantén comparables el conjunto de datos, las versiones y el estado de la caché. La mejora tanto de la finalización como de la métrica prevista supera la prueba causal.

No compres hardware basándote en un promedio durante inactividad o en un único pico. Merece la pena actualizar un recurso cuando controla repetidamente la carga de trabajo importante después de excluir errores de software, problemas de espacio libre y tareas programadas en competencia.

Revierte los cambios que trasladen el fallo a otra capa o alarguen las colas más allá del objetivo del servicio. Solicita asistencia con la definición de la carga de trabajo, las marcas de tiempo, las métricas por contenedor, la latencia del disco, las pruebas de red, el progreso de la cola y los registros si el sistema se detiene sin que ningún recurso muestre presión; ese patrón puede indicar un bloqueo, una dependencia o un fallo de la aplicación.

Soporte y Consejos

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.