Geekly articles weekly

NVidia GPU-Stresstest bei Live-Stream-Transcodierung

Im Folgenden finden Sie eine detaillierte Geschichte darüber, wie wir die Karte von NVidia mit den Aufgaben des Transcodierens von Videos für das Streaming geladen haben. Lassen Sie uns zeigen, dass wir versucht haben, was passiert ist und wie Grafikkarten am besten für das Online-Streaming verwendet werden können.
Seit mehreren Jahren entwickelt unser Team Produkte für die Verarbeitung und Verbreitung von Medieninhalten online. In diesem Artikel wurde kürzlich beschrieben, warum Content-Besitzer in unserem YouTube-Zeitalter möglicherweise solche Lösungen benötigen.

Eines unserer Produkte ist der Nimble Streamer- Medienserver, eine Serversoftware, die Live-Streams und -Dateien zur Eingabe überträgt und sie einer großen Anzahl von Zuschauern zugänglich macht, während gleichzeitig Inhalte monetarisiert werden können. Dies ist eine native Anwendung, die in C ++ geschrieben und auf alle gängigen Betriebssysteme (Linux, Windows, MacOS) und Plattformen (x64, ARM) portiert wurde. Von Anfang an waren ein geringer Ressourcenverbrauch und eine hohe Produktivität die Hauptanforderungen, und wir erzielen hier gute Ergebnisse .

Letztes Jahr haben wir den Nimble Streamer Add-On - Live Stream Transcoder - veröffentlicht . Mit dieser Anwendung können Sie den Eingabestream von Video und / oder Audio in verschiedenen Formaten aufnehmen und verschiedene Konvertierungen mit ihnen in Echtzeit durchführen. Die Funktionalität umfasst Decodierung (sowohl Software als auch Hardware), Video- und Audiokonvertierung mithilfe von Filtern (Größenänderung, Overlay usw.) und Codierung (Codierung) - sowohl Software als auch Hardware.

Der Transcoder wird über den WMSPanel-Webdienst gesteuert. Transcodierungsskripte werden über die Drag-and-Drop-Oberfläche erstellt, sodass Sie den Prozess visuell sehen können. Verschiedene Szenarien können zusammen ausgeführt werden. Bei diesem Ansatz ist es praktisch, Testkombinationen auszuführen und den Server in beliebigen Variationen zu laden.
In diesen VideosSie können Beispiele für die Funktionsweise der Benutzeroberfläche sehen.

Die Dekodierung jedes Streams erfolgt nur einmal vor allen weiteren Konvertierungen ... Dies ermöglicht es Ihnen, Ressourcen bei einem teuren Dekodierungsvorgang zu sparen. Dies wird in den Tests deutlich.

Einer der Konvertierungsmechanismen, die in unserem Transcoder verwendet werden können, ist die Hardware-Decodierung und Videocodierung mit der GPU von NVidia. Mit Grafikkarten der neuesten Generationen können Sie einige der typischen Aufgaben übernehmen, wodurch die CPU entlastet wird. Unser Transcoder kann mit dieser Hardware arbeiten, die von unseren Kunden aktiv genutzt wird.


Im Rahmen der Kommunikation mit Vertretern des russischen Büros von NVidia wurden wir gebeten, gemeinsame Stresstests für unseren Transcoder und die NVidia-GPU durchzuführen, um zu verstehen, wie sich die wirtschaftlichen Auswirkungen eines solchen Tandems auf die ausschließliche Software-Transcodierung ohne Hardwarebeschleunigung auswirken. Außerdem wollte ich verstehen, wie man die GPU optimal nutzt und wenn möglich gute Rezepte gibt.

Für den Zyklus unserer Experimente mussten wir schnell das geeignete Eisen und den Zugang dazu finden. Wir wollten uns ein paar Wochen treffen. Es bleibt zu finden, wo die Ausrüstung zu bekommen ist. Die beste Option wäre, sie in der Cloud zu finden und Fernzugriff zu erhalten. Nach der Suche nach den Optionen stellte sich heraus, dass AWS noch keine VM mit einer GPU der Maxwell-Generation hat. In der Azure-Cloud ist nur geplant, diese bald bereitzustellen.

