Jusqu’à quelle taille une bibliothèque Jellyfin peut-elle atteindre sur un seul hôte ?

Il n’existe pas de seuil universel utile du nombre d’éléments Jellyfin indiquant à quel moment un seul hôte est « plein ». La limite pratique est atteinte lorsque votre base de données, votre mémoire, votre stockage, vos tâches planifiées ou vos lectures simultanées ne peuvent plus respecter votre objectif de temps de réponse.

Deux bibliothèques contenant le même nombre de films peuvent solliciter un serveur de manière très différente, car la densité des métadonnées, les images de chapitres, les données trickplay, le stockage réseau, le type de clients et les besoins en transcodage varient. Mesurez l’hôte avec votre charge réelle et définissez une limite que vous pourrez vérifier après chaque extension importante de la bibliothèque.

Commencez par l’empreinte de la base de données, pas par le nombre de fichiers multimédias

Jellyfin stocke l’état de la bibliothèque dans sa base de données, tandis que les fichiers multimédias restent dans le système de fichiers. À mesure que le catalogue s’agrandit, le premier indicateur utile est donc la taille et le comportement de l’ensemble de données Jellyfin, plutôt que le nombre total de téraoctets occupés par les films.

La documentation de stockage de Jellyfin indique que la base de données d’une bibliothèque de taille moyenne peut atteindre environ 10 à 100 Go et recommande de la conserver sur un stockage local plutôt que sur un partage réseau. conseils sur le stockage de la base de données

Notez la taille de la base de données, l’espace libre sur le volume de données et le temps nécessaire pour ouvrir les grandes vues de bibliothèque ou effectuer une recherche une fois le cache réchauffé. Si ces valeurs restent stables tandis que la capacité multimédia augmente, la taille brute des médias n’a pas, à elle seule, dépassé la limite d’un hôte unique.

Mesurez la marge mémoire une fois la base de données réchauffée

Le comportement de la mémoire est plus important dans les versions récentes de Jellyfin, car le serveur peut conserver une grande quantité de données de la base en mémoire afin de réduire les lectures sur disque. Un hôte qui semblait disposer d’une marge confortable avec un catalogue plus petit peut donc afficher une utilisation stable de la RAM plus élevée après l’agrandissement de la bibliothèque.

Les notes de version de Jellyfin 10.11 expliquent que le moteur de base de données met agressivement en cache les métadonnées en mémoire et peut utiliser jusqu’à la taille de la base de données de la bibliothèque, en libérant de la mémoire lorsque d’autres processus en ont besoin. mise en cache de la base de données en mémoire

Surveillez la mémoire disponible et l’activité du swap après une navigation normale ayant réchauffé le cache. Le signal d’alerte n’est pas l’utilisation élevée du cache en elle-même, mais une pression mémoire persistante, l’utilisation du swap ou une latence qui apparaît lorsque Jellyfin est en concurrence avec d’autres conteneurs et disparaît lorsque cette concurrence est supprimée.

Chronométrez les tâches en arrière-plan qui augmentent avec la bibliothèque

Les analyses de bibliothèque, l’actualisation des métadonnées, l’extraction d’images, le traitement des sous-titres et les autres tâches planifiées peuvent devenir la première limite de montée en charge, même lorsque la lecture reste fluide. Mesurez la durée de ces tâches et vérifiez si elles empiètent sur les heures où les utilisateurs se servent réellement du serveur.

L’extraction des images de chapitres est un exemple de coût qui évolue directement avec la taille de la bibliothèque : Jellyfin indique que son activation pendant une analyse peut ralentir considérablement celle-ci, en particulier pour les grandes bibliothèques. coût de l’analyse des images de chapitres

Si une analyse complète occupe désormais la majeure partie de la fenêtre de maintenance, commencez par réduire les tâches inutiles ou déplacez les opérations coûteuses en dehors des heures de pointe. Une analyse plus longue ne signifie pas automatiquement que l’hôte est sous-dimensionné ; elle devient un problème de capacité lorsque la maintenance entre régulièrement en conflit avec l’utilisation interactive ou ne se termine jamais de manière fiable.

-15% OFF

ZimaBoard 2 - Mini serveur domestique pour votre grande idée

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

Distinguez la capacité de la bibliothèque de celle du transcodage

Un catalogue immense ne rend pas nécessairement coûteux un flux en lecture directe, tandis qu’un petit catalogue peut surcharger un processeur lorsque plusieurs clients incompatibles demandent un transcodage vidéo. Traitez la capacité du catalogue et celle de la conversion pendant la lecture comme deux tests distincts.

Effectuez un test de lecture reproductible avec le type de clients que vous utilisez réellement : un flux en lecture directe, un transcodage courant, puis votre pic attendu de lectures simultanées. Si le catalogue s’agrandit mais que ces tests de lecture restent inchangés, vous n’avez pas atteint une limite de transcodage due à la taille de la bibliothèque.

Lorsque la saturation du processeur apparaît uniquement pendant le transcodage, optimisez les codecs, l’accélération matérielle ou la compatibilité des clients avant d’incriminer la base de données. Le guide de l’accélération matérielle constitue une étape suivante plus pertinente que le déplacement d’une base de métadonnées fonctionnelle vers un deuxième serveur.

Vérifiez la latence du stockage et la disponibilité des médias pendant les analyses

Les grandes bibliothèques s’étendent souvent sur plusieurs disques ou un NAS ; le chemin d’accès aux médias peut donc devenir la couche limitante. Comparez la navigation interactive et la lecture avec et sans analyse de bibliothèque en cours, et surveillez la file d’attente du disque ou la latence du partage réseau sur le chemin des médias.

Jellyfin recommande de monter les stockages Samba ou NFS directement dans le système d’exploitation et avertit que la maintenance planifiée peut supprimer des éléments de la bibliothèque si le stockage est indisponible lorsqu’une tâche s’exécute. stockage réseau et précautions de maintenance

Si la base de données est rapide mais que les répertoires multimédias disparaissent par intermittence ou que les analyses de métadonnées sont bloquées par un partage lent, ajouter du processeur ne résoudra pas le véritable goulot d’étranglement. Corrigez d’abord la fiabilité du montage, la latence du stockage ou le calendrier des tâches, puis répétez le même test.

Définissez votre propre limite sur un hôte unique avec un test reproductible

Créez une petite fiche de suivi avant la prochaine extension de la bibliothèque : latence de recherche une fois le cache réchauffé, temps d’ouverture d’une grande collection, durée d’une analyse complète, taille de la base de données, RAM disponible, latence maximale du stockage et test représentatif de lecture simultanée. Utilisez les mêmes mesures à chaque fois.

Un flux de travail de centre multimédia domestique sépare déjà le stockage des médias de la couche applicative Jellyfin ; conservez cette séparation dans votre test afin de déterminer si un ralentissement vient de l’hôte, du chemin de stockage ou des clients.

Considérez que l’hôte unique a atteint ses limites uniquement lorsqu’un objectif mesuré échoue de manière répétée malgré des optimisations peu risquées : les requêtes interactives restent lentes, les analyses ne peuvent pas se terminer dans la fenêtre de maintenance, la pression mémoire provoque l’utilisation du swap, la latence du stockage ne peut pas être isolée ou les transcodages nécessaires dépassent la capacité de calcul disponible. À ce stade, les données vous indiquent quelle ressource augmenter, plutôt que d’imposer un seuil arbitraire de nombre d’éléments.