Comment déterminer si Jellyfin est limité par le processeur, la RAM, le stockage ou le réseau
Trouvez le goulot d’étranglement de Jellyfin en reproduisant une panne tout en mesurant simultanément le processeur, la pression mémoire, la latence du stockage et le comportement du réseau.
La mise en mémoire tampon, les démarrages lents, la navigation saccadée et les transcodages échoués peuvent sembler similaires depuis le canapé, mais provenir de ressources différentes. Le diagnostic doit garder constants le média, le client, la qualité et le mode de lecture, puis identifier la ressource dont la saturation ou les erreurs apparaissent avec le symptôme. Ne modifiez qu’une seule variable après avoir confirmé cette corrélation à plusieurs reprises.
Le processeur est suspect lorsque les tâches prêtes s’accumulent dans la file d’exécution
Un pourcentage élevé d’utilisation du processeur ne suffit pas à lui seul ; le signal le plus probant est une saturation prolongée pendant laquelle le transcodage actif ou la tâche en arrière-plan n’atteint pas son objectif de synchronisation. L’accélération matérielle peut déporter la même charge de travail hors des cœurs généraux du processeur.
La méthode USE distingue l’utilisation, la saturation et les erreurs, ce qui évite de considérer à tort un processeur très sollicité mais sain comme le goulot d’étranglement.
Comparez la file d’exécution du processeur et la vitesse de transcodage pendant la panne. Si la saturation du processeur disparaît lorsque le flux est lu en lecture directe ou que l’accélération matérielle fonctionne, le chemin de calcul est confirmé.
La mémoire vive est suspecte lorsque la pression entraîne de la récupération ou du swap
Jellyfin bénéficie du cache du système de fichiers et de la base de données, mais davantage de mémoire n’apporte rien lorsque l’ensemble de travail tient déjà en mémoire. Le mauvais scénario est une pression qui force des récupérations répétées, du swap ou l’arrêt de processus concurrents.
Les ensembles de travail mis en cache peuvent réduire les lectures du stockage jusqu’à ce qu’une autre charge de travail les évince.
Surveillez la pression mémoire, les défauts de page majeurs et le swap pendant le même scénario. Si l’ajout ou la libération de mémoire vive supprime les accès répétés au stockage, la mémoire faisait partie du problème.
Le stockage est suspect lorsque l’attente des entrées-sorties suit le symptôme
Un disque multimédia peut offrir un débit moyen suffisant tout en accumulant une file d’attente à cause de métadonnées aléatoires ou de plusieurs lectures simultanées. Le démarrage et les recherches le révèlent souvent avant la lecture séquentielle continue.
La latence du stockage par rapport au débit fournit la distinction de mesure appropriée pour déterminer si le problème vient du temps de réponse ou de la bande passante brute.
Enregistrez la latence du périphérique et la profondeur de la file d’attente pendant la reproduction du problème. Les vérifications de la mise en mémoire tampon de Jellyfin ne devraient passer au réseau qu’après avoir confirmé que le stockage local peut alimenter le serveur de manière constante.
Le réseau est suspect lorsque le serveur produit les données plus rapidement que le client ne les reçoit
Un chemin de transcodage et de stockage sain peut tout de même provoquer une mise en mémoire tampon lorsque le Wi-Fi, le débit montant distant, un port client ou une route VPN ne peut pas maintenir le débit binaire demandé. La perte de paquets et les retransmissions peuvent avoir un impact avant même que la liaison n’atteigne sa vitesse nominale.
Comparez le débit binaire du flux à celui réellement fourni par la liaison à l’aide d’un budget de bande passante pour un flux multimédia avant de considérer un serveur sain comme le goulot d’étranglement.
Testez un client local filaire et une version à débit binaire inférieur du même flux. Si le symptôme suit la route ou le débit binaire tandis que les ressources de l’hôte restent saines, maintenez la correction au niveau du réseau.
Produits recommandés
Assistance et conseils
Plus à lire
Faut-il sauvegarder Jellyfin à chaud ou arrêter le service au préalable ?
Privilégiez les sauvegardes lorsque le service est arrêté pour plus de simplicité ; n’utilisez des instantanés à chaud que lorsque l’état de l’application est...
Pourquoi Jellyfin chauffe-t-il ou est-il bruyant lorsque personne ne regarde de contenu en streaming ?
La chaleur au repos indique généralement une activité en arrière-plan ou une charge de travail d’hébergement partagé. Identifiez donc le processus actif et la...
Quand faut-il reconstruire Jellyfin plutôt que le réparer ?
Choisissez la reconstruction plutôt que la réparation lorsque la dérive de l’environnement d’exécution est à l’origine du problème et que l’état persistant est sauvegardé...
