Plex peut-il partager un GPU avec un autre conteneur Docker ?

Oui, Plex peut souvent partager un GPU avec un autre conteneur Docker, mais exposer le même périphérique aux deux conteneurs ne réserve ni ne garantit les performances de l’une ou l’autre charge de travail.

La décision dépend du GPU, du pilote Linux, du moteur d’exécution des conteneurs, du type de charge et de la façon dont chaque application utilise les moteurs vidéo, le calcul et la mémoire. Les cartes graphiques intégrées Intel sont généralement exposées via des nœuds de périphérique Linux tels que /dev/dri, tandis que les conteneurs NVIDIA utilisent le moteur d’exécution de conteneurs NVIDIA ou les réservations de GPU de Docker. Configurez d’abord l’accès, puis exécutez Plex et la seconde charge de travail simultanément et vérifiez que Plex utilise toujours le transcodage matériel dans les conditions de charge qui vous intéressent réellement.

Vérifiez d’abord que Plex peut utiliser seul le GPU

Avant de tester le partage, lancez un transcodage Plex forcé en arrêtant l’autre charge de travail GPU. Plex doit signaler l’accélération matérielle pour le flux, et l’hôte doit afficher l’activité attendue du moteur vidéo ou du GPU. Si Plex ne peut pas utiliser le périphérique seul, l’ajout d’un autre conteneur ne fera que compliquer le diagnostic.

Le guide Plex du streaming avec accélération matérielle explique que les déploiements Docker doivent exposer le périphérique du noyau concerné au conteneur pour permettre l’accélération matérielle. Utilisez la méthode actuelle pour votre plateforme au lieu de supposer qu’un GPU détecté par l’hôte est automatiquement visible dans Plex.

Notez le temps de démarrage du transcodage de référence, l’utilisation du CPU, l’utilisation du GPU et du moteur vidéo, ainsi que la stabilité de la lecture. Vous disposerez ainsi d’un résultat de contrôle pour le test de partage. Sans référence fiable, vous ne pourrez pas déterminer si les problèmes ultérieurs proviennent de la concurrence ou de la configuration GPU initiale de Plex.

Exposez délibérément le même périphérique au second conteneur

Pour NVIDIA, Docker Compose peut réserver des GPU par nombre ou par ID de périphérique pour un service. Si deux services sont configurés pour voir le même GPU, le moteur d’exécution peut exposer ce périphérique aux deux conteneurs ; il s’agit d’un contrôle d’accès, et non d’une garantie de performances exclusives. Pour Intel ou d’autres périphériques Linux, les deux conteneurs peuvent obtenir l’accès au même nœud de périphérique concerné lorsque le pilote autorise une utilisation simultanée.

La documentation de Docker sur la prise en charge des GPU par Compose montre comment les services demandent un accès au GPU et ciblent des ID de périphériques précis. Utilisez un périphérique spécifique si vous disposez de plusieurs GPU, afin que Plex ne passe pas discrètement d’un périphérique à l’autre pendant le test du partage.

Vérifiez les autorisations après chaque recréation de conteneur ou modification du modèle d’application. Le fait qu’un second conteneur fonctionne ne prouve pas que Plex dispose toujours de l’accès au périphérique, et le fait qu’un paramètre Plex indique que l’accélération matérielle est activée ne prouve pas que le flux actif l’utilise.

Testez les deux charges ensemble et surveillez la première ressource qui sature

Démarrez la seconde charge de travail à un niveau représentatif, puis forcez le même transcodage Plex que pour la référence. Comparez la stabilité de la lecture, la vitesse de transcodage, la mémoire GPU, l’utilisation du moteur vidéo et le recours au CPU. Si Plex passe du mode matériel au mode logiciel ou commence à mettre la lecture en mémoire tampon uniquement lorsque l’autre charge est active, vous avez identifié un problème de concurrence et non un mystère de compatibilité.

Le guide de vérification préalable des GPU de ZimaSpace recommande de vérifier non seulement la détection du périphérique, mais aussi l’accès des conteneurs et le maintien de la réactivité du stockage, des sauvegardes et des tâches multimédias sous la charge combinée. Ce test de l’ensemble du système est particulièrement important sur un NAS où Plex n’est pas l’unique service qui compte.

Si les charges utilisent des moteurs GPU différents, le partage peut très bien fonctionner ; si elles se disputent les mêmes moteurs d’encodage ou de décodage vidéo, la mémoire ou la marge de puissance et de température, les performances peuvent fortement diminuer. Ne supposez pas qu’un faible pourcentage d’utilisation globale du « GPU » signifie que le moteur vidéo spécifique dont Plex a besoin est disponible.

-15% OFF

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

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

Déterminez à partir de quand le partage n’est plus une bonne solution

Conservez la configuration partagée si Plex reste en mode matériel, si le second conteneur atteint son objectif et si le NAS reste réactif sous la charge combinée. Répétez le test après un redémarrage de Plex et après le redémarrage du second conteneur afin de vérifier que les mappages de périphériques et les autorisations résistent aux événements courants du cycle de vie.

Si la concurrence est occasionnelle, planifiez la charge lourde du second conteneur en dehors des périodes de streaming intense ou ajoutez des limites au niveau des applications. Si les deux charges doivent fonctionner simultanément à pleine capacité et que l’une prive systématiquement l’autre de ressources, dédiez un second accélérateur à l’une d’elles ou déplacez-la vers un autre hôte au lieu de chercher à ajuster des priorités de manière fragile.

Passez au dépannage du pilote ou du moteur d’exécution lorsque l’un ou l’autre conteneur perd l’accès au GPU même lorsque l’autre est arrêté. Un problème de partage ne doit être diagnostiqué qu’après avoir confirmé que les deux applications peuvent accéder indépendamment au périphérique et que l’échec apparaît spécifiquement lors de l’utilisation simultanée.