1. Bügeln Sie NVidia in der Softlayer-Cloud und richten Sie den Nimble Streamer ein


Mit Unterstützung von NVidia verschaffte uns IBM Zugriff auf seine Cloud, die IBM Bluemix Cloud Platform (ehemals Softlayer ). Dies ist ein großes Netzwerk moderner Rechenzentren (zum Zeitpunkt der Veröffentlichung etwa 50) auf der ganzen Welt, die über ein gemeinsames privates Netzwerk verbunden sind und eine große Auswahl an Cloud-Infrastrukturdiensten bieten. Alle Rechenzentren sind vereinheitlicht und ermöglichen es Ihnen, mehrere Stunden lang einen bis Hunderte von virtuellen oder physischen Servern der erforderlichen Konfiguration sowie Balancer, Speichersysteme und Firewalls zu mieten - im Allgemeinen alles, was zum Aufbau einer zuverlässigen IT-Infrastruktur für den bereitgestellten IT-Service erforderlich ist.

Die russische Repräsentanz von IBM gewährte uns vollen Zugriff auf das Self-Service-Portal zur Verwaltung von Cloud-Diensten und zur gewünschten Serverkonfiguration, wo wir mit verschiedenen Eingabestreams und den Einstellungen unseres Transcoders arbeiten konnten.

Eisen


Zunächst erhielten wir einen physischen Server (Bare-Metal) mit 128 GB RAM und 2xGPU NVidia Tesla M60 sowie das vorinstallierte Betriebssystem Ubuntu 14.04. Alle Serverparameter, Kennwörter, Firmware-Versionen, deren Umschaltung, dedizierte IP-Adresse und der Status der Hardwarekomponenten wurden direkt in Ihrem persönlichen Konto angezeigt, sodass Sie die erforderlichen Manipulationen mit der gemieteten Hardware vornehmen konnten, wodurch die Notwendigkeit einer Interaktion mit dem IBM Support minimiert wurde. Während des Testlaufs stellte sich heraus, dass wir diese Konfiguration aufgrund einer Reihe von Einschränkungen bei der Generierung von Kontexten nicht optimal laden konnten.

Wir wollten die Konfiguration reduzieren. Da wir die Cloud-Plattform verwendet haben, war es über das Self-Service-Portal erforderlich, Konfigurationsänderungen anzufordern. Nach der Genehmigung dauerte dieser Vorgang ca. 2 Stunden bis zum genehmigten Servicefenster. Während dieser Zeit entfernte das technische Personal im Amsterdamer Rechenzentrum zusätzliche Komponenten (RAM-Steckplätze und 1xGPU) von dem Server, der uns zuvor zur Verfügung gestellt wurde, und nahm ihn wieder in Betrieb. Es sollte beachtet werden, dass diese Option für Entwickler sehr praktisch ist, da weder die Hardwareeinstellungen bearbeitet, repariert noch Zeit für die Installation des Betriebssystems aufgewendet werden müssen. Ich möchte Sie daran erinnern, dass in diesem Fall der Hypervisor nicht verwendet wird, da wir das Maximum aus den Hardwareressourcen herausholen müssen.

Basierend auf den Ergebnissen unserer Forschung haben wir uns für die folgende Serverkonfiguration entschieden:
Dual Intel Xeon E5-2690 v3 (2,60 GHz)
24 Kerne
64 GB RAM
1 TB SATA

Wir haben 2 Prozessoren mit jeweils 12 Kernen und dank Hyper-Threading erhalten wir doppelt so viel, d. H. praktisch 48 Kerne.

In Szenarien mit einem Grafikbeschleuniger wurde eine Karte verwendet, die auf dem GM204-Chip - Tesla M60 - basiert:
NVIDIA Tesla M60
1xGPU: 2 x Maxwell GM204
Speicher: 16 GB GDDR5
Taktrate: 2,5 GHz
NVIDIA CUDA-Kerne: 2 x 2048
Speicherbandbreite: 2 x 160 GB / s

Ich mache Sie darauf aufmerksam, dass auf der reduzierten Hardware keine Affinität, Chip-Tuning, Übertaktung oder andere Magie angewendet wurde - nur nicht übertaktete CPUs und GPUs, und für die GPU wurde nur der offizielle Treiber verwendet, der von der NVidia-Website stammt. Wenn jemand eine ähnliche Erfahrung hat - teilen Sie in den Kommentaren.

