Comment déterminer si Plex est limité par le processeur, la mémoire vive, le stockage ou le réseau

Pour déterminer ce qui limite Plex, reproduisez une charge connue et cherchez la ressource dont la pression augmente au moment où le flux ralentit. Ne mettez pas à niveau en premier le composant qui semble le plus sollicité ; une utilisation élevée n’est pertinente que si elle coïncide avec l’échec de la lecture.

Commencez avec un fichier, un client, un mode de lecture et une période donnés. Séparez ensuite le travail de conversion de Plex des indicateurs du système d’exploitation concernant le processeur, la mémoire, le stockage et le réseau. Le test n’est terminé que lorsque la modification d’une ressource suspectée change le symptôme Plex initial, tandis que les autres conditions restent stables.

Reproduisez une seule charge Plex avant de consulter les métriques système

Choisissez un fichier et un client qui reproduisent le problème de manière fiable. Notez s’il s’agit d’un démarrage lent, de mises en mémoire tampon répétées, d’un transcodage qui prend du retard, d’une analyse qui ralentit la lecture ou d’un échec limité aux accès distants, car chaque symptôme correspond à un chemin d’attente différent.

Un dépannage spécifique à Plex doit commencer par la session active plutôt que par un graphique générique du processeur. Une vérification axée sur le tableau de bord permet de distinguer les branches Lecture directe, transcodage, réseau et stockage avant de modifier le serveur.

Ne modifiez pas le fichier, les pistes sélectionnées, la qualité du client ni la charge simultanée pendant la collecte des métriques système. Si le symptôme varie d’un test à l’autre, simplifiez la charge jusqu’à ce que la même panne se reproduise ; sinon, un pic ultérieur du processeur ou du disque pourrait provenir d’une autre tâche.

Utilisez la session Plex pour distinguer la diffusion de la conversion

Consultez la session Plex pendant le problème. La lecture directe signifie que le serveur se contente principalement de diffuser le média stocké, tandis qu’un transcodage vidéo ajoute un processus de conversion en temps réel susceptible de déplacer le goulot d’étranglement vers le processeur ou les moteurs vidéo matériels.

Utilisez ce mode comme une branche de diagnostic, et non comme une conclusion. Un transcodage qui prend du retard fait du calcul un candidat sérieux, mais une lecture directe qui utilise la mémoire tampon laisse le stockage et le réseau parmi les causes possibles. Si le même fichier change de mode lorsque les sous-titres, l’audio ou la qualité sont modifiés, reproduisez de nouveau le problème avec la requête d’origine avant de comparer les métriques de l’hôte.

À la fin de cette étape, vous devez disposer d’un mode de lecture fixe associé au symptôme. Si vous ne pouvez pas préciser si le test défaillant concerne la lecture directe ou le transcodage, arrêtez-vous ici ; comparer les données relatives à la mémoire vive, au disque et au réseau avant de stabiliser le chemin multimédia rend les métriques restantes plus difficiles à interpréter.

Testez la pression exercée sur le processeur et la mémoire vive

Surveillez l’utilisation du processeur, la file d’exécution ou la charge, la mémoire disponible et l’activité du swap pendant le test Plex fixé. La pression sur le processeur est particulièrement révélatrice lorsque le processus Plex ou son transcodeur consomme durablement des ressources de calcul tandis que la sortie prend du retard ; la pression sur la mémoire est plus probable lorsque le système commence à récupérer de la mémoire ou à utiliser le swap et que le temps de réponse se dégrade, même si le processeur n’est pas l’unique ressource sollicitée.

Un processus général d’analyse des performances Linux utilise des outils tels que top, vmstat, iostat et sar pour distinguer les pressions exercées sur les ressources. En particulier, le processeur, la mémoire, le disque et le réseau nécessitent des indicateurs de saturation différents, plutôt qu’un seul chiffre d’utilisation globale.

