Test d'effort NVidia GPU sur le transcodage en direct

Vous trouverez ci-dessous une histoire détaillée sur la façon dont nous avons chargé la carte de NVidia avec les tâches de transcodage de la vidéo pour sa diffusion. Montrons que nous avons essayé ce qui s'est passé et comment utiliser au mieux les cartes vidéo pour la diffusion en ligne.
Depuis plusieurs années, notre équipe développe des produits pour le traitement et la distribution de contenu multimédia en ligne. Cet article a récemment expliqué pourquoi les propriétaires de contenu pourraient avoir besoin de telles solutions à l'ère de YouTube.

L'un de nos produits est le serveur multimédia Nimble Streamer , qui est un logiciel serveur qui prend les flux en direct et les fichiers à l'entrée et les rend accessibles à un grand nombre de téléspectateurs, tout en lui permettant simultanément de monétiser le contenu. Il s'agit d'une application native écrite en C ++ et portée sur tous les systèmes d'exploitation (Linux, Windows, MacOS) et plates-formes populaires (x64, ARM). Dès le début, une faible consommation de ressources et une productivité élevée étaient les principales exigences, et nous parvenons à obtenir de bons résultats dans ce domaine.

L'année dernière, nous avons publié le module complémentaire Nimble Streamer - transcodeur de diffusion en direct . Cette application vous permet de prendre le flux d'entrée vidéo et / ou audio dans différents formats et d'effectuer diverses conversions avec eux en temps réel. La fonctionnalité comprend le décodage (logiciel et matériel), la conversion vidéo et audio à l'aide de filtres (redimensionnement, superposition, etc.) et l'encodage (codage) - logiciel et matériel.

Le transcodeur est contrôlé via le service Web WMSPanel, les scripts de transcodage sont créés via l'interface glisser-déposer, ce qui vous permet de voir visuellement le processus. Différents scénarios peuvent être exécutés ensemble - avec cette approche, il est pratique d'exécuter des combinaisons de tests, en chargeant le serveur dans toutes les variantes.
Dans ces vidéos, vous pouvez voir des exemples de fonctionnement de l'interface.

Le décodage de chaque flux n'est effectué qu'une seule fois avant toutes les autres conversions ... Cela vous permet d'économiser des ressources sur une opération de décodage coûteuse, cela sera clairement visible plus loin au cours des tests.

L'un des mécanismes de conversion qui peuvent être utilisés dans notre transcodeur est le décodage matériel et l'encodage vidéo à l'aide du GPU de NVidia. Les cartes graphiques des dernières générations vous permettent d'assumer certaines des tâches typiques, ce qui supprime la charge du processeur. Notre transcodeur est capable de fonctionner avec ce matériel, qui est activement utilisé par nos clients.


Au cours de la communication avec les représentants du bureau russe de NVidia, on nous a demandé d'essayer d'organiser des tests de résistance conjoints de notre transcodeur et du GPU NVidia afin de comprendre quel sera l'effet économique d'un tel tandem par rapport à un transcodage exclusivement logiciel, sans accélération matérielle. De plus, je voulais comprendre comment utiliser de manière optimale le GPU, et si possible donner de bonnes recettes.

Nous devions obtenir rapidement le fer approprié et y avoir accès, pour le cycle de nos expériences. Nous avions prévu de nous rencontrer quelques semaines. Reste à savoir où se procurer le matériel. La meilleure option serait de les trouver dans le cloud et d'accéder à distance. Après avoir recherché les options, il s'est avéré qu'AWS n'a pas encore de machine virtuelle avec un GPU de génération Maxwell, et dans le cloud Azure, il est seulement prévu de commencer à les fournir bientôt.

1. Repasser à partir de NVidia dans le cloud Softlayer, configuration de Nimble Streamer

Avec l'aide de NVidia, IBM nous a fourni un accès à son cloud, IBM Bluemix Cloud Platform (anciennement Softlayer ). Il s'agit d'un vaste réseau de centres de données modernes (environ 50 au moment de la publication) dans le monde, connectés par un réseau privé commun et fournissant une large sélection de services d'infrastructure cloud. Tous les centres de données sont unifiés et vous permettent de louer de un à des centaines de serveurs virtuels ou physiques de la configuration requise pendant plusieurs heures, ainsi que des équilibreurs, des systèmes de stockage, des pare-feu - en général, tout ce qui est nécessaire pour construire une infrastructure informatique fiable pour le service informatique déployé.

