Quelle limite de mémoire devez-vous définir pour Jellyfin ?
Ne choisissez pas une limite de mémoire universelle pour Jellyfin : commencez par mesurer la charge de travail, réservez de la mémoire pour l’hôte et les conteneurs voisins, et n’imposez une limite stricte qu’après avoir observé les pics réels.
Votre conteneur augmente-t-il jusqu’à ce que l’hôte commence à utiliser le swap, ou une limite trop basse provoque-t-elle des arrêts OOM répétés ? Mesurez l’utilisation au repos, les analyses de bibliothèque, le traitement des métadonnées, le nombre de transcodages simultanés et la mémoire disponible pour Docker ou la machine virtuelle avant de modifier la limite. Une limite n’est sûre que si la charge de travail initiale s’achève toujours et que l’hôte conserve une marge suffisante pour récupérer.
Distinguez la croissance normale du cache de la pression exercée sur la mémoire résidente
Commencez par comparer le RSS du conteneur, le cache, le swap et la mémoire libre de l’hôte au repos et pendant la tâche répétable la plus exigeante. Le cache du système de fichiers peut sembler volumineux sans signaler une fuite, tandis qu’une augmentation de la mémoire résidente accompagnée d’événements OOM indique une véritable contrainte.
Un déploiement Docker Jellyfin basique démarre généralement autour de quelques gigaoctets et nécessite davantage de mémoire pour le transcodage, mais la valeur correcte dépend de la charge de travail (base de référence de la mémoire selon la charge de travail).
Si le RSS reste stable tandis que le cache augmente et que l’hôte dispose de mémoire récupérable, surveillez plutôt que de réduire la limite. Si le RSS augmente avec le swap ou des messages d’arrêt OOM, poursuivez avec les tests de transcodage et de bibliothèque.
Testez la limite dans les conditions qui provoquent l’échec
Effectuez une analyse de bibliothèque, un transcodage représentatif et un nombre de flux simultanés conforme aux attentes, tout en enregistrant l’utilisation de la mémoire du cgroup, les événements mémoire, le swap et la pression exercée sur l’hôte. Ne modifiez que la limite de mémoire entre les différentes exécutions.
Une limite qui permet une lecture au repos mais échoue pendant l’affichage des sous-titres, la conversion HDR ou l’indexation n’est pas adaptée à la production. Notez le déclencheur responsable de l’échec afin de ne pas augmenter la limite pour résoudre un problème sans rapport.
Si le conteneur est arrêté, augmentez la limite uniquement après avoir réduit le cache de transcodage inutile ou séparé les tâches lourdes. Si l’hôte lui-même utilise le swap, réduisez la simultanéité ou déplacez un rôle ; attribuer à Jellyfin toute la RAM restante ne fait que déplacer la panne vers un autre service.
Définissez une limite d’arrêt et vérifiez sa persistance
Conservez une alerte souple en dessous de la limite stricte et laissez suffisamment de mémoire pour l’hôte, les services de stockage et un redémarrage propre. Une limite stricte doit protéger l’hôte, et non dissimuler un processus sans borne ou une machine sous-dimensionnée.
Après avoir modifié la limite, arrêtez et recréez le conteneur une fois, puis répétez l’analyse et le scénario de lecture initiaux. Vérifiez que la limite configurée est toujours active après la recréation et que la base de données reste accessible en écriture.
Arrêtez les réglages et demandez une analyse approfondie lorsque les événements OOM persistent avec une limite qui ne laisse aucune marge à l’hôte, que la base de données devient corrompue ou que le processus augmente sans charge de travail reproductible. Conservez les journaux et la dernière configuration connue comme fonctionnelle avant d’effectuer une modification plus importante.
Revérifiez le pic de lecture après un redémarrage à froid
Redémarrez l’hôte, attendez le montage du stockage et le démarrage des conteneurs voisins, puis reproduisez le même mélange de flux multi-utilisateurs qui avait initialement révélé la limite. Ne validez pas uniquement avec un tableau de bord au repos ou une seule session Direct Play.
La récupération est confirmée lorsque la lecture reste stable, qu’aucune saturation du swap n’apparaît, que le conteneur reste sous sa limite et qu’une nouvelle sauvegarde ou un redémarrage s’achève sans erreur liée à la mémoire. Comparez le résultat avec la référence enregistrée avant les réglages.
Conservez le réglage lorsque la charge de pointe passe avec une marge mesurable pour l’hôte. S’il échoue uniquement après le démarrage d’un autre conteneur, répartissez le budget de ressources ou reprogrammez la tâche concurrente au lieu d’augmenter à nouveau la limite de Jellyfin.
Produits recommandés
Assistance et conseils
Plus à lire
Comment optimiser les connexions à la base de données de Jellyfin pour des conteneurs simultanés
Commencez avec un seul propriétaire de base de données et mesurez le comportement des verrous SQLite ; n’ajoutez un autre backend que lorsque la...
Comment éviter les tâches ou importations en double dans Jellyfin
Le travail en double provient généralement de planificateurs qui se chevauchent ou de plusieurs rédacteurs ; désignez un responsable, un chemin et une vérification...
Comment réparer Jellyfin après le remplissage de son volume de base de données
Arrêtez les écritures, préservez la base de données et les fichiers WAL, libérez de l’espace sans supprimer aveuglément l’état, puis vérifiez l’intégrité et la...
