Pourquoi Jellyfin consomme-t-il beaucoup de CPU après une mise à jour ?

Une utilisation élevée du CPU par Jellyfin après une mise à jour provient généralement de l’une de quatre sources : les opérations de démarrage ou de base de données, les tâches planifiées de la bibliothèque, le transcodage logiciel ou partiel, ou encore un plugin ou une tâche en arrière-plan dont le comportement a changé avec la nouvelle version. Ne partez pas du principe que la mise à jour a rendu Jellyfin durablement plus gourmand avant d’avoir identifié le processus et la tâche qui consomment le CPU.

Le diagnostic le plus rapide consiste à comparer le moment où le problème survient et la charge de travail. Si le CPU est élevé uniquement pendant quelques minutes après le démarrage, surveillez les journaux de démarrage et des tâches. S’il augmente seulement pendant la lecture, examinez le flux actif et le chemin FFmpeg. S’il reste élevé alors que personne ne regarde de contenu, vérifiez les tâches planifiées et les plugins. Ne modifiez qu’une variable à la fois, puis reproduisez les mêmes conditions afin de distinguer une tâche temporaire suivant la mise à jour d’une régression persistante.

Distinguer les opérations de démarrage de l’utilisation normale du CPU

Redémarrez Jellyfin une fois pendant une période calme et mesurez le temps pendant lequel le CPU reste fortement sollicité. Consultez le journal du serveur pour repérer les migrations, l’optimisation de la base de données, le chargement des plugins ou les messages liés à la bibliothèque, puis attendez que l’interface web et les tâches planifiées soient stabilisées avant d’évaluer la nouvelle valeur de référence.

Les tâches planifiées et de démarrage par défaut de Jellyfin incluent l’analyse des bibliothèques, l’extraction des images clés, l’optimisation de la base de données, le nettoyage du cache et les mises à jour des plugins. Certaines tâches s’exécutent également au démarrage ; un pic suivant une mise à jour peut donc correspondre à de la maintenance plutôt qu’à une modification continue des performances.

Si l’utilisation du CPU revient à l’ancienne plage au repos une fois les tâches terminées, ne modifiez pas les paramètres de transcodage et ne remplacez pas le matériel. Votre installation a déjà convergé vers une activité temporaire en arrière-plan ; planifiez plutôt les tâches lourdes en dehors des heures de visionnage si elles perturbent la lecture.

Vérifier si la lecture utilise désormais le CPU

Si le pic du CPU commence uniquement lorsqu’un client donné lance une lecture, ouvrez le tableau de bord Jellyfin et déterminez si la session est en lecture directe, en remultiplexage, en transcodage audio ou en transcodage vidéo. Un changement de client ou de codec peut activer un traitement logiciel qui n’était pas utilisé auparavant.

Lancez le même contenu sur le même client avec les sous-titres désactivés, puis comparez l’utilisation du CPU. Si elle chute fortement, les sous-titres ou le chemin de transcodage sont le facteur déterminant. Si elle reste élevée en lecture directe, examinez le stockage, les plugins ou un autre processus au lieu d’accuser l’encodeur.

Pour approfondir le diagnostic de lecture, utilisez la même méthode que celle décrite dans la vérification du transcodage matériel : vérifiez le GPU actif et le chemin FFmpeg au lieu de vous contenter de constater que l’accélération matérielle est activée dans les paramètres.

Mesurer le processus du conteneur plutôt que de se fier à la charge de l’hôte

Sur un serveur domestique partagé, vérifiez que Jellyfin est bien le processus qui consomme le CPU. Des sauvegardes, des indexeurs multimédias, des clients de téléchargement, des générateurs de miniatures ou des tâches de maintenance du système de fichiers ont pu être déclenchés au même moment que le redémarrage ou la mise à jour.

Les moteurs de conteneurs fournissent des vues de l’utilisation par conteneur ; la commande stats de Docker est conçue pour afficher l’utilisation en direct des ressources des conteneurs en cours d’exécution. Utilisez la vue de l’utilisation des ressources par conteneur ou son équivalent sur votre plateforme pendant la reproduction du problème.

Si un autre conteneur monopolise le CPU, mettez cette tâche en pause et relancez le test initial. Si Jellyfin en est responsable, poursuivez l’analyse des tâches et de la lecture dans Jellyfin ; dans le cas contraire, la mise à jour n’a fait que coïncider avec la charge de l’hôte, sans en être la cause.

Featured

ZimaCube 2 NAS personnel Cloud à domicile

ZimaCube2

$799.00 - $2,499.00

Buy Now

Désactiver ou reprogrammer une seule source d’activité en arrière-plan à la fois

Consultez la page des tâches planifiées de Jellyfin pour repérer une tâche actuellement en cours d’exécution ou qui redémarre continuellement. Examinez également les plugins qui ajoutent leurs propres tâches planifiées, des fournisseurs de métadonnées, la détection des intros, le traitement des sous-titres ou d’autres automatisations de bibliothèque.

Ne désactivez pas définitivement tous les plugins et toutes les tâches en une seule étape. Mettez en pause un candidat fortement consommateur de ressources, laissez le CPU se stabiliser, puis reproduisez les mêmes conditions au repos ou pendant l’analyse. Une baisse nette identifie la source ; l’absence de changement signifie qu’il faut la réactiver et tester le candidat suivant.

Si la tâche est légitime mais mal planifiée, reprogrammez-la au lieu de la considérer comme un défaut. Si elle boucle, échoue ou redémarre immédiatement après la mise à jour, conservez les journaux ainsi que les informations sur le plugin et sa version avant de modifier les fichiers de base de données ou de reconstruire le serveur.

Confirmer la correction dans les mêmes conditions de charge qu’après la mise à jour

Après avoir identifié la cause, appliquez la correction adaptée : laissez les migrations se terminer, reprogrammez une tâche, rétablissez l’accélération matérielle, mettez à jour ou désactivez un plugin problématique, ou corrigez les conditions liées au client ou au transcodage. Redémarrez ensuite une fois le serveur et répétez exactement le test qui faisait auparavant grimper le CPU.

La correction est réussie si le comportement du CPU correspond à nouveau à la charge de travail : l’utilisation au repos se stabilise après le démarrage, une lecture directe reste peu gourmande et tout transcodage nécessaire utilise le chemin d’accélération attendu. Une seule minute au calme sans reproduire le déclencheur ne suffit pas.

Demandez une analyse approfondie lorsque l’utilisation du CPU reste élevée en l’absence de tâches en cours, de transcodage, de conteneur concurrent et après avoir rétabli une configuration propre des plugins. À ce stade, recueillez la version de Jellyfin, le système d’exploitation et l’architecture, l’état des tâches ainsi qu’une courte période de journaux afin d’étudier une éventuelle régression propre à la version sans tirer de conclusion générale à partir d’un simple démarrage chargé.