Also haben wir Zugang bekommen. Eine schnelle Kenntnis der Weboberfläche des Control Panels (dort ist alles einfach und klar), dann Zugriff auf den Server über SSH - und hier befinden wir uns in der üblichen Ubuntu-Befehlszeile, setzen Nimble Streamer, registrieren eine neue Transcoder-Lizenz und führen ein wenig Konfigurations-Setup durch.

Flinker Streamer-Transcoder


Nimble Streamer wurde so konfiguriert, dass der GPU-Kontextcache vorab erstellt wird. Dies liegt an der Tatsache, dass die GPU die maximale Anzahl der erstellten Dekodierungs- und Codierungskontexte begrenzt. Darüber hinaus kann das Erstellen von Kontexten im laufenden Betrieb zu lange dauern.
Weitere Details zum Problem der Erstellung von Kontexten finden Sie im entsprechenden Abschnitt unten.

Flinke Einstellungen am Beispiel der ersten Testreihe:
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

Weitere Details zu diesen Einstellungen finden Sie in unserem Artikel .

Vor Beginn jeder Testreihe wurde der Cache separat konfiguriert, wobei die Besonderheiten jeder Aufgabe berücksichtigt wurden.

Erstellen Sie Transcodierungsskripte


Weitere Arbeiten wurden in unserem WMSPanel-Dienst durchgeführt, in dem die Transcoder-Skripte konfiguriert sind.

Wie bereits erwähnt, geht die Arbeit über die Weboberfläche, alles ist äußerst klar und bequem. Wir haben eine Reihe von Szenarien erstellt, in denen verschiedene Transcodierungsoptionen (CPU / GPU), verschiedene Auflösungsoptionen und verschiedene Codierungsparameter (CPU / GPU, Profil, Bitrate usw.) kombiniert werden. Sie

können gleichzeitig Skriptsätze ausführen, wodurch verschiedene Kombinationen in den Umlauf gebracht werden können Tests, erhöhen Sie die Last in einer anderen Reihenfolge und ändern Sie sie je nach Situation. Wählen Sie einfach die erforderlichen Szenarien aus und stoppen oder setzen Sie sie fort.

Hier ist eine Reihe von Szenarien:


Hier ist ein Beispiel für eines der Szenarien:


Der GPU-Decoder sieht folgendermaßen aus:


Wir wenden den Bildgrößenfilter an:


Und hier ist der Encoder für die GPU-Variante:



Im Allgemeinen ist der Betrieb der Transcoder-Schnittstelle in diesen Videos zu sehen .

2. Transcodieren von Streams FullHD 1080p


Zunächst haben wir das Szenario mit den höchsten Belastungen getestet, um die Grenzen der Eisenfähigkeiten herauszufinden. Derzeit ist FullHD 1080p die „schwerste“ der in der Praxis verwendeten Auflösungen.

Um die ursprünglichen Live-Streams zu generieren, wurde eine Datei in FullHD (1920 * 1080) in hochkarätigem H.264 aufgenommen . Der Inhalt selbst ist eine Videotour durch die Stadt, d.h. Dies ist ein Video mit einer durchschnittlichen Bildänderungsrate. Es gibt keine statischen einfarbigen Rahmen, die die Arbeit des Transcoders erleichtern könnten, aber es gibt keinen zu schnellen Wechsel von Typen und Farben. Mit einem Wort - eine ziemlich typische Last.

Dem Nimble Streamer-Eingang wurden 36 identische Streams zugeführt , die dann in verschiedenen Szenarien im Transcoder verwendet wurden.