Le bureau de représentation russe d'IBM nous a donné un accès complet au portail en libre-service pour la gestion des services cloud et à la configuration de serveur nécessaire, où nous avons pu travailler avec différents flux d'entrée et paramètres de notre transcodeur.

Le fer

Tout d'abord, nous avons reçu un serveur physique (bare-metal) avec 128 Go de RAM et 2xGPU NVidia Tesla M60 et OS préinstallé Ubuntu 14.04. Tous les paramètres du serveur, mots de passe, versions du micrologiciel, sa commutation, IP dédiée, l'état des composants matériels, étaient visibles directement dans votre compte personnel, vous permettant de faire les manipulations requises avec le matériel loué, ce qui minimisait le besoin d'interaction avec le support IBM. Au cours du test, il s'est avéré que nous n'avons pas pu charger de manière optimale cette configuration, en raison d'un certain nombre de limitations dans la génération des contextes.

Nous voulions réduire la configuration. Depuis que nous avons utilisé la plate-forme cloud, elle était requise via le portail libre-service pour demander des modifications de configuration. Après approbation, cette opération a pris environ 2 heures jusqu'à la fenêtre de service approuvée. Pendant ce temps, le personnel technique du centre de données d'Amsterdam a retiré des composants supplémentaires (emplacements RAM et 1xGPU) du serveur qui nous avait été fourni plus tôt et l'a remis en service. Il convient de noter que pour les développeurs, cette option est très pratique, car il n'est pas nécessaire de traiter les paramètres matériels, de les réparer ou même de passer du temps à installer le système d'exploitation. Permettez-moi de vous rappeler que dans ce cas, l'hyperviseur n'est pas utilisé car nous devons tirer le maximum des ressources matérielles.

Sur la base des résultats de nos recherches, nous avons opté pour la configuration de serveur suivante:

Double Intel Xeon E5-2690 v3 (2,60 GHz)
24 coeurs
64 Go de RAM
1TB SATA

Nous avons 2 processeurs avec 12 cœurs chacun, et grâce à l'hyper threading, nous en obtenons deux fois plus, c'est-à-dire pratiquement 48 cœurs.

Dans les scénarios avec un accélérateur graphique, une carte basée sur la puce GM204 - Tesla M60 a été utilisée:

NVIDIA Tesla M60
1xGPU: 2 x Maxwell GM204
Mémoire: 16 Go GDDR5
Fréquence d'horloge: 2,5 GHz
Noyaux NVIDIA CUDA: 2 x 2048
Bande passante mémoire: 2 x 160 Go / sec

J'attire votre attention sur le fait qu'aucune affinité, réglage de puce, overclocking ou autre magie n'a été effectué sur le matériel réduit - uniquement des CPU et GPU non overclockés, et pour le GPU, seul le pilote officiel tiré du site Web NVidia a été utilisé. Si quelqu'un a une expérience similaire - partagez les commentaires.

Nous avons donc eu accès. Une connaissance rapide de l'interface Web du panneau de contrôle (tout est simple et clair là-bas), puis l'accès au serveur via SSH - et nous voici dans la ligne de commande Ubuntu habituelle, mettez Nimble Streamer, enregistrez une nouvelle licence de transcodeur et faites une petite configuration.

Transcodeur de streamer agile

Nimble Streamer a été configuré pour pré-créer le cache de contexte GPU. Cela est dû au fait que le GPU a une limite sur le nombre maximum de contextes de décodage et d'encodage créés, et en outre, la création de contextes à la volée peut prendre trop de temps.
Plus de détails sur le problème de la création de contextes peuvent être trouvés dans la section correspondante ci-dessous.

Paramètres Nimbl sur l'exemple de la première série de tests:

