Vous pouvez identifier le goulot d’étranglement de Jellyfin en répétant une même charge de travail et en reliant le symptôme visible par l’utilisateur à la ressource qui arrive à saturation avec des erreurs ou une mise en file d’attente.
Un graphique CPU élevé ne prouve pas que le CPU est la limite, tout comme une activité élevée du stockage ne prouve pas que celui-ci est en cause. Réutilisez le même fichier, le même client, la même qualité et le même nombre de sessions, en ne changeant qu’une condition à la fois. Cela permet de distinguer une véritable limite de dépendance d’un chemin de lecture plus exigeant sélectionné par le client.
Gardez le scénario de lecture constant
Choisissez un fichier multimédia, un client, une politique de qualité et un niveau de concurrence. Notez si la session utilise la lecture directe, le remuxage ou le transcodage avant de consulter les graphiques de ressources, car le mode de lecture détermine les ressources qui devraient être sollicitées.
Commencez par le passage de la lecture directe au transcodage afin de connaître le chemin utilisé par le serveur avant de comparer le comportement des ressources.
Une base de référence contrôlée vous évite de comparer un transcodage dans un navigateur à une session de lecture directe native et d’attribuer la différence à un goulot d’étranglement matériel.
Le CPU et la mémoire laissent des signatures différentes
Les tâches limitées par le CPU suivent généralement le décodage logiciel, les filtres, la composition des sous-titres ou l’encodage, tandis que la pression mémoire se manifeste par la récupération de mémoire, le swap, des processus bloqués ou une activité croissante du stockage due à la pagination. Les symptômes peuvent se chevaucher, mais leurs compteurs sont différents.
Utilisez la méthode d’utilisation et de saturation pour examiner ensemble l’utilisation, la saturation et les erreurs, plutôt que de vous fonder sur la moyenne du CPU ou de la RAM.
Si la désactivation d’un filtre ou le passage au décodage matériel rétablit une vitesse en temps réel sans modifier le stockage ni le réseau, le CPU est probablement en cause. Si la récupération de mémoire ou le swap disparaît lorsqu’un autre conteneur est arrêté, la pression mémoire constitue l’explication la plus probable.
Le réseau et le stockage nécessitent des tests spécifiques au chemin utilisé
Un débit montant saturé peut provoquer la mise en mémoire tampon d’une lecture distante alors que le CPU de l’hôte reste peu sollicité. La latence du stockage peut retarder le démarrage, les recherches, les métadonnées et l’espace de travail du transcodage, même si le débit séquentiel semble suffisant. Testez le chemin réellement utilisé par le client.
Mesurez séparément la latence et le débit du stockage, puis comparez le même flux lorsque les transferts concurrents sont interrompus.
Si le symptôme suit la profondeur de file d’attente ou l’utilisation du débit montant, modifier le CPU ou la RAM ne le fera pas disparaître. Si le symptôme persiste une fois le chemin au repos, examinez la compatibilité du client ou la puissance de calcul.
Utilisez une matrice de décision à quatre ressources
Pour chaque test, notez le symptôme observable, le premier compteur qui arrive à saturation, l’augmentation éventuelle des erreurs et le fait que la suppression de la pression sur cette ressource rétablisse ou non la base de référence. Un seul signal positif ne suffit pas : la relation doit se répéter.
Un benchmark à froid et à chaud concis permet de fonder la décision sur des preuves plutôt que sur l’envie de faire une mise à niveau.
Arrêtez-vous dès qu’une ressource explique le symptôme lors de plusieurs tests répétés. Si aucune ressource ne le suit, le problème actif peut venir de l’interface du client, de l’ordre de démarrage ou d’un changement de mode de lecture qui sort du cadre du test à quatre ressources.
Centre Tech & IA
Plus à lire

Pourquoi Home Assistant fonctionne-t-il différemment sur le réseau local et à distance ?
Les sessions Home Assistant en réseau local et à distance utilisent des chemins réseau différents ; la latence à distance ajoute le DNS, le...

Home Assistant fonctionne-t-il de manière fiable derrière un CGNAT ou un double NAT ?
Le CGNAT et le double NAT n’affectent généralement pas le contrôle local de Home Assistant ; ils modifient principalement la façon dont les clients...

Comment la latence du réseau affecte-t-elle Home Assistant pendant les pannes d’Internet ?
La perte de connexion Internet et la latence du réseau sont deux problèmes distincts : les chemins locaux entre les appareils peuvent rester rapides...