Das Transcodierungsszenario wird typisch verwendet - der eingehende Stream ist ein 1080p- High- Profile- , 720p-, 480p- und 360p-Hauptprofil, und dann werden die Basisprofil- Streams daraus erstellt : 240p, 160p . Insgesamt gibt es 1 Stream am Eingang und 5 am Ausgang. Normalerweise wird auch ein Durchgang (Übertragung ohne Änderungen) des ursprünglichen Streams durchgeführt, damit der Betrachter beim Anzeigen selbst 1080p auswählen kann. Wir haben es nicht in das Skript eingefügt, weil Es wird keine Transcodierung verwendet - es erfolgt eine direkte Datenübertragung von der Eingabe zur Ausgabe. Dieses Szenario ist in Nimble optimiert und erhöht unter realen Bedingungen den Speicherverbrauch relativ geringfügig.
Audio in den generierten Streams - nein. Das Hinzufügen von Audio zum Skript führt nicht zu einer erheblichen CPU-Auslastung. Aus Gründen der Reinheit des Experiments haben wir den Sound ausgeschlossen.

CPU-Test, keine GPU


Zu Beginn haben wir Transcodierungsskripte ohne Verwendung einer GPU gestartet und in den Skripten den Softwaredecoder und -codierer angegeben.

Infolgedessen konnten nur 16 Eingabeflüsse verarbeitet werden, wobei 80 Flüsse aller Exit-Berechtigungen ausgegeben wurden.

CPU-Auslastung - 4600%, d.h. 46 Kerne waren beteiligt. RAM-Verbrauch - ca. 15 GB.

CPU + GPU-Test


Der Kontext-Cache beim Start ist als 0: 30: 15.1: 30: 15 konfiguriert - d.h. 30 Kontexte zum Codieren, 15 zum Decodieren, jede GPU.

Ich möchte Sie daran erinnern, dass wir auf der GPU zwei Kerne haben, mit denen wir Aufgaben parallelisieren können - das ist nützlich für uns.

Die maximale Last wurde mit der folgenden Strömungskonfiguration erhalten.

Der Eingangsdecoder GPU0 und GPU1 - 15 Streams. So erhalten wir 30 dekodierte Streams, die zur weiteren Verwendung bereit sind. Jeder Stream wird nur einmal dekodiert, unabhängig davon, wie viele Szenarien er in Zukunft verwendet.

Den Codierern GPU0 und GPU1 wurden jeweils 15 Ströme zugeführt, um 720p zu erhalten, d.h. Es stellte sich heraus, dass 30 Streams mit 720p an einem Ausgang vorhanden waren.

Außerdem lieferten die GPU0- und GPU1-Encoder jeweils 15 Streams für 480p - und 30 Streams von 480p wurden ebenfalls ausgegeben.

Da die Encoder-Kontexte erschöpft waren, wurde die Codierung der verbleibenden Berechtigungen für die CPU festgelegt. Es stellte sich Folgendes heraus:

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

Es stellte sich heraus, dass die Last 2600% CPU, 75% Decoder, 32% Encoder war. Als nächstes wurde die CPU mit 6 Streams zum Decodieren geladen, wobei jeweils 5 ähnliche Auflösungen für insgesamt 30 Threads pro Ausgabe konfiguriert wurden.

Insgesamt wurden 36 Streams am Eingang empfangen , 180 wurden am Ausgang ausgegeben . Die endgültige Last wird wie folgt festgelegt: 4400% CPU, 75% Kartendecoder, 32% Kartencodierer, 30 GB RAM .

Einige Details


Wir haben uns entschlossen, die Option zu prüfen, mit der wir die schwierigsten Aufgaben auf der GPU verarbeiten - Dekodierung 1080 und Kodierung 720 und 480 - und den Rest über die CPU verarbeiten zu lassen.

Zuerst haben wir das Limit des Decoders überprüft. Bei 22 Threads war die Dekodierung vom Problem mit den Kontexten betroffen, sie konnten einfach nicht erstellt werden. Auf 21 verringert - Kontexte wurden erstellt, aber die Last wurde 100% und Artefakte wurden im Stream beobachtet. Wir haben bei 20 Streams angehalten - wir dekodieren 20 Streams, codieren bei 160p - alles funktioniert gut.

Darüber hinaus stellte sich empirisch heraus, dass diese Karte mit 16 GB RAM an Bord sicher mit 47 Kontexten arbeiten kann - und es gibt keinen Unterschied, dies sind die Kontexte eines Codierers oder Decodierers. Ich wiederhole - hier geht es speziell um diese Tesla M60 GPU, auf anderen Karten kann diese Nummer anders sein. Wir glauben, dass wenn die Karte 24 GB RAM hätte, die Anzahl der Kontexte unterschiedlich sein könnte, aber dies muss getestet werden.