nvenc_context_cache_enable = true
nvenc_context_create_lock = true
nvenc_context_cache_init = 0: 30: 15.1: 30: 15
nvenc_context_reuse_enable = true

Plus de détails sur ces paramètres sont écrits dans notre article .

Avant de démarrer chaque série de tests, le cache était configuré séparément, en tenant compte des spécificités de chaque tâche.

Créer des scripts de transcodage

D'autres travaux se sont poursuivis dans notre service WMSPanel, où les scripts du transcodeur sont configurés.

Comme déjà mentionné, le travail passe par l'interface web, tout est extrêmement clair et pratique. Nous avons créé un certain nombre de scénarios combinant différentes options de transcodage (CPU / GPU), différentes options de résolution et différents paramètres d'encodage (CPU / GPU, profil, débit binaire, etc.)

Des ensembles de scénarios peuvent être exécutés simultanément, ce qui permet d'introduire différentes combinaisons de tests, d'augmenter la charge dans un ordre différent et de la modifier en fonction de la situation. Sélectionnez simplement les scénarios nécessaires et arrêtez-les ou reprenez-les.

Voici un ensemble de scénarios:


Voici un exemple de l'un des scénarios:


Le décodeur GPU ressemble à ceci:


Nous appliquons le filtre de taille d'image:


Et voici l'encodeur pour la variante GPU:



En général, le fonctionnement de l'interface du transcodeur peut être vu dans ces vidéos .

2. Transcodage de flux FullHD 1080p

Pour commencer, nous avons testé le scénario avec les charges les plus élevées afin de découvrir les limites des capacités en fer. À l'heure actuelle, la «plus lourde» des résolutions utilisées dans la pratique est FullHD 1080p.

Pour générer les flux en direct d'origine, un fichier a été pris en FullHD (1920 * 1080) en profil haut H.264 . Le contenu lui-même est une visite vidéo de la ville, c'est-à-dire Il s'agit d'une vidéo avec un taux de changement d'image moyen. Il n'y a pas de trames statiques monochromes qui pourraient faciliter le travail du transcodeur, mais il n'y a pas de changement trop rapide de types et de couleurs. En un mot - une charge assez typique.

36 flux identiques ont été introduits dans l'entrée Nimble Streamer, qui ont ensuite été utilisés dans le transcodeur dans différents scénarios.

Le scénario de transcodage est utilisé de manière typique - le flux entrant est un profil haut 1080p , 720p, 480p, un profil principal 360p en est créé , puis les flux de profil de base: 240p, 160p . Au total, il y a 1 flux à l'entrée et 5 à la sortie. Habituellement, une transmission (transfert sans modifications) du flux d'origine est également effectuée afin que le spectateur puisse sélectionner 1080p lui-même lors de la visualisation. Nous ne l'avons pas ajouté dans le script, car il n'utilise pas de transcodage - il y a un transfert direct des données de l'entrée à la sortie. Ce scénario est optimisé dans Nimble et en conditions réelles, il augmentera la consommation de mémoire relativement légèrement.
Audio dans les flux générés - non. L'ajout d'audio au script ne causera pas de charges CPU importantes, mais pour la pureté de l'expérience, nous avons exclu le son.

Test CPU, pas de GPU

Pour commencer, nous avons lancé le transcodage des scripts sans utiliser de GPU, en spécifiant le décodeur logiciel et l'encodeur dans les scripts.

En conséquence, il n'a été possible de traiter que 16 flux d'entrée avec l'émission de 80 flux de toutes les autorisations de sortie.

Charge CPU - 4600%, soit 46 cœurs ont été impliqués. Consommation de RAM - environ 15 Go.

Test CPU + GPU

Le cache de contexte au démarrage est configuré comme 0: 30: 15.1: 30: 15 - c'est-à-dire 30 contextes pour l'encodage, 15 pour le décodage, chaque GPU.

Permettez-moi de vous rappeler que sur le GPU, nous avons deux cœurs, ce qui nous permet de paralléliser les tâches - cela nous est utile.

La charge maximale a été obtenue avec la configuration de débit suivante.

