فيما يلي قصة تفصيلية حول كيفية تحميل البطاقة من NVidia بمهام تحويل ترميز الفيديو لبثها. دعنا نظهر أننا جربنا ما حدث ، وأفضل طريقة لاستخدام بطاقات الفيديو للبث عبر الإنترنت.لسنوات عديدة ، كان فريقنا يعمل على تطوير منتجات لمعالجة محتوى الوسائط وتوزيعه عبر الإنترنت.
وصفت هذه المقالة مؤخرًا سبب احتياج مالكي المحتوى إلى مثل هذه الحلول في عصر YouTube الخاص بنا.
أحد منتجاتنا هو خادم وسائط
Nimble Streamer ، وهو برنامج خادم يأخذ البث المباشر والملفات إلى المدخلات ويجعلها في متناول عدد كبير من المشاهدين ، مع السماح لها في نفس الوقت بتحقيق الدخل من المحتوى. هذا هو تطبيق أصلي مكتوب بلغة C ++ ويتم نقله إلى جميع أنظمة التشغيل (Linux و Windows و MacOS) والأنظمة الأساسية (x64 و ARM). منذ البداية ، كان انخفاض استهلاك الموارد والإنتاجية العالية المتطلبات الرئيسية ، ونستطيع تحقيق
نتائج جيدة في ذلك.
في العام الماضي ، قمنا بإصدار إضافة Nimble Streamer -
محول البث المباشر . يسمح لك هذا التطبيق بأخذ دفق إدخال الفيديو و / أو الصوت بتنسيقات مختلفة وإجراء تحويلات مختلفة معهم في الوقت الحقيقي. تتضمن الوظيفة فك التشفير (كل من البرامج والأجهزة) ، وتحويل الفيديو والصوت باستخدام الفلاتر (تغيير الحجم ، والتراكب ، وما إلى ذلك) والتشفير (التشفير) - كل من البرامج والأجهزة.
يتم التحكم في محول الترميز عن طريق خدمة ويب WMSPanel ، ويتم إنشاء نصوص تحويل الشفرة من خلال واجهة السحب والإفلات ، والتي تتيح لك رؤية العملية بصريًا. يمكن تشغيل سيناريوهات مختلفة معًا - من خلال هذا النهج ، من المناسب تشغيل تركيبات الاختبار ، وتحميل الخادم بأي اختلافات.
في مقاطع الفيديو هذه ، يمكنك مشاهدة أمثلة لكيفية عمل الواجهة.
يتم فك تشفير كل دفق مرة واحدة فقط قبل كل التحويلات الإضافية ... هذا يسمح لك بحفظ الموارد على عملية فك تشفير باهظة الثمن ، وسوف يظهر هذا بوضوح أكبر على طول الاختبارات.
إحدى آليات التحويل التي يمكن استخدامها في جهاز التحويل لدينا هي فك تشفير الأجهزة وترميز الفيديو باستخدام GPU من NVidia. تتيح لك بطاقات الجرافيك من أحدث الأجيال تولي بعض المهام النموذجية ، والتي تزيل الحمل من وحدة المعالجة المركزية. إن جهاز التحويل لدينا قادر على العمل مع هذا الجهاز ، والذي يستخدمه عملائنا بنشاط.
في سياق التواصل مع ممثلي مكتب NVidia الروسي ، طُلب منا محاولة ترتيب اختبار الإجهاد المشترك لمحولنا و NVidia GPU من أجل فهم ما سيكون التأثير الاقتصادي لمثل هذا الترادف مقارنةً بتحويل البرامج حصريًا ، دون تسريع الأجهزة. بالإضافة إلى ذلك ، أردت أن أفهم كيفية استخدام GPU على النحو الأمثل ، وإعطاء وصفات جيدة إن أمكن.
نحن بحاجة إلى الحصول بسرعة على الحديد المناسب والوصول إليه ، من أجل دورة تجاربنا. خططنا للقاء بضعة أسابيع. يبقى العثور على مكان الحصول على المعدات. سيكون الخيار الأفضل هو العثور عليها في السحابة والحصول على وصول عن بعد. بعد البحث عن الخيارات ، اتضح أن AWS ليس لديها حتى الآن VM مع وحدة معالجة رسومات من الجيل Maxwell ، وفي سحابة Azure ، من المخطط فقط البدء في توفيرها قريبًا.
1. الحديد من NVidia في سحابة Softlayer ، وإعداد Nimble Streamer
بمساعدة NVidia ، زودتنا IBM بإمكانية الوصول إلى السحابة الخاصة بها ، وهي منصة IBM Bluemix Cloud Platform (المعروفة سابقًا باسم
Softlayer ). هذه شبكة كبيرة من مراكز البيانات الحديثة (حوالي 50 في وقت النشر) حول العالم ، متصلة بشبكة خاصة مشتركة وتوفر مجموعة كبيرة من خدمات البنية التحتية السحابية. جميع مراكز البيانات موحدة وتسمح لك بالاستئجار من واحد إلى مئات الخوادم الافتراضية أو المادية للتكوين المطلوب لعدة ساعات ، بالإضافة إلى الموازنات وأنظمة التخزين والجدران النارية - بشكل عام ، كل ما هو مطلوب لبناء بنية أساسية موثوقة لتكنولوجيا المعلومات لخدمة تكنولوجيا المعلومات المنشورة.
منحنا المكتب التمثيلي الروسي لشركة IBM وصولاً كاملاً إلى
بوابة الخدمة الذاتية لإدارة الخدمات السحابية وتهيئة الخادم الضرورية ، حيث تمكنا من العمل مع تدفقات الإدخال المختلفة وإعدادات محول الترميز الخاص بنا.
حديد
أولاً ، تم منحنا خادمًا فعليًا (المعدن) مع 128 غيغابايت من ذاكرة الوصول العشوائي و 2 xGPU NVidia Tesla M60 وتم تثبيت نظام التشغيل Ubuntu 14.04 مسبقًا. كانت جميع معلمات الخادم وكلمات المرور وإصدارات البرامج الثابتة وتبديلها وعنوان IP المخصص وحالة مكونات الأجهزة مرئية بشكل مباشر في حسابك الشخصي ، مما يسمح لك بإجراء التلاعبات المطلوبة مع الأجهزة المستأجرة ، مما قلل من الحاجة إلى التفاعل مع دعم IBM. أثناء التشغيل التجريبي ، اتضح أننا لم نتمكن من تحميل هذا التكوين على النحو الأمثل ، نظرًا لعدد من القيود في إنشاء السياقات.
أردنا تقليل التكوين. نظرًا لأننا استخدمنا النظام الأساسي السحابي ، فقد كان مطلوبًا من خلال بوابة الخدمة الذاتية طلب تغييرات التكوين. بعد الموافقة ، استغرقت هذه العملية حوالي ساعتين إلى نافذة الخدمة المعتمدة. خلال هذا الوقت ، قام الموظفون الفنيون في مركز بيانات أمستردام بإزالة مكونات إضافية (فتحات ذاكرة الوصول العشوائي و 1 xGPU) من الخادم المقدم لنا في وقت سابق وأعادوها إلى التشغيل. تجدر الإشارة إلى أن هذا الخيار مناسب جدًا للمطورين ، حيث لا توجد حاجة للتعامل مع إعدادات الأجهزة أو إصلاحه أو حتى قضاء بعض الوقت في تثبيت نظام التشغيل. دعني أذكرك أنه في هذه الحالة لا يتم استخدام برنامج Hypervisor لأننا نحتاج إلى ضغط الحد الأقصى من موارد الأجهزة.
بناءً على نتائج بحثنا ، قمنا بتسوية تكوين الخادم التالي:
Dual Intel Xeon E5-2690 v3 (2.60 جيجاهرتز)
24 نواة
64 جيجا بايت رام
1 تيرا بايت ساتا
لدينا معالجان لكل منهما 12 نواة ، وبفضل Hyper Threading ، نحصل على ضعف هذا العدد ، أي ما يقرب من 48 نوى.
في سيناريوهات مع مسرع الرسومات ، تم استخدام بطاقة تعتمد على شريحة GM204 - Tesla M60:
NVIDIA Tesla M60
1xGPU: 2 × Maxwell GM204
الذاكرة: 16 جيجابايت GDDR5
سرعة الساعة: 2.5 جيجا هرتز
NVIDIA CUDA Core: 2 × 2048
عرض نطاق الذاكرة: 2 × 160 جيجابايت / ثانية
ألفت انتباهك إلى حقيقة أنه لم يتم إجراء أي تقارب أو ضبط رقاقة أو رفع تردد التشغيل أو أي سحر آخر على الأجهزة المخفضة - فقط وحدات المعالجة المركزية ووحدات معالجة الرسومات التي لا يتم زيادة سرعة تشغيلها ، وبالنسبة لوحدة معالجة الرسومات ، تم استخدام برنامج التشغيل الرسمي المأخوذ من موقع NVidia فقط. إذا كان شخص ما لديه تجربة مماثلة - شارك في التعليقات.
لذا ، وصلنا. التعرف السريع على واجهة الويب الخاصة بلوحة التحكم (كل شيء بسيط وواضح هناك) ، ثم الوصول إلى الخادم عبر SSH - وهنا نحن في سطر أوامر Ubuntu المعتاد ، ووضع Nimble Streamer ، وتسجيل ترخيص محول جديد وإجراء القليل من إعداد التكوين.
Nimble غاسل محول
تم تكوين Nimble Streamer لإنشاء ذاكرة التخزين المؤقت لسياق GPU مسبقًا. ويرجع ذلك إلى حقيقة أن GPU لديها حد أقصى لعدد من سياقات فك التشفير والترميز التي تم إنشاؤها ، بالإضافة إلى أن إنشاء السياقات أثناء التنقل يمكن أن يستغرق الكثير من الوقت.
يمكن العثور على مزيد من التفاصيل حول مشكلة إنشاء السياقات في القسم المقابل أدناه.
إعدادات Nimbl على مثال السلسلة الأولى من الاختبارات:
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
مزيد من التفاصيل حول هذه الإعدادات مكتوبة
في مقالتنا .
قبل بدء كل سلسلة من الاختبارات ، تم تكوين ذاكرة التخزين المؤقت بشكل منفصل ، مع الأخذ بعين الاعتبار تفاصيل كل مهمة.
إنشاء برامج تحويل الشفرة
استمر العمل الإضافي في خدمة WMSPanel الخاصة بنا ، حيث يتم تكوين البرامج النصية لمحول الشفرة.
كما ذكرنا من قبل ، فإن العمل يمر عبر واجهة الويب ، كل شيء واضح للغاية ومريح. لقد أنشأنا عددًا من السيناريوهات التي تجمع بين خيارات التحويل المختلفة (CPU / GPU) وخيارات الدقة المختلفة ومعلمات التشفير المختلفة (CPU / GPU والملف الشخصي ومعدل البت وما إلى ذلك).
يمكن تشغيل مجموعات من السيناريوهات في وقت واحد ، مما يجعل من الممكن إدخال مجموعات مختلفة من الاختبارات ، وزيادة الحمل بترتيب مختلف ، وتغييره اعتمادًا على الموقف. ما عليك سوى اختيار السيناريوهات الضرورية وإيقافها أو استئنافها.
إليك مجموعة من السيناريوهات:
فيما يلي مثال لأحد السيناريوهات:
يبدو وحدة فك ترميز GPU كما يلي:
نطبق مرشح حجم الصورة:
وهنا هو التشفير لمتغير GPU:
بشكل عام ، يمكن
رؤية تشغيل واجهة محول الترميز
في مقاطع الفيديو هذه .
2. تيارات الترميز FullHD 1080p
بادئ ذي بدء ، اختبرنا السيناريو بأحمال أعلى من أجل معرفة حدود قدرات الحديد. في الوقت الحالي ، فإن "أثقل" القرارات المستخدمة في الممارسة هي FullHD 1080p.
لإنشاء مجموعات البث المباشر الأصلية ، تم التقاط ملف بتنسيق
FullHD (1920 * 1080) بتنسيق
H.264 عالي المستوى . المحتوى نفسه عبارة عن جولة بالفيديو في المدينة ، أي هذا الفيديو بمتوسط معدل تغيير الصورة. لا توجد إطارات ثابتة أحادية اللون يمكن أن تسهل عمل المحول ، ولكن لا يوجد تغيير سريع جدًا للأنواع والألوان. في كلمة واحدة - حمولة نموذجية إلى حد ما.
تم إدخال
36 تيارات متطابقة لمدخلات Nimble Streamer ، والتي تم استخدامها بعد ذلك في محول الترميز في سيناريوهات مختلفة.
يتم استخدام سيناريو التحويل بشكل نموذجي - الدفق الوارد هو ملف تعريف عالي
1080p ،
720p ، 480p ، 360p ملف رئيسي مصنوع منه
، ثم تدفقات
ملف تعريف خط الأساس: 240p ، 160p . في المجمل ، يوجد دفق واحد عند الإدخال و 5 عند الإخراج. عادة ، يتم أيضًا تمرير (نقل بدون تغييرات) الدفق الأصلي بحيث يمكن للعارض تحديد 1080 بكسل نفسه عند العرض. لم نقم بإضافته إلى البرنامج النصي ، لأنه لا يستخدم التحويل - هناك نقل مباشر للبيانات من الإدخال إلى الإخراج. تم تحسين هذا السيناريو في Nimble وفي الظروف الحقيقية سيزيد استهلاك الذاكرة قليلاً نسبيًا.
الصوت في التدفقات المولدة - لا. لن تؤدي إضافة الصوت إلى النص البرمجي إلى تحميلات كبيرة على وحدة المعالجة المركزية ، ولكن بالنسبة لنقاء التجربة ، استبعدنا الصوت.
اختبار وحدة المعالجة المركزية ، لا يوجد GPU
للبدء ، أطلقنا برامج تحويل الشفرة دون استخدام GPU ، مع تحديد وحدة فك ترميز البرامج وبرامج التشفير في البرامج النصية.
ونتيجة لذلك ، كان من الممكن معالجة 16 فقط من تدفقات المدخلات مع إصدار 80 تدفق من جميع أذونات الخروج.
تحميل وحدة المعالجة المركزية - 4600٪ ، أي وشارك 46 النوى. استهلاك ذاكرة الوصول العشوائي - حوالي 15 جيجابايت.
اختبار CPU + GPU
يتم تكوين ذاكرة التخزين المؤقت للسياق عند بدء التشغيل على أنها 0: 30: 15.1: 30: 15 - أي 30 سياقًا للترميز و 15 لفك التشفير لكل وحدة معالجة رسومات.
دعني أذكرك أنه في وحدة معالجة الرسومات لدينا مركزان ، مما يسمح لنا بموازنة المهام - وهذا مفيد لنا.
تم الحصول على الحمل الأقصى مع تكوين التدفق التالي.
وحدة فك ترميز الإدخال GPU0 و GPU1 - 15 تيارات. وبالتالي نحصل على 30 تيارات مفككة ، جاهزة للاستخدام مرة أخرى. يتم فك ترميز كل دفق مرة واحدة فقط ، بغض النظر عن عدد السيناريوهات التي سيتم استخدامها في المستقبل.
تم تغذية المشفرين GPU0 و GPU1 بـ 15 دفقًا لكل منهما للحصول على 720 بكسل ، أي تحولت 30 تيارات 720p عند الخروج.
أيضًا ، قام كل من مشفري GPU0 و GPU1 بتوفير 15 دفقًا لـ 480p - وتم أيضًا إخراج 30 دفقًا بدقة 480p.
منذ استنفاد سياقات التشفير ، تم تعيين ترميز الأذونات المتبقية على وحدة المعالجة المركزية. اتضح ما يلي:
- 30 بثًا 360 بكسل
- 30 تيارات 240p
- 30 تيارات 160p
اتضح أن الحمل هو 2600٪ CPU ، 75٪ decoder ، 32٪ encoder. بعد ذلك ، تم تحميل وحدة المعالجة المركزية بـ 6 تدفقات لفك التشفير ، لكل 5 قرارات متشابهة تم تكوينها ، ليصبح المجموع 30 سلسلة لكل ناتج.
في المجموع ، تم استلام
36 تيارات عند المدخلات ، تم إصدار 180 عند الإخراج . يتم إصلاح الحمل النهائي على النحو التالي:
4400٪ وحدة المعالجة المركزية ، وحدة فك ترميز 75٪ بطاقة ، ترميز بطاقة 32٪ ، ذاكرة وصول عشوائي 30 جيجابايت .
بعض التفاصيل
قررنا التحقق من الخيار الذي نعالج فيه أصعب المهام على وحدة معالجة الرسومات - فك تشفير 1080 وترميز 720 و 480 ، والسماح بمعالجة الباقي عبر وحدة المعالجة المركزية.
أولاً ، تحققنا من حد وحدة فك الترميز. باستخدام 22 خيطًا ، تأثر فك التشفير بمشكلة السياقات ، ببساطة تعذر إنشاؤها. انخفض إلى 21 - تم إنشاء السياقات ، ولكن الحمل أصبح 100 ٪ وبدأت ملاحظة القطع الأثرية في الدفق. توقفنا عند 20 تيارات - نقوم بفك تشفير 20 تيارات ، ترميز عند 160p - كل شيء يعمل بشكل جيد.
بالإضافة إلى ذلك ، اتضح تجريبيًا أن هذه البطاقة التي تحتوي على ذاكرة وصول عشوائي سعتها 16 جيجابايت يمكن أن تعمل بثقة مع 47 سياقًا - ولا يوجد فرق ، فهذه هي سياقات برنامج التشفير أو فك التشفير. أكرر - هذا يتعلق بشكل خاص بوحدة معالجة رسومات Tesla M60 هذه ، على بطاقات أخرى قد يكون هذا الرقم مختلفًا. نعتقد أنه إذا كانت البطاقة تحتوي على 24 غيغابايت من ذاكرة الوصول العشوائي ، فقد يكون عدد السياقات مختلفًا ، ولكن هذا يجب اختباره.
ونتيجة لذلك ، اخترنا صيغة إنشاء ذاكرة التخزين المؤقت "15 سياقًا من وحدة فك الترميز و 30 سياقًا من برنامج التشفير" - والتي توفر 30 دفقًا للإدخال ويسمح لكل منها بإنشاء إذنين. لذلك تم إطلاق الدقة الأعلى - 720 و 480 - على وحدة معالجة الرسومات ، وتم إرسال الباقي - 360 و 240 و 160 - إلى وحدة المعالجة المركزية. وبما أن وحدة المعالجة المركزية كانت لا تزال مجانية بعد ذلك ، فقد "أنهينا" النوى الحرة بخيوط جديدة ، تاركين 4 نوى للمهام النفعية.
3. تحويل تيارات ترميز HD 720p
سيناريو الحمل النموذجي يتم الآن إنشاء معظم المحتوى بدقة عالية. حتى SuperBowl LI الأخيرة - العرض الأعلى تقييمًا في السوق الأمريكية - تم
بثه بجودة HD ، تاركًا FullHD للمستقبل.
لإنشاء تدفقات المصدر ، تم التقاط ملف
بدقة عالية (1280 * 720) في
ملف تعريف عالي . المحتوى هو سلسلة "الزوجة الصالحة" لمهندسنا ، أي هذا الفيديو بمتوسط معدل تغيير الصورة.
عند مدخل Nimble Streamer ، تم تغذية 70 تيارات متطابقة ، والتي تم استخدامها بعد ذلك في محول الترميز في سيناريوهات مختلفة.
يتم استخدام سيناريو التحويل التالي - الدفق الوارد هو
720p عالي المستوى ،
480p ، 360p رئيسي ثم ثم
240p ، 160p تدفقات ملف تعريف
أساسية مصنوعة منه. الإجمالي ، عند الإدخال 1 ، عند الإخراج 4. لم يتم تمرير التمرير الأصلي ، كما في السيناريو السابق. الصوت في التدفقات المولدة ليس كذلك.
اختبار وحدة المعالجة المركزية ، لا يوجد GPU
كما في القسم السابق ، جربنا تيارات التحويل فقط على وحدة المعالجة المركزية. ونتيجة لذلك ، كان من الممكن معالجة 22 فقط من تدفقات المدخلات مع إصدار 88 تدفق من جميع أذونات الخروج. تحميل وحدة المعالجة المركزية - 4700٪ ، أي تشارك 47 نواة. استهلاك ذاكرة الوصول العشوائي - حوالي 20 جيجابايت.
اختبار CPU + GPU
يتم تكوين ذاكرة التخزين المؤقت للسياق عند بدء التشغيل على أنها 0: 23: 23.1: 23: 23 - أي 23 سياقًا للترميز و 23 سياقًا لفك التشفير لكل وحدة معالجة رسومات.
باستخدام GPU ، تم فك ترميز 46 دفق 720 بكسل. هناك ، على وحدة معالجة الرسوميات ، تم تشفير 46 تيارات بدقة 480 بكسل. بعد ذلك ، تم إجراء ترميز 360 بكسل و 240 بكسل و 160 بكسل على وحدة المعالجة المركزية - 46 دفقًا لكل منها.
تحميل ثابت لوحدة المعالجة المركزية 2100٪ ، 61٪ من وحدة فك الترميز ، 16٪ من وحدة التشفير.
بالإضافة إلى ذلك ، تم إطلاق تشفير وفك تشفير 24 سلسلة إلى وحدة المعالجة المركزية لكل سلسلة واحدة - 4 مخرجات ، كما هو الحال مع وحدة معالجة الرسومات.
إجمالاً ،
تم إدخال 70 تيارات ، تم إنتاج 280 تيارات .
الحمل:
4600٪ ، 61٪ من وحدة فك الترميز ، 16٪ من وحدة الترميز ، 30 غيغابايت من ذاكرة الوصول العشوائي .
بالنسبة للاختبار السابق ، ربما توفر وحدة معالجة رسومات RAM أكبر سياقات ويمكننا التعامل مع المزيد من سلاسل المحادثات. ولكن هذا من الناحية النظرية فقط ، فمن الضروري التحقق.
4. مشكلة إنشاء سياقات في NVidia GPU
بضع كلمات حول المشكلة التي لم تسمح لنا بمعالجة المزيد من سلاسل الرسائل على GPU.
في نهاية العام الماضي ، أجرينا اختبارات مع فريق NVidia بعدة بطاقات. عند العمل مع وحدات معالجة رسومات متعددة ، اتضح أن إنشاء السياقات يبطئ إلى حد كبير الخادم - إنشاء كل سياق جديد يستغرق المزيد والمزيد من الوقت من الخريطة. إذا تم إنشاء السياق الأول بترتيب 300 مللي ثانية ، فإن كل سياق لاحق أضاف 200-300 مللي ثانية بالفعل في السياقات العشرة الثالثة ، واستغرق إنشاء سياق جديد 3-4 ثوانٍ لكل منهما. عندما يُنشئ المستخدم نصًا برمجيًا للتحويل ، يُفترض أنه يبدأ العمل على الفور وبدون تأخير ، وهذا الظرف الجديد يلغي كل المزايا في سرعة Nimbl ويعطي تأخيرات في إنشاء السياقات التي أدت إلى تأخيرات في بدء الترميز.
في البداية ، وقع الشك على Nimble ، ولكن بعد ذلك أجرينا اختبارات باستخدام ffmpeg ، والتي توفرها NVidia نفسها للعملاء وتبين أن النتيجة هي نفسها تمامًا - تقضي GPU المزيد والمزيد من الوقت في إنشاء كل سياق جديد. في الحالات التي يكون فيها الخادم بالفعل في تحويل الترميز وتحتاج إلى بدء سلاسل رسائل جديدة للمعالجة ، يؤثر ذلك على الأداء العام ويجعل الخادم ببساطة غير قابل للاستخدام.
تم وصف المشكلة بالتفصيل من قبل فريق NVidia ، ولكن حتى الآن لم يتم توفير حل بدوام كامل. لذلك ، قمنا حتى الآن بتطبيق آلية التخزين المؤقت للسياق في خادمنا ، مع إنشاء أولي للسياقات في بداية الخادم. أدى ذلك إلى حل المشكلة من وجهة نظر عمل المستخدم النهائي ، ولكن بداية Nimbl قد تستغرق بعض الوقت. يتم وصف إعداد Nimbl للعمل الفعال مع السياقات
في مدونتنا .
بالإضافة إلى ذلك ، ليس من السهل إنشاء السياقات. مع وجود عدد كبير من السياقات عند تضمين أي نص برمجي للتحويل ، تبدأ NVENC API في إلقاء الأخطاء: "فشل استدعاء API لأنه لم يتمكن من تخصيص ذاكرة كافية لتنفيذ العملية المطلوبة."
من الناحية التجريبية ، اتضح أن وحدة معالجة رسومات واحدة يمكن أن تبدأ وتعمل بثقة مع 47 سياقًا - ولا يوجد فرق ، فهذه هي سياقات المشفر أو وحدة فك الترميز. كان هناك افتراض بأن هذا يرجع إلى حجم الذاكرة على GPU. الآن هناك 16 غيغابايت ، إذا وضعت بطاقة بسعة 24 غيغابايت ، فمن المحتمل أنه يمكن عمل المزيد من السياقات. لكن هذه ليست سوى نظرية ، من الضروري التحقق ، كما ذكرنا سابقًا. البيانات التي تم الحصول عليها صالحة لنموذج GPU معين ، ويجب اختبار البطاقات الأخرى بشكل منفصل.
إنه القيد على عدد السياقات التي تضع العقبة الرئيسية عند العمل بأحمال كبيرة.
5. الاستنتاجات
لذلك ، كان الغرض من الاختبار هو دراسة فعالية GPU لمجموعة المهام المحددة وتطوير وصفات لاستخدامها بشكل صحيح. ما هي النتيجة؟
التأثير الاقتصادي
أعلاه ، رأينا كيف يختلف عدد سلاسل العمليات التي يمكن معالجتها على وحدة المعالجة المركزية وعلى وحدة المعالجة المركزية CPU + GPU. دعونا نرى ما يعنيه هذا من حيث المال. كأساس نأخذ كل نفس Softlayer وأسعار تأجير المعدات الخاصة بهم.
- سيكلف التكوين بدون GPU $ 819 شهريًا . هنا يمكنك التقاط سيارة.
- سيكلف التكوين مع GPU $ 1729 شهريًا لمركز البيانات في أمستردام ، ويمكن الاطلاع على الأسعار هنا . عند استخدام GPU ، يرتفع سعر تأجير الخادم قليلاً ، حيث يتم استخدام عامل شكل الحالة الأكبر المكون من وحدتين. من المحتمل أن يكون التأثير الاقتصادي أعلى عند شراء المعدات (ولكن هذا يتطلب تحليلًا جادًا لـ TCO ، مع مراعاة التحديث المستمر لخط NVidia GPU).
الآن دعونا نرى نتائج الاختبار:للحصول على FullHD 1080p- وحدة المعالجة المركزية بدون وحدة معالجة الرسومات: 16 سلسلة لكل إدخال + 80 سلسلة لكل إخراج
- CPU + GPU: 36 سلسلة لكل إدخال + 180 لكل ناتج
مزايا GPU: 2.25x.فوائد استخدام GPU: 819 دولارًا أمريكيًا * 2.25 دولارًا أمريكيًا - 1729 دولارًا أمريكيًا = 113 دولارًا أمريكيًا شهريًا عند استئجار خادم واحد باستخدام GPU.لدقة 720 بكسل- وحدة المعالجة المركزية بدون وحدة معالجة الرسومات: 22 سلسلة لكل إدخال + 88 سلسلة لكل إخراج
- CPU + GPU: 70 سلسلة لكل إدخال + 280 لكل ناتج
مزايا GPU: 3.18x.فوائد استخدام GPU: 819 دولارًا أمريكيًا * 3.18 دولارًا أمريكيًا - 1729 دولارًا أمريكيًا = 875 دولارًا أمريكيًا شهريًا عند استئجار خادم واحد باستخدام وحدة معالجة رسوماتأي ، مع خيار التأجير ، تكون المدخرات ملحوظة تمامًا. هذا لا يأخذ في الاعتبار الخصومات - في المكتب الروسي لشركة IBM يعدون بخصومات على تأجير الموارد في السحابة مقارنة بالأسعار المعروضة هنا.لم ندخل في خيارات الشراء لأن هنا يعتمد TCO بشدة على اختيار المورد وتكلفة الخدمة في مركز البيانات وعوامل أخرى مألوفة لأولئك الذين يعملون مع المعدن. ومع ذلك ، فإن الأرقام الأولية تتحدث أيضًا لصالح حل قائم على GPU.أيضًا ، لا تنسى حركة المرور وعرض القناة - يتم تضمينها في مبلغ معين في التعريفات المقدمة أعلاه ، ولكنك ستحتاج إلى تحديد خيارات لمهامك استنادًا إلى عدد المواضيع ، العدد المتوقع للمستخدمين ، إلخ.تحجيم
يبدو لنا الخيار الذي يحتوي على بطاقة رسومية واحدة لكل خادم أنه أكثر فعالية من حيث التكلفة من الخيار مع بطاقتين أو أكثر. كما نرى ، فإن وحدة فك ترميز GPU يتم تحميلها دائمًا أكثر من برنامج التشفير ، ولكن حتى يتم الاحتفاظ بها تحت التحميل بسبب مشاكل في استخدام السياقات. إذا أضفت بطاقة ثانية ، فسيتم استخدام أداة فك التشفير بشكل أقل ، ولن نتمكن من تحميل برامج التشفير بكامل طاقتها ، وستظل جميع أعمال التشفير بحاجة إلى التحويل إلى وحدة المعالجة المركزية ، والتي لن يتم تبريرها للحصول على المال. لقد اختبرنا أيضًا الخيار باستخدام وحدتي GPU بفضل دعم Softlayer ، ولكن نظرًا للتأثير الاقتصادي الضعيف ، فإننا لا نقدم تفاصيل في المقالة.وفقًا لذلك ، لقياس الحمل ، يفضل إضافة خوادم جديدة ببطاقة رسومية واحدة من إضافة بطاقات إلى الأجهزة الموجودة.إذا كان عدد التدفقات الواردة والصادرة لمشروعك صغيرًا نسبيًا - على سبيل المثال ، عشرات التدفقات عالية الدقة مع عدد قليل من أذونات الإخراج ، مع كمية صغيرة نسبيًا من التصفية ، فسيكون من الأفضل استخدام خادم بدون وحدة معالجة رسومات.من الجدير بالذكر أيضًا أن مقدار ذاكرة الوصول العشوائي لمهمة تحويل الخيوط ليست بنفس أهمية قوة المعالجة. لذلك ، في بعض الحالات ، يمكنك أيضًا الحفظ عن طريق تقليل حجم الذاكرة.الخلاصة
كان حل الأجهزة المقدم - وهو مزيج من وحدة المعالجة المركزية Tesla M60 ووحدة معالجة الرسومات - مثاليًا لتحويل ترميز البث المباشر تحت الأحمال الثقيلة. تعتني وحدة معالجة الرسومات (GPU) بالعمليات الأكثر استخدامًا للموارد - فك تشفير التدفقات وترميزها إلى أعلى درجات الدقة ، بينما تتم معالجة درجات الدقة المتوسطة والصغيرة بشكل جيد على وحدة المعالجة المركزية.إذا كان أحد القراء لديه خبرة وتحسين أداء البطاقات الرسومية للبث المباشر ، فسوف نكون سعداء للتعرف على تجربتك - اكتب في التعليقات.