Aus diesem Grund haben wir die Cache-Erstellungsformel „15 Kontexte des Decoders und 30 Kontexte des Encoders“ gewählt, die der Eingabe 30 Streams gibt und für die jeweils 2 Berechtigungen erstellt werden können. So wurden die oberen Auflösungen - 720 und 480 - auf der GPU gestartet und der Rest - 360, 240 und 160 - an die CPU gesendet. Und da die CPU danach noch frei war, haben wir die freien Kerne mit neuen Threads „fertiggestellt“ und 4 Kerne für nützliche Aufgaben übrig gelassen.

3. Transcodieren von Streams HD 720p


Typisches Lastszenario Der größte Teil des Inhalts wird jetzt in HD erstellt. Sogar die jüngste SuperBowl LI - die bestbewertete Show auf dem US-Markt - wurde in HD ausgestrahlt , sodass FullHD für die Zukunft übrig bleibt.

Um die Quelldatenströme zu generieren, wurde eine Datei in HD (1280 * 720) in einem hohen Profil aufgenommen . Der Inhalt ist die Lieblingsserie unseres Ingenieurs "The Good Wife", d. H. Dies ist ein Video mit einer durchschnittlichen Bildänderungsrate.

Am Eingang zum Nimble Streamer wurden 70 identische Streams eingespeist, die dann in verschiedenen Szenarien im Transcoder verwendet wurden.

Das folgende Transcodierungsszenario wird verwendet: Der eingehende Stream ist ein 720p- High- Profile-, 480p- und 360p-Hauptprofil, und dann werden Streams daraus erstellt240p, 160p Basislinienprofil . Total, bei Eingang 1, bei Ausgang 4. Der Durchgang des ursprünglichen Streams wurde wie im vorherigen Szenario nicht durchgeführt. Audio in den generierten Streams ist auch nicht.

CPU-Test, keine GPU


Wie im vorherigen Abschnitt haben wir versucht, Streams nur auf der CPU zu transkodieren. Infolgedessen konnten nur 22 Eingabeströme mit der Ausgabe von 88 Flüssen aller Exit-Berechtigungen verarbeitet werden. CPU-Auslastung - 4700%, d.h. 47 Kerne waren beteiligt. RAM-Verbrauch - ca. 20 GB.

CPU + GPU-Test


Der Kontext-Cache beim Start ist als 0: 23: 23.1: 23: 23 konfiguriert - d.h. 23 Kontexte zum Codieren, 23 zum Decodieren für jede GPU.

Mit der GPU wurden 46 720p-Streams dekodiert. Dort wurden auf der GPU 46 Streams von 480p codiert. Als nächstes wurden 360p-, 240p- und 160p-Codierungen auf der CPU durchgeführt - jeweils 46 Streams.
Feste Last von 2100% CPU, 61% des Decoders, 16% des Encoders.

Zusätzlich wurde die Codierung und Decodierung von 24 Threads zur CPU für jeden 1 Thread - 4 Ausgänge wie für die GPU gestartet.

Insgesamt wurden 70 Streams eingegeben, 280 Streams wurden ausgegeben .
Last: 4600%, 61% des Decoders, 16% des Encoders, 30 GB RAM .

Wie beim vorherigen Test würde eine größere RAM-GPU möglicherweise mehr Kontexte liefern und wir könnten mehr Threads verarbeiten. Dies ist aber nur theoretisch, es ist notwendig zu überprüfen.

4. Das Problem beim Erstellen von Kontexten in der NVidia-GPU


Ein paar Worte zu dem Problem, das es uns nicht ermöglichte, mehr Threads auf der GPU zu verarbeiten.

Ende letzten Jahres haben wir mit dem Team von NVidia Tests mit mehreren Karten durchgeführt. Bei der Arbeit mit mehreren GPUs stellte sich heraus, dass das Erstellen von Kontexten den Server erheblich verlangsamt. Das Erstellen jedes neuen Kontexts nahm immer mehr Zeit in Anspruch. Wenn der erste Kontext in der Größenordnung von 300 ms erstellt wurde, fügte jeder nachfolgende 200-300 ms hinzu und bereits in den dritten zehn Kontexten dauerte das Erstellen eines neuen Kontexts jeweils 3-4 Sekunden. Wenn ein Benutzer ein Transcodierungsskript erstellt, wird davon ausgegangen, dass er sofort und ohne Verzögerungen mit der Arbeit beginnt. Dieser neue Umstand hat alle Vorteile der Nimbl-Geschwindigkeit zunichte gemacht und Verzögerungen beim Erstellen von Kontexten verursacht, die zu Verzögerungen beim Starten der Codierung geführt haben.