Le décodeur d'entrée GPU0 et GPU1 - 15 flux. Ainsi, nous obtenons 30 flux décodés, prêts pour une utilisation ultérieure. Chaque flux n'est décodé qu'une seule fois, quel que soit le nombre de scénarios utilisés à l'avenir.

Les encodeurs GPU0 et GPU1 ont reçu 15 flux chacun pour obtenir 720p, c'est-à-dire 30 flux de 720p sur une sortie se sont avérés.

En outre, les encodeurs GPU0 et GPU1 ont chacun fourni 15 flux pour 480p - et 30 flux de 480p ont également été émis.

Les contextes d'encodeur étant épuisés, l'encodage des autorisations restantes a été défini sur le CPU. Il s'est avéré ce qui suit:

1. 30 flux 360p
2. 30 flux 240p
3. 30 flux 160p

La charge s'est avérée être 2600% CPU, 75% décodeur, 32% encodeur. Ensuite, le CPU a été chargé avec 6 flux pour le décodage, pour chaque 5 résolutions similaires ont été configurées, pour un total de 30 threads par sortie.

Au total, 36 flux ont été reçus en entrée, 180 ont été émis en sortie . La charge finale est fixée comme suit: 4400% CPU, 75% décodeur de carte, 32% encodeur de carte, 30 Go de RAM .

Quelques détails

Nous avons décidé de vérifier l'option dans laquelle nous traitons les tâches les plus difficiles sur le GPU - décodage 1080 et codage 720 et 480, et laisser le reste être traité via le CPU.

Tout d'abord, nous avons vérifié la limite du décodeur. Avec 22 threads, le décodage était affecté par le problème des contextes, ils ne pouvaient tout simplement pas être créés. Diminué à 21 - des contextes ont été créés, mais la charge est devenue à 100% et des artefacts ont commencé à être observés dans le cours d'eau. Nous nous sommes arrêtés à 20 flux - nous faisons le décodage de 20 flux, l'encodage à 160p - tout fonctionne bien.

De plus, il s'est avéré empiriquement que cette carte avec 16 Go de RAM à bord peut fonctionner en toute confiance avec 47 contextes - et il n'y a pas de différence, ce sont les contextes d'un encodeur ou d'un décodeur. Je répète - il s'agit spécifiquement de ce GPU Tesla M60, sur d'autres cartes, ce nombre peut être différent. Nous pensons que si la carte avait 24 Go de RAM, le nombre de contextes pourrait être différent, mais cela doit être testé.

En conséquence, nous avons choisi la formule de création de cache "15 contextes du décodeur et 30 contextes de l'encodeur" - qui donne 30 flux à l'entrée et pour chacun vous permet de créer 2 autorisations. Ainsi, les résolutions supérieures - 720 et 480 - ont été lancées sur le GPU, et les autres - 360, 240 et 160 - ont été envoyées au CPU. Et puisque le CPU était encore libre après cela, nous avons «terminé» les cœurs gratuits avec de nouveaux threads, laissant 4 cœurs pour les tâches utilitaires.

3. Transcodage de flux HD 720p

Scénario de charge typique La plupart du contenu est désormais créé en HD. Même le récent SuperBowl LI - l'émission la mieux notée sur le marché américain - a été diffusé en HD , laissant FullHD pour l'avenir.

Pour générer les flux source, un fichier a été pris en HD (1280 * 720) dans un profil élevé . Le contenu est la série préférée de notre ingénieur «The Good Wife», c'est-à-dire Il s'agit d'une vidéo avec un taux de changement d'image moyen.

À l'entrée du Nimble Streamer, 70 flux identiques ont été alimentés, qui ont ensuite été utilisés dans le transcodeur dans différents scénarios.

Le scénario de transcodage suivant est utilisé - le flux entrant est un profil haut 720p, un profil principal 480p, 360p , puis des flux de profil de base 240p, 160p sont créés à partir de celui-ci. Total, à l'entrée 1, à la sortie 4. La transmission du flux d'origine, comme dans le scénario précédent, n'a pas été effectuée. L'audio dans les flux générés ne l'est pas non plus.

Test CPU, pas de GPU

