Réservez suffisamment de marge CPU pour Plex afin d’absorber le chevauchement entre le transcodage normal le plus intense et les tâches d’arrière-plan, sans saturation prolongée ni instabilité de lecture.
Il n’existe pas de pourcentage universel, car la lecture directe, le transcodage logiciel, l’accélération matérielle, les sous-titres, les analyses et les conteneurs annexes sollicitent le CPU de manière différente. Élaborez un scénario de pointe reproductible et mesurez la saturation, pas seulement l’utilisation moyenne. La marge correspond à l’écart entre cette pointe testée et le niveau auquel la latence ou les erreurs commencent à apparaître.
Commencez par la charge normale la plus intense
Un benchmark synthétique utilisant tous les cœurs ne représente pas Plex si la plupart des sessions utilisent la lecture directe. Reproduisez le mélange de flux, les sous-titres, les analyses et les services annexes qui se chevauchent réellement chez vous.
Utilisez les vérifications d’utilisation et de saturation pour déterminer si le CPU est simplement très sollicité ou s’il présente une file d’attente persistante de tâches prêtes à s’exécuter pendant la pointe.
Exécutez le scénario plusieurs fois et notez les mises en mémoire tampon, la latence des tâches et la saturation du CPU. Utilisez le pire résultat normal et reproductible comme référence pour le dimensionnement.
Distinguez les transcodages matériels des transcodages logiciels
L’accélération matérielle peut transférer la conversion vidéo des cœurs CPU généraux vers un autre moteur, tandis qu’un basculement logiciel peut consommer bien davantage de CPU pour le même flux. La marge doit couvrir le chemin qui peut réellement être utilisé.
Un moteur multimédia compatible peut gérer plusieurs transcodages sans exercer une pression équivalente sur le CPU général ; les résultats de transcodage matériel sur N100 en fournissent un exemple basse consommation.
Vérifiez que le tableau de bord indique le chemin matériel prévu pour vos fichiers multimédias les plus exigeants. Si un basculement est possible, incluez au moins un test de transcodage logiciel avant de considérer la marge comme suffisante.
Incluez les tâches d’arrière-plan dans la pointe
Les analyses, l’indexation, les sauvegardes et un autre conteneur peuvent se chevaucher avec la lecture, même si chaque charge est sûre lorsqu’elle est exécutée seule. Les hôtes partagés ont besoin d’une pointe qui inclut ces chevauchements.
L’utilisation simultanée des ressources fait partie de la charge réelle lorsqu’une pile multimédia à plusieurs services place plusieurs services sur le même hôte et utilise les mêmes chemins de stockage.
Lancez la lecture la plus intense pendant qu’une tâche d’arrière-plan courante est active. Si ce chevauchement entraîne une saturation prolongée, reprogrammez la tâche ou réservez davantage de ressources de calcul. Ne traduisez la pointe mesurée en exigences matérielles pour Plex qu’après avoir déterminé si la véritable limite vient de la saturation du CPU, d’un basculement vers le transcodage matériel ou d’une autre charge partagée.
Utilisez un seuil d’échec plutôt qu’un pourcentage arbitraire
La marge utile est celle qui maintient le système en dessous du niveau auquel la latence visible par l’utilisateur ou les tâches en attente devient inacceptable. Ce seuil peut varier d’un foyer à l’autre.
Une seconde vérification de saturation après des changements de configuration confirme si le nouveau point de fonctionnement rétablit réellement une marge.
Définissez une condition de réussite, par exemple l’absence de mise en mémoire tampon, une exécution stable des tâches et l’absence de file d’attente persistante du CPU. Effectuez un nouveau test après toute modification importante de la bibliothèque, des clients ou des conteneurs, plutôt que de conserver indéfiniment un pourcentage unique.
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é...