Si le processeur reste proche de sa limite uniquement pendant le transcodage défaillant et que le flux reprend normalement lorsque la conversion est supprimée ou accélérée, considérez le calcul comme le principal goulot d’étranglement. Si l’utilisation du swap ou la récupération de mémoire augmente à la place, réduisez le nombre de tâches d’arrière-plan gourmandes en mémoire ou ajoutez de la mémoire, puis répétez la même charge Plex avant de modifier les paramètres de stockage ou du réseau.

-15% OFF

ZimaBoard 2 - Mini serveur domestique pour votre grande idée

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

Testez le stockage avec le même chemin multimédia

Pour le stockage, lisez le même média depuis le même système de fichiers pendant la reproduction du symptôme et surveillez la latence du périphérique, la mise en file d’attente et l’attente d’E/S. La capacité et les performances sont deux choses distinctes : un disque peut disposer d’espace libre tout en répondant lentement parce qu’une autre tâche génère des E/S aléatoires ou parce que le chemin multimédia passe par un pool occupé ou un montage réseau.

Les outils Linux tels qu’iostat et iotop sont utiles, car l’attente d’E/S du disque et le débit du périphérique révèlent un mode de défaillance différent d’une utilisation élevée du processeur ou de l’activité du swap. Comparez ces chiffres avec l’intervalle exact où la mise en mémoire tampon se produit, et non avec une moyenne mesurée au repos.

Si le fichier est lu sans problème alors que Plex utilise la mémoire tampon, le stockage devient moins probable. Si la latence et la mise en file d’attente augmentent en même temps que le symptôme, mettez en pause la tâche concurrente qui sollicite le disque ou déplacez le fichier de test vers un chemin local connu pour être rapide ; si Plex reprend immédiatement dans le même mode de lecture, le stockage est passé du statut de simple suspicion à celui de preuve.

Testez le débit du réseau sur le chemin réellement utilisé

Testez séparément le chemin entre le serveur et le client, sans passer par Plex. Un client local connecté en filaire peut distinguer un problème d’itinéraire distant d’un problème global de ressources du serveur, tandis qu’un test de débit de bout en bout peut montrer si le chemin peut maintenir le débit multimédia sans dépendre de l’application Plex.

Utilisez un outil tel qu’iperf3 lorsque vous contrôlez les deux extrémités. Un test réseau doit examiner le débit, la perte de paquets et la latence, car la vitesse théorique de la liaison ne prouve pas que l’itinéraire réellement utilisé assure un trafic applicatif stable.

Si le test réseau indépendant s’effondre alors que le processeur, la mémoire et le stockage restent sains, corrigez le chemin avant d’optimiser le transcodeur. Si le réseau dispose d’une marge durable confortable et que le symptôme Plex persiste lors d’un test local filaire, revenez à la branche des ressources du serveur plutôt que d’acheter un routeur plus rapide.

Ne modifiez que la ressource qui a échoué au test

Choisissez la première ressource qui a échoué à un test discriminant et effectuez une seule modification censée agir uniquement sur cette branche. Vous pouvez par exemple activer un transcodage matériel vérifié pour un flux limité par le calcul, réduire une tâche d’arrière-plan gourmande en mémoire, reprogrammer une tâche intensive pour le disque ou contourner un maillon réseau défaillant.

Pour approfondir le dépannage spécifique à Plex, le parcours de diagnostic des mises en mémoire tampon de ZimaSpace propose une suite plus détaillée une fois que vous savez si la branche à modifier concerne le mode de lecture, la charge de conversion, la stabilité du réseau ou la réactivité du stockage.

Répétez le test avec le fichier, le client et le mode de lecture d’origine après la modification. Ne désignez un composant comme goulot d’étranglement que lorsque le symptôme initial s’améliore et que le signal de pression correspondant diminue ou dispose de davantage de marge. Si le symptôme ne change pas, rétablissez la configuration de référence et testez la branche suivante au lieu d’empiler les mises à niveau jusqu’à faire disparaître la véritable cause par accident.