Zuerst fiel der Verdacht auf Nimble, aber dann haben wir Tests mit ffmpeg durchgeführt, die NVidia selbst den Kunden zur Verfügung stellt, und das Ergebnis war genau das gleiche - die GPU verbringt immer mehr Zeit damit, jeden neuen Kontext zu erstellen. Unter Bedingungen, in denen der Server bereits transkodiert und Sie neue Threads für die Verarbeitung starten müssen, wirkt sich dies auf die Gesamtleistung aus und macht den Server einfach unbrauchbar.

Das Problem wurde vom NVidia-Team ausführlich beschrieben, es wurde jedoch bisher keine Vollzeitlösung bereitgestellt. Aus diesem Grund haben wir bisher einen Kontext-Caching-Mechanismus auf unserem Server implementiert, bei dem beim Serverstart vorläufig Kontexte erstellt werden. Dies löste das Problem aus Sicht der Arbeit des Endbenutzers, aber der Start des Nimbl kann einige Zeit dauern. Konfigurieren Sie Nimbl so, dass es effektiv mit Kontexten arbeitetauf unserem Blog beschrieben .

Darüber hinaus sind Kontexte nicht einfach zu erstellen. Bei einer großen Anzahl von Kontexten, in denen ein Transcodierungsskript enthalten ist, gibt die NVENC-API folgende Fehler aus: "Der API-Aufruf ist fehlgeschlagen, weil nicht genügend Speicher für die Ausführung des angeforderten Vorgangs zugewiesen werden konnte."

Empirisch stellte sich heraus, dass eine GPU mit 47 Kontexten sicher starten und arbeiten kann - und es gibt keinen Unterschied, dies sind die Kontexte eines Codierers oder Decodierers. Es wurde angenommen, dass dies auf die Speichermenge auf der GPU zurückzuführen ist. Jetzt gibt es 16 GB. Wenn Sie eine Karte mit 24 GB einsetzen, können wahrscheinlich mehr Kontexte erstellt werden. Dies ist jedoch nur eine Theorie, die überprüft werden muss, wie bereits erwähnt. Die erhaltenen Daten gelten für ein bestimmtes GPU-Modell, andere Karten müssen separat getestet werden.

Es ist die Beschränkung der Anzahl der Kontexte, die das Haupthindernis beim Arbeiten mit großen Lasten darstellt.

5. Schlussfolgerungen


Ziel des Tests war es daher, die Wirksamkeit der GPU für den angegebenen Aufgabenbereich zu untersuchen und Rezepte für die ordnungsgemäße Verwendung zu entwickeln. Was ist das Ergebnis?

Wirtschaftliche Wirkung


Oben haben wir gesehen, wie unterschiedlich die Anzahl der Threads ist, die auf der CPU und auf dem Tandem CPU + GPU verarbeitet werden können. Mal sehen, was das für Geld bedeutet. Als Basis nehmen wir alle die gleichen Softlayer und deren Ausrüstungsmietpreise.

  • Die Konfiguration ohne GPU kostet 819 US-Dollar pro Monat . Hier können Sie ein Auto abholen .
  • Die Konfiguration mit der GPU kostet 1729 USD pro Monat für das Rechenzentrum in Amsterdam. Die Preise finden Sie hier . Bei Verwendung einer GPU erhöht sich der Servermietpreis geringfügig, da der größere 2U-Fallformfaktor verwendet wird. Der wirtschaftliche Effekt wird beim Kauf von Geräten wahrscheinlich höher sein (dies erfordert jedoch eine gründliche Analyse der Gesamtbetriebskosten unter Berücksichtigung der ständigen Aktualisierung der NVidia-GPU-Linie).

Nun sehen wir uns die Testergebnisse an:

