¿Hasta qué tamaño puede crecer una biblioteca de Jellyfin en un solo host?

No existe un límite universal útil de cantidad de elementos de Jellyfin que indique cuándo un host está «lleno». El límite práctico aparece cuando la base de datos, la memoria, el almacenamiento, las tareas programadas o la reproducción simultánea ya no pueden cumplir tu objetivo de tiempo de respuesta.

Dos bibliotecas con la misma cantidad de películas pueden exigir cargas muy distintas a un servidor, porque difieren en densidad de metadatos, imágenes de capítulos, datos de reproducción rápida, almacenamiento en red, combinación de clientes y demanda de transcodificación. Mide el host con tu carga de trabajo real y define un límite que puedas volver a comprobar después de cada ampliación importante de la biblioteca.

Empieza por el tamaño de la base de datos, no por la cantidad de archivos multimedia

Jellyfin almacena el estado de la biblioteca en su base de datos, mientras que los archivos multimedia permanecen en el sistema de archivos. A medida que crece el catálogo, la primera métrica útil es el tamaño y el comportamiento del conjunto de datos de Jellyfin, no los terabytes totales de archivos de películas.

La documentación de almacenamiento de Jellyfin señala que la base de datos de una biblioteca de tamaño moderado puede alcanzar aproximadamente entre 10 y 100 GB, y recomienda mantenerla en almacenamiento local en lugar de un recurso compartido de red. guía sobre el almacenamiento de la base de datos

Registra el tamaño de la base de datos, el espacio libre del volumen de datos y el tiempo necesario para abrir vistas de bibliotecas grandes o realizar búsquedas una vez que la caché esté activa. Si estos valores se mantienen estables mientras aumenta la capacidad multimedia, el tamaño bruto de los archivos multimedia por sí solo no ha llevado la aplicación más allá del límite de un único host.

Mide la memoria disponible después de que la base de datos se haya cargado en la caché

El comportamiento de la memoria es más importante en las versiones actuales de Jellyfin porque el servidor puede mantener una gran cantidad de datos de la base de datos en memoria para reducir las lecturas del disco. Por eso, un host que parecía funcionar cómodamente con un catálogo más pequeño puede mostrar un mayor uso estable de RAM después de que la biblioteca crezca.

Las notas de la versión 10.11 de Jellyfin explican que el motor de base de datos almacena agresivamente los metadatos en la memoria y puede utilizar memoria hasta alcanzar el tamaño de la base de datos de la biblioteca, devolviéndola cuando otros procesos la necesitan. caché de la base de datos en memoria

Observa la memoria disponible y la actividad de intercambio después de que la navegación normal haya calentado la caché. La señal de advertencia no es un uso elevado de la caché por sí solo, sino una presión de memoria sostenida, el uso de la memoria de intercambio o una latencia que aparece cuando Jellyfin compite con otros contenedores y desaparece al eliminar esa competencia.

Calcula el tiempo de las tareas en segundo plano que crecen con la biblioteca

Los análisis de la biblioteca, las actualizaciones de metadatos, la extracción de imágenes, el procesamiento de subtítulos y otras tareas programadas pueden convertirse en el primer límite de escalabilidad, incluso cuando la reproducción sigue siendo fluida. Mide cuánto tardan estas tareas y si coinciden con las horas en que realmente se utiliza el servidor.

La extracción de imágenes de capítulos es un ejemplo de un coste de escalabilidad que Jellyfin documenta directamente: activar la extracción durante un análisis de la biblioteca puede ralentizar considerablemente los análisis, especialmente en bibliotecas grandes. coste del análisis de imágenes de capítulos

Si un análisis completo ocupa ahora la mayor parte de la ventana de mantenimiento, primero reduce el trabajo innecesario o traslada las tareas costosas fuera de las horas punta. Un análisis más largo no significa automáticamente que el host sea insuficiente; se convierte en un problema de capacidad cuando el mantenimiento interfiere repetidamente con el uso interactivo o nunca finaliza de forma fiable.

-15% OFF

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

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

Separa la escala de la biblioteca de la escala de la transcodificación

Un catálogo enorme no necesariamente hace que una transmisión con reproducción directa sea costosa, mientras que un catálogo pequeño puede sobrecargar una CPU cuando varios clientes incompatibles solicitan la transcodificación de vídeo. Trata la escala del catálogo y la conversión durante la reproducción como pruebas de capacidad independientes.

Ejecuta una prueba de reproducción repetible con la combinación de clientes que realmente utilizas: una transmisión con reproducción directa, una transcodificación típica y, después, el pico simultáneo previsto. Si el catálogo crece pero estas pruebas de reproducción no cambian, no has alcanzado un límite de transcodificación debido al tamaño de la biblioteca.

Cuando la saturación de la CPU aparece solo durante la transcodificación, ajusta los códecs, la aceleración por hardware o la compatibilidad de los clientes antes de culpar a la base de datos. La guía de aceleración por hardware es un siguiente paso más pertinente que trasladar una base de datos de metadatos que funciona correctamente a un segundo servidor.

Comprueba la latencia del almacenamiento y la disponibilidad de los archivos multimedia durante los análisis

Las bibliotecas grandes suelen abarcar varios discos o un NAS, por lo que la ruta hasta los archivos multimedia puede convertirse en la capa limitante. Compara la navegación interactiva y la reproducción con un análisis de la biblioteca en ejecución y sin él, y observa las colas del disco o la latencia del recurso compartido de red en la ruta de los archivos multimedia.

Jellyfin recomienda montar el almacenamiento Samba o NFS directamente en el sistema operativo y advierte que el mantenimiento programado puede eliminar elementos de la biblioteca si el almacenamiento no está disponible cuando se ejecuta una tarea. precaución sobre el almacenamiento en red y el mantenimiento

Si la base de datos es rápida, pero los directorios multimedia desaparecen de forma intermitente o los análisis de metadatos se bloquean debido a un recurso compartido lento, añadir CPU no resolverá el verdadero cuello de botella. Corrige primero la fiabilidad del montaje, la latencia del almacenamiento o la programación de las tareas; después, repite la misma prueba.

Define tu propio límite para un único host con una prueba repetible

Crea una pequeña tabla de control antes de la próxima ampliación de la biblioteca: latencia de búsqueda con la caché activa, tiempo necesario para abrir una colección grande, duración del análisis completo, tamaño de la base de datos, RAM disponible, latencia máxima del almacenamiento y una prueba representativa de reproducción simultánea. Utiliza las mismas mediciones cada vez.

Un flujo de trabajo de centro multimedia doméstico práctico ya separa el almacenamiento multimedia de la capa de la aplicación Jellyfin; conserva esa separación en tu prueba para saber si la ralentización procede del host, de la ruta de almacenamiento o de los clientes.

Considera que un único host ha quedado pequeño solo cuando un objetivo medido falla repetidamente después de aplicar ajustes de bajo riesgo: las solicitudes interactivas siguen siendo lentas, los análisis no pueden finalizar durante la ventana de mantenimiento, la presión de memoria provoca intercambio, la latencia del almacenamiento no puede aislarse o las transcodificaciones necesarias superan la capacidad de cálculo disponible. En ese momento, las pruebas te indican qué recurso debes ampliar, en lugar de obligarte a establecer un límite arbitrario de cantidad de elementos.