¿Qué límite de memoria deberías establecer para Immich?

No establezcas un límite de memoria para Immich basándote en una cifra universal de GB. Un objetivo de RAM para el host y un límite por contenedor resuelven problemas distintos: el host debe admitir toda la pila, mientras que el límite del contenedor debe protegerlo sin interrumpir una carga de trabajo legítima de Immich.

Navegar por una biblioteca procesada puede parecer poco exigente, mientras que un arranque en frío del aprendizaje automático, una importación grande, la generación de miniaturas, el análisis facial o el procesamiento de vídeo consumen mucha más memoria. Mide la carga de trabajo más exigente que realmente necesites, reserva margen para PostgreSQL y el sistema operativo, y considera los cierres repetidos por falta de memoria (OOM) como un límite fallido, no como una limitación normal.

Mide la presión de memoria antes de elegir el límite

Registra la memoria en tres estados: navegación tranquila, una carga diaria representativa y la carga de trabajo en segundo plano más exigente que tengas prevista. Captura el uso del contenedor, la memoria disponible del host, la actividad de intercambio, los eventos OOM y si los trabajos siguen avanzando. Un único pico de docker stats no es suficiente, porque la contabilidad de memoria de Linux incluye varios tipos de memoria con distinto comportamiento de recuperación.

Un desglose de la memoria de cgroup de Docker útil separa la memoria anónima, la caché respaldada por archivos y el slab, en lugar de tratar el total bruto como igualmente peligroso. Una caché de archivos estable con suficiente margen en el host no es lo mismo que una memoria anónima que aumenta constantemente, presión de intercambio o un contador OOM del cgroup que se incrementa durante el mismo trabajo de Immich.

Supera esta etapa cuando puedas identificar una marca de agua máxima repetible y explicar si se compone principalmente de caché recuperable o de memoria de trabajo activa. Si el uso sigue aumentando con una carga de trabajo sin cambios, un contenedor termina repetidamente por falta de memoria o el host empieza a intercambiar datos intensivamente, deja de dimensionar a partir de esa ejecución y diagnostica primero el crecimiento anómalo.

Dimensiona el límite en torno a la carga de trabajo válida más exigente de Immich

Elige la carga de trabajo que deba seguir siendo compatible después de aplicar el límite. Para un hogar, puede consistir en cuatro teléfonos cargando contenido mientras Smart Search y los trabajos de reconocimiento facial se ponen al día; para otro, puede ser una importación inicial grande seguida de una navegación normal. Mantén fijos el conjunto de datos, el modelo, la configuración de concurrencia y los demás contenedores durante la medición, para que el límite refleje una promesa de servicio definida.

Establece el límite estricto por encima del pico observado de memoria no recuperable, con un margen medible suficiente para los picos breves, y conserva memoria del host para PostgreSQL, la caché del sistema de archivos, el entorno de ejecución de contenedores y los servicios no relacionados. La lista de comprobación de ZimaSpace sobre señales de advertencia de recursos para IA local resulta útil porque el calor, el intercambio y los reinicios repentinos revelan una presión a nivel del host que un gráfico exclusivo de Immich puede pasar por alto. No interpretes que «el contenedor alcanzó el límite una vez» como una prueba de que necesitas más RAM. El límite de fallo importante es si la misma carga de trabajo válida se ralentiza gravemente, pierde trabajos, intercambia datos continuamente o termina por falta de memoria. A la inversa, un límite es demasiado permisivo si Immich puede privar de recursos a la base de datos o al host antes de que su propio cgroup se convierta en el límite.

Reduce la carga de trabajo antes de aumentar el límite por un crecimiento anómalo

Si el límite propuesto falla únicamente durante una clase de trabajo en segundo plano, reduce la concurrencia de ese trabajo o aísla esa etapa antes de elevar el límite. El aprendizaje automático, la generación de miniaturas, el procesamiento de vídeo y las tareas de base de datos pueden tener perfiles de memoria distintos. Un lote activo más pequeño puede tardar más en finalizar, pero mantendrá la interfaz del hogar receptiva y permitirá que el host se recupere.

También importan los fallos específicos de cada versión. Un informe de memoria de Immich v3.0.3 describió un trabajador de aprendizaje automático que crecía hasta que un límite del cgroup provocaba un error OOM después de una condición anómala relacionada con la configuración regional. Ese caso no define el uso normal de RAM de Immich; demuestra por qué el crecimiento inexplicado debe tratarse primero como una posible rama de software o configuración antes de aumentar permanentemente el presupuesto del host.

Después de cambiar una sola variable de concurrencia, modelo o versión, vuelve a ejecutar la misma carga de trabajo. Conserva el cambio únicamente si tanto el patrón de memoria como el trabajo original mejoran en la dirección esperada. Si la memoria sigue aumentando sin acercarse a una meseta estable, conserva los registros y los detalles de la versión y escala el problema en lugar de convertir el límite estricto en una cifra cada vez mayor.

Featured

ZimaCube 2 NAS personal en la nube para el hogar

ZimaCube2

$799.00 - $2,499.00

Buy Now

Valida el límite después de un reinicio en frío y de un ciclo intensivo

Reinicia el host para que las cachés y la permanencia de los modelos comiencen desde un estado en frío conocido. Realiza las comprobaciones normales de inicio de sesión y navegación, y después ejecuta la carga representativa y el trabajo en segundo plano. Registra el pico de memoria anónima, la caché, el intercambio, los contadores OOM, la respuesta de la base de datos, el tiempo de vaciado de la cola y si otro contenedor importante sigue respondiendo.

Un límite aprobado supera tanto el arranque en frío como el ciclo normal más exigente sin cierres por falta de memoria, saturación prolongada del intercambio, reinicios repetidos del contenedor ni una cola que deje de vaciarse. También debe dejar suficiente margen en el host para tareas de recuperación, como un volcado de la base de datos o un inicio de sesión administrativo cuando Immich está ocupado.

Si solo falla una prueba de estrés artificial mientras todas las cargas de trabajo domésticas definidas funcionan, documenta el límite aceptado en lugar de comprar RAM para un escenario que no necesitas.

Si una carga de trabajo real no puede completarse sin agotar el host, reduce la concurrencia, aísla el aprendizaje automático, añade memoria o traslada los servicios que compiten por recursos; después repite la misma validación antes de declarar seguro el nuevo límite.