Für FullHD 1080p

  • CPU ohne GPU: 16 Threads pro Eingang + 80 Threads pro Ausgang
  • CPU + GPU: 36 Threads pro Eingang + 180 pro Ausgang

GPU-Vorteil: 2,25x.

Vorteile der Verwendung der GPU: 819 USD * 2,25 USD - 1729 USD = 113 USD pro Monat bei Anmietung eines Servers mit einer GPU.

Für HD 720p

  • CPU ohne GPU: 22 Threads pro Eingang + 88 Threads pro Ausgang
  • CPU + GPU: 70 Threads pro Eingang + 280 pro Ausgang

GPU-Vorteil: 3,18x.

Profitieren Sie von der Verwendung der GPU: 819 USD * 3,18 USD - 1729 USD = 875 USD pro Monat, wenn Sie einen Server mit einer GPU mieten.

Mit der Mietoption sind die Einsparungen also spürbar. Dabei werden Rabatte nicht berücksichtigt. Im russischen IBM-Büro versprechen sie Rabatte für die Anmietung von Ressourcen in der Cloud im Vergleich zu den hier angegebenen Preisen.

Wir sind beim Kauf nicht auf die Optionen eingegangen, weil Hier hängt die Gesamtbetriebskosten stark von der Wahl des Lieferanten, den Servicekosten im Rechenzentrum und anderen Faktoren ab, die denjenigen bekannt sind, die mit Bare Metal arbeiten. Vorläufige Zahlen sprechen jedoch auch für eine GPU-basierte Lösung.

Vergessen Sie auch nicht den Datenverkehr und die Kanalbreite - diese sind in den oben angegebenen Tarifen in einem bestimmten Betrag enthalten. Sie müssen jedoch Optionen für Ihre Aufgaben basierend auf der Anzahl der Threads, der erwarteten Anzahl der Benutzer usw. auswählen.

Skalieren


Die Option mit einer Grafikkarte pro Server erscheint uns kostengünstiger als die Option mit zwei oder mehr Karten. Wie wir sehen können, hat der GPU-Decoder immer mehr als der Encoder geladen, aber selbst er blieb aufgrund von Problemen bei der Verwendung von Kontexten unterlastet. Wenn Sie eine zweite Karte hinzufügen, wird der Decoder noch weniger verwendet, die Encoder können nicht mit voller Kapazität geladen werden, und die gesamte Arbeit an der Codierung muss noch auf die CPU verlagert werden, was für das Geld nicht gerechtfertigt ist. Wir haben die Option dank der Unterstützung von Softlayer auch mit zwei GPUs getestet, aber aufgrund des schwachen wirtschaftlichen Effekts geben wir im Artikel keine Details an.

Um die Last zu skalieren, ist es daher vorzuziehen, neue Server mit einer Grafikkarte hinzuzufügen, als Karten zu vorhandenen Computern hinzuzufügen.

Wenn die Anzahl der eingehenden und ausgehenden Streams für Ihr Projekt relativ gering ist - beispielsweise ein Dutzend HD-Streams mit einer geringen Anzahl von Ausgabeauflösungen und einem relativ geringen Filteraufwand -, ist es zweckmäßiger, einen Server ohne GPU zu verwenden.

Es ist auch erwähnenswert, dass die Menge an RAM für die Aufgabe des Konvertierens von Threads nicht so wichtig ist wie die Verarbeitungsleistung. In einigen Fällen können Sie also auch sparen, indem Sie den Speicherplatz reduzieren.

Fazit


Die vorgestellte Hardwarelösung - eine Kombination aus Tesla M60-CPU und GPU - war perfekt für die Transcodierung von Live-Streams unter hoher Last. Die GPU kümmert sich um die ressourcenintensivsten Vorgänge - das Decodieren der Streams und das Codieren in die höchsten Auflösungen, während mittlere und kleine Auflösungen auf der CPU gut verarbeitet werden.

Wenn einer der Leser Erfahrung hat und die Leistung von Grafikkarten für die Live-Übertragung optimiert, werden wir uns freuen, Ihre Erfahrungen kennenzulernen - schreiben Sie in die Kommentare.

Source: https://habr.com/ru/post/de401539/

More articles:


All Articles