Comme dans la section précédente, nous avons essayé de transcoder les flux uniquement sur le CPU. En conséquence, il n'a été possible de traiter que 22 flux d'entrée avec l'émission de 88 flux de toutes les autorisations de sortie. Charge CPU - 4700%, soit 47 cœurs ont été impliqués. Consommation de RAM - environ 20 Go.

Test CPU + GPU

Le cache de contexte au démarrage est configuré comme 0: 23: 23.1: 23: 23 - c'est-à-dire 23 contextes pour l'encodage, 23 pour le décodage pour chaque GPU.

En utilisant le GPU, 46 flux 720p ont été décodés. Là, sur le GPU, 46 flux de 480p ont été encodés. Ensuite, l'encodage 360p, 240p et 160p a été effectué sur le CPU - 46 flux chacun.
Charge fixe de 2100% CPU, 61% du décodeur, 16% de l'encodeur.

De plus, l'encodage et le décodage de 24 threads vers le CPU ont été lancés, pour chaque 1 thread - 4 sorties, comme pour le GPU.

Au total, 70 flux ont été entrés, 280 flux ont été sortis .
Charge: 4600%, 61% du décodeur, 16% de l'encodeur, 30 Go de RAM .

Comme pour le test précédent, peut-être qu'un GPU RAM plus grand donnerait plus de contextes et nous pourrions gérer plus de threads. Mais ce n'est qu'en théorie, il faut vérifier.

4. Le problème avec la création de contextes dans le GPU NVidia

Quelques mots sur le problème qui ne nous a pas permis de traiter plus de threads sur le GPU.

À la fin de l'année dernière, nous avons effectué des tests avec l'équipe de NVidia, avec plusieurs cartes. Lorsque vous travaillez avec plusieurs GPU, il s'est avéré que la création de contextes ralentit considérablement le serveur - la création de chaque nouveau contexte prenait de plus en plus de temps de la carte. Si le premier contexte a été créé de l'ordre de 300 ms, alors chacun des suivants a ajouté 200 à 300 ms et déjà dans les troisièmes dix contextes, la création d'un nouveau a pris 3-4 secondes chacun. Lorsqu'un utilisateur crée un script de transcodage, il est supposé qu'il commence à travailler immédiatement et sans retards, et cette nouvelle circonstance annule tous les avantages de la vitesse Nimbl et retarde la création de contextes qui entraînent des retards dans le démarrage de l'encodage.

Au début, les soupçons étaient tombés sur Nimble, mais ensuite nous avons fait des tests en utilisant ffmpeg, que NVidia lui-même fournit aux clients et le résultat s'est avéré être exactement le même - le GPU passe de plus en plus de temps à créer chaque nouveau contexte. Dans des conditions où le serveur est déjà en train de transcoder et que vous devez démarrer de nouveaux threads pour le traitement, cela affecte les performances globales et rend le serveur tout simplement inutilisable.

Le problème a été décrit en détail par l'équipe NVidia, mais jusqu'à présent aucune solution à temps plein n'a été fournie. Par conséquent, nous avons jusqu'à présent implémenté un mécanisme de mise en cache de contexte dans notre serveur, avec la création préliminaire de contextes au démarrage du serveur. Cela a résolu le problème du point de vue du travail de l'utilisateur final, mais le démarrage du Nimbl peut prendre un certain temps. La configuration de Nimbl pour un travail efficace avec les contextes est décrite dans notre blog .

De plus, les contextes ne sont pas faciles à créer. Avec un grand nombre de contextes lors de l'inclusion d'un script de transcodage, l'API NVENC commence à générer des erreurs: «L'appel d'API a échoué car il n'a pas pu allouer suffisamment de mémoire pour effectuer l'opération demandée.»

Empiriquement, il s'est avéré qu'un GPU peut démarrer et fonctionner en toute confiance avec 47 contextes - et il n'y a pas de différence, ce sont les contextes d'un encodeur ou d'un décodeur. On supposait que cela était dû à la quantité de mémoire sur le GPU. Maintenant, il y a 16 Go, si vous mettez une carte avec 24 Go, il est probable que plus de contextes puissent être créés. Mais ce n'est qu'une théorie, il faut vérifier, comme mentionné précédemment. Les données obtenues sont valables pour un modèle de GPU spécifique, les autres cartes doivent être testées séparément.

