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

No elijas un límite de memoria universal para Jellyfin; empieza con una carga de trabajo medida, reserva memoria para el host y los contenedores vecinos, y aplica un límite estricto solo después de observar los picos reales.

¿Tu contenedor crece hasta que el host empieza a usar la memoria de intercambio, o un límite bajo provoca repetidos cierres por falta de memoria (OOM)? Mide el uso en reposo, los escaneos de la biblioteca, el procesamiento de metadatos, las transcodificaciones simultáneas y la memoria disponible para Docker o la máquina virtual antes de cambiar el límite. Un límite es seguro solo cuando la carga de trabajo original sigue completándose y el host conserva margen de recuperación.

Separa el crecimiento normal de la caché de la presión sobre la memoria residente

Primero compara la memoria RSS del contenedor, la caché, la memoria de intercambio y la memoria libre del host durante el reposo y durante el trabajo repetible más exigente. La caché del sistema de archivos puede parecer grande sin que exista una fuga, mientras que el crecimiento de la memoria residente junto con eventos OOM indica una limitación real.

Una implementación básica de Jellyfin en Docker suele comenzar con unos pocos gigabytes y necesita más memoria para transcodificar, pero el valor correcto depende de la carga de trabajo (referencia de memoria basada en la carga de trabajo).

Si la memoria RSS permanece estable mientras aumenta la caché y el host dispone de memoria recuperable, supervisa en lugar de reducir el límite. Si la memoria RSS aumenta junto con el uso de intercambio o los mensajes de cierre por OOM, continúa con las pruebas de transcodificación y de la biblioteca.

Prueba el límite con el desencadenante que provoca el fallo

Ejecuta un escaneo de la biblioteca, una transcodificación representativa y la cantidad esperada de transmisiones simultáneas mientras registras el uso de memoria del cgroup, los eventos de memoria, el uso de intercambio y la presión del host. Cambia únicamente el límite de memoria entre las pruebas.

Un límite que permite la reproducción en reposo pero falla durante los subtítulos, la conversión HDR o la indexación no es una configuración de producción válida. Registra qué desencadenante causó el fallo para no aumentar el límite por un cuello de botella no relacionado.

Si el contenedor se cierra, aumenta el límite solo después de reducir la caché de transcodificación innecesaria o separar los trabajos pesados. Si el propio host empieza a usar la memoria de intercambio, reduce la concurrencia o traslada una función; asignar a Jellyfin toda la RAM restante simplemente trasladará el fallo a otro servicio.

Establece un límite de detención y verifica su persistencia

Mantén una alerta preventiva por debajo del límite estricto y deja suficiente memoria para el host, los servicios de almacenamiento y un reinicio limpio. Un límite estricto debe proteger al host, no ocultar un proceso sin límites o una máquina con recursos insuficientes.

Después de cambiar el límite, detén y vuelve a crear el contenedor una vez, y repite el escaneo y la reproducción originales que desencadenaron el problema. Comprueba que el límite configurado siga activo después de volver a crear el contenedor y que la base de datos siga permitiendo escrituras.

Deja de ajustar el límite y escala el problema cuando continúen los eventos OOM con un límite que no deja margen para el host, la base de datos se corrompa o el proceso crezca sin una carga de trabajo reproducible. Conserva los registros y la última configuración conocida como funcional antes de realizar un cambio mayor.

Featured

ZimaCube 2 NAS personal en la nube para el hogar

ZimaCube2

$799.00 - $2,499.00

Buy Now

Vuelve a comprobar el pico de reproducción después de un reinicio en frío

Reinicia el host, espera a que se monten los volúmenes de almacenamiento y se inicien los contenedores vecinos, y reproduce la misma combinación de transmisiones multiusuario que expuso originalmente el límite. No lo valides únicamente con un panel en reposo o una sola sesión de reproducción directa.

La recuperación queda demostrada cuando la reproducción permanece estable, no aparece una avalancha de uso de intercambio, el contenedor se mantiene por debajo de su límite y una copia de seguridad nueva o un reinicio se completa sin errores relacionados con la memoria. Compara el resultado con la referencia registrada antes del ajuste.

Mantén la configuración cuando la carga máxima se complete con un margen medible para el host. Si falla solo después de que se inicie otro contenedor, divide el presupuesto de recursos o reprograma el trabajo que compite por ellos en lugar de volver a aumentar el límite de Jellyfin.