C'est la restriction du nombre de contextes qui fait l'obstacle principal lorsque l'on travaille avec des charges importantes.

5. Conclusions

Ainsi, le but du test était d'étudier l'efficacité du GPU pour la gamme de tâches indiquée et de développer des recettes pour son utilisation appropriée. Quel est le résultat?

Effet économique

Ci-dessus, nous avons vu comment le nombre de threads pouvant être traités sur le CPU et sur le tandem CPU + GPU est différent. Voyons ce que cela signifie en termes d'argent. Comme base, nous prenons tous les mêmes Softlayer et leurs prix de location d'équipement.

• La configuration sans GPU coûtera 819 $ par mois . Ici, vous pouvez récupérer une voiture.
• La configuration avec le GPU coûtera 1729 $ par mois pour le centre de données d'Amsterdam, les prix peuvent être trouvés ici . Lorsque vous utilisez un GPU, le prix de location du serveur augmente légèrement, car le plus grand facteur de forme de boîtier 2U est utilisé. L'effet économique sera probablement plus important lors de l'achat d'équipement (mais cela nécessite une analyse sérieuse du TCO, compte tenu de la mise à jour constante de la gamme GPU NVidia).

Voyons maintenant les résultats du test:

Pour FullHD 1080p

• CPU sans GPU: 16 threads par entrée + 80 threads par sortie
• CPU + GPU: 36 threads par entrée + 180 par sortie

Avantage GPU: 2,25x.

Avantages de l'utilisation du GPU: 819 $ * 2,25 - 1729 $ = 113 $ par mois lors de la location d'un serveur avec un GPU.

Pour HD 720p

• CPU sans GPU: 22 threads par entrée + 88 threads par sortie
• CPU + GPU: 70 threads par entrée + 280 par sortie

Avantage GPU: 3,18x.

Bénéficiez de l'utilisation du GPU: 819 $ * 3,18 - 1729 $ = 875 $ par mois lors de la location de 1 serveur avec un GPU

Autrement dit, avec l'option de location, les économies sont assez importantes. Cela ne tient pas compte des rabais - au bureau russe d'IBM, ils promettent des rabais sur la location de ressources dans le cloud par rapport aux prix présentés ici.

Nous n'avons pas abordé les options avec l'achat, car ici, le TCO dépend fortement du choix du fournisseur, du coût du service dans le centre de données et d'autres facteurs familiers à ceux qui travaillent avec du métal nu. Cependant, les chiffres préliminaires parlent également en faveur d'une solution basée sur GPU.

— , , , ..

L'option avec une carte graphique par serveur nous semble plus rentable que l'option avec deux cartes ou plus. Comme nous pouvons le voir, le décodeur GPU a toujours chargé plus que l'encodeur, mais même il est resté sous-chargé en raison de problèmes avec l'utilisation des contextes. Si vous ajoutez une deuxième carte, le décodeur sera encore moins utilisé, les encodeurs que nous ne pourrons pas charger à pleine capacité, et tout le travail sur l'encodage devra encore être déplacé vers le CPU, ce qui ne sera pas justifié pour l'argent. Nous avons également testé l'option avec deux GPU grâce au support de Softlayer, mais en raison du faible effet économique, nous ne donnons pas de détails dans l'article.

Par conséquent, pour faire évoluer la charge, il est préférable d'ajouter de nouveaux serveurs avec une carte graphique plutôt que d'ajouter des cartes aux machines existantes.

Si le nombre de flux entrants et sortants pour votre projet est relativement faible - disons, une douzaine de flux HD avec un petit nombre d'autorisations de sortie, avec une quantité de filtrage relativement faible, il serait plus judicieux d'utiliser un serveur sans GPU.

Il convient également de noter que la quantité de RAM pour la tâche de conversion des threads n'est pas aussi importante que la puissance de traitement. Ainsi, dans certains cas, vous pouvez également économiser en réduisant la quantité de mémoire.

Conclusion

— CPU GPU Tesla M60 — . GPU — , CPU.

- , — .