Ниже подробный рассказ о том, как мы нагружали карту NVidia задачами перекодирования видео для потоковой передачи.
Мы покажем вам, что мы пробовали, что сработало и как лучше всего использовать видеокарты для онлайн-трансляций.
Наша команда уже несколько лет занимается разработкой продуктов для обработки и распространения медиаконтента в сети.
В этой статье Не так давно объяснялось, зачем владельцам контента могут понадобиться подобные решения в наш век YouTube. Один из наших продуктов — медиасервер Шустрый стример — это серверное программное обеспечение, которое принимает прямые трансляции и файлы в качестве входных данных и делает их доступными большому количеству зрителей, одновременно позволяя вам монетизировать контент. Это нативное приложение, написанное на C++ и портированное на все популярные ОС (Linux, Windows, MacOS) и платформы (x64, ARM).
С самого начала главными требованиями были низкое потребление ресурсов и высокая производительность, и нам удается этого добиться.
В прошлом году мы выпустили дополнение к Nimble Streamer — транскодер прямого эфира .
Это приложение позволяет вам принимать на вход видео и/или аудиопотоки разных форматов и выполнять с ними различные преобразования в реальном времени.
Функционал включает в себя декодирование (как программное, так и аппаратное), преобразование видео и аудио с помощью фильтров (изменение размера, наложение и т. д.) и кодирование (кодирование) — как программное, так и аппаратное.
Управление транскодером осуществляется через веб-сервис WMSPanel, скрипты транскодирования создаются через интерфейс перетаскивания, что позволяет наглядно видеть процесс.
Разные сценарии можно запускать вместе — при таком подходе удобно запускать комбинации тестов, нагружая сервер в любом варианте.
В этих видео Вы можете увидеть примеры работы интерфейса.
Декодирование каждого потока производится только один раз перед всеми дальнейшими преобразованиями.
Это позволяет сэкономить ресурсы на дорогостоящей операции декодирования, это будет хорошо видно далее в тестах.
Одним из механизмов преобразования, который можно использовать в нашем транскодере, является аппаратное декодирование и кодирование видео с использованием графических процессоров NVidia. Последние поколения видеокарт позволяют взять на себя часть типовых задач, что снижает нагрузку на процессор.
Наш транскодер может работать с этим оборудованием, которым активно пользуются наши клиенты.
В ходе беседы с представителями российского офиса NVidia нам предложили попробовать организовать совместное стресс-тестирование нашего транскодера и графического процессора NVidia, чтобы понять, какой экономический эффект от такого тандема будет по сравнению с чисто программным транскодированием, без аппаратного обеспечения.
ускорение.
Кроме того, мне хотелось понять, как наиболее оптимально использовать графический процессор, и по возможности дать хорошие рецепты.
Нам нужно было быстро получить подходящее оборудование и доступ к нему для нашей серии экспериментов.
Мы планировали сделать это за пару недель.
Остается только найти, где взять оборудование.
Лучшим вариантом будет найти их в облаке и получить к ним удаленный доступ.
Поискав варианты, выяснилось, что у AWS пока нет ВМ с графическими процессорами поколения Maxwell, а в облаке Azure их планируется начать предоставлять только в ближайшее время.
1. Оборудование от NVidia в облаке Softlayer, настройка Nimble Streamer
При содействии NVidia компания IBM предоставила нам доступ к своему облаку — IBM Bluemix Cloud Platform (ранее называвшаяся Мягкий слой ).Это большая сеть современных дата-центров (около 50 на момент публикации) по всему миру, связанных общей частной сетью и предоставляющих большой выбор услуг облачной инфраструктуры.
Все дата-центры унифицированы и позволяют арендовать от одного до сотни виртуальных или физических серверов необходимой конфигурации в течение нескольких часов, а также балансировщики, системы хранения, межсетевые экраны — в общем, все, что требуется для построения надежной ИТ.
инфраструктура для развернутой ИТ-службы.
Российское представительство IBM предоставило нам полный доступ к портал самообслуживания для управления облачными сервисами и до нужной конфигурации сервера, где мы могли работать с разными входными потоками и настройками нашего транскодера.
Железо
Сначала нам предоставили физический сервер (голый) с 128 ГБ ОЗУ и 2xGPU NVidia Tesla M60 и предустановленной ОС Ubuntu 14.04. Все параметры сервера, пароли, версии прошивки, его коммутация, выделенные IP-адреса и состояние аппаратных компонентов были видны непосредственно в личном кабинете, что позволяло производить необходимые манипуляции с арендованным оборудованием, что свело к минимуму необходимость взаимодействия со службой поддержки IBM. .В ходе тестов выяснилось, что нам не удалось оптимально загрузить данную конфигурацию из-за ряда ограничений при генерации контекстов.
Мы хотели уменьшить конфигурацию.
Поскольку мы использовали облачную платформу, нам нужно было запросить изменения конфигурации через портал самообслуживания.
После одобрения эта операция заняла примерно 2 часа в пределах утвержденного окна обслуживания.
За это время технические сотрудники дата-центра Амстердама удалили ненужные компоненты (планки оперативной памяти и 1xGPU) с ранее предоставленного нам сервера и вернули его в работу.
Следует отметить, что этот вариант очень удобен для разработчиков, так как нет необходимости самостоятельно разбираться с настройками оборудования, или ремонтировать его, или даже тратить время на установку ОС.
Напомню, что в данном случае гипервизор не используется, поскольку нам необходимо выжать максимум из аппаратных ресурсов.
По результатам нашего исследования мы остановились на следующей конфигурации сервера:
Двойной процессор Intel Xeon E5-2690 v3 (2,60 ГГц) 24 ядра 64 ГБ ОЗУ 1 ТБ SATAУ нас 2 процессора по 12 ядер каждый, а благодаря Hyper threading мы получаем вдвое больше, т.е.
практически 48 ядер.
В сценариях с графическим ускорителем использовалась карта на базе чипа GM204 — Tesla M60:
NVIDIA Тесла М60 1xGPU: 2xMaxwell GM204 Память: 16 ГБ GDDR5. Тактовая частота: 2,5 ГГц Ядра NVIDIA CUDA: 2 x 2048 Пропускная способность памяти: 2 x 160 ГБ/сек.Обратите внимание, что на данном оборудовании не проводилось никаких аффинити, чип-тюнинга, разгона и прочей магии - только неразогнанные процессоры и графические процессоры, а для графического процессора использовались только официальные драйвера, взятые с сайта NVidia. Если у кого-то есть подобный опыт, поделитесь им в комментариях.
Итак, мы получили доступ.
Быстрое знакомство с веб-интерфейсом панели управления (там все просто и понятно), затем доступ к серверу по SSH — и вот мы уже в обычной командной строке Ubuntu, устанавливаем Nimble Streamer, регистрируем свежую лицензию транскодера и делаем небольшая корректировка конфигурации.
Шустрый стример-транскодер
Nimble Streamer был настроен для предварительного создания кэша контекста графического процессора.Это связано с тем, что у графического процессора есть ограничение на максимальное количество контекстов декодирования и кодирования, которые он может создать, а кроме того, создание контекстов на лету может занять слишком много времени.
Более подробно о проблеме создания контекстов можно прочитать в соответствующем разделе ниже.
Шустрые настройки на примере первой серии тестов:
nvenc_context_cache_enable = правда nvenc_context_create_lock = правда nvenc_context_cache_init = 0:30:15,1:30:15 nvenc_context_reuse_enable = правдаПодробнее об этих настройках написано в нашей статье .
Перед запуском каждой серии тестов кэш настраивался отдельно с учетом специфики каждой задачи.
Создание скриптов транскодирования
Далее работа происходила в нашем сервисе WMSPanel, где настраиваются скрипты транскодера.Как уже говорилось, работа ведется через веб-интерфейс, все предельно понятно и удобно.
Мы создали ряд сценариев, сочетающих разные параметры транскодирования (ЦП/ГП), разные параметры разрешения и разные параметры кодирования (ЦП/ГП, профиль, битрейт и т. д.).
Наборы сценариев могут запускаться одновременно, что позволяет вводить разные комбинации тестов, увеличивать нагрузку в разном порядке и менять ее в зависимости от ситуации.
Мы просто выбираем нужные сценарии и останавливаем или возобновляем их.
Вот как выглядит набор скриптов: 
Вот пример одного из сценариев: 
Декодер графического процессора выглядит следующим образом: 
Примените фильтр размера изображения: 
А вот кодировщик для версии GPU: 
В целом работу интерфейса транскодера можно посмотри на эти видео .
2. Транскодирование потоков FullHD 1080p.
Для начала мы протестировали сценарий с самыми большими нагрузками, чтобы выяснить пределы возможностей оборудования.На данный момент самое тяжелое разрешение, используемое на практике, — FullHD 1080p. Для создания первоначальных прямых трансляций был взят файл в формате Full HD (1920*1080) в высокий профиль H.264 .
Сам контент представляет собой видеоэкскурсию по городу, т.е.
это видео средней интенсивности.
Здесь нет статичных одноцветных кадров, которые могли бы облегчить работу транскодера, но и нет слишком быстрых изменений видов и цветов.
Одним словом – довольно типичная нагрузка.
На входе в Шустрый Стример обслуживали 36 одинаковых потоков , которые затем использовались в транскодере в разных сценариях.
Используемый скрипт транскодирования стандартный – входящий поток 1080p высокий профиль, они сделаны из него Основной профиль 720p, 480p, 360p и дальнейшие потоки базовый профиль: 240p, 160p .
Итого на входе 1 поток, а на выходе 5. Обычно также делается сквозная передача (передача без изменений) исходного потока, чтобы зритель мог выбрать при просмотре актуальное разрешение 1080p. Мы не стали добавлять его в скрипт, потому что… он не использует транскодирование — происходит прямая передача данных с входа на выход. Этот сценарий оптимизирован в Nimble и в реальных условиях сравнительно немного увеличит потребление памяти.
В генерируемых потоках нет звука.
Добавление звука в скрипты не даст существенной нагрузки на процессор, но для чистоты эксперимента мы исключили звук.
Тест на процессоре, без графического процессора
Для начала мы запустили скрипты транскодирования без использования GPU, указав в скриптах программный декодер и кодировщик.В результате удалось обработать только 16 потоков на вход при выдаче 80 потокам всех разрешений на выход. Загрузка ЦП — 4600%, т.е.
использовалось 46 ядер.
Потребление оперативной памяти составляет около 15 ГБ.
Тест процессора + графического процессора
Кэш контекста при запуске настроен как 0:30:15,1:30:15 — т.е.30 контекстов для кодирования, 15 для декодирования, для каждого графического процессора.
Напомню, что у нас два ядра на GPU, что позволяет распараллеливать задачи — это нам пригодится.
Максимальная нагрузка была получена при следующей конфигурации потока.
Входы декодеров GPU0 и GPU1 имеют по 15 потоков каждый.
Таким образом мы получаем 30 декодированных потоков, готовых к дальнейшему использованию.
Каждый поток декодируется только один раз, независимо от того, в скольких сценариях он впоследствии используется.
На энкодеры GPU0 и GPU1 было подано по 15 потоков для получения 720p, т.е.
получилось 30 потоков 720p на выходе.
Кроме того, кодерам GPU0 и GPU1 было выделено по 15 потоков для 480p — и это также привело к 30 потокам 480p на выходе.
Поскольку контексты кодировщика были исчерпаны, кодирование оставшихся разрешений было передано в ЦП.
Результат следующий: 30 потоков 360p 30 потоков 240p 30 потоков 160p Загрузка оказалась 2600% ЦП, 75% декодер, 32% энкодер.
Затем в ЦП было загружено 6 потоков декодирования, каждый из которых имел по 5 одинаковых разрешений, всего по 30 потоков на выход. Всего получено 36 потоков на вход, 180 потоков на выход .
Окончательная нагрузка записывается следующим образом: 4400% ЦП, 75% карта декодера, 32% карта кодера, 30 ГБ ОЗУ .
Некоторые подробности
Мы решили протестировать вариант, при котором самые сложные задачи мы обрабатываем на GPU — декодирование 1080 и кодирование 720 и 480, а остальное пусть обрабатывается через CPU. Сначала мы проверили рабочий предел декодера.При 22 потоках на декодирование возникла проблема с контекстами; их просто невозможно было создать.
Уменьшил до 21 - контексты создались, но нагрузка стала 100% и в потоке стали наблюдаться артефакты.
Остановились на 20 потоках - декодируем 20 потоков, кодируем на 160p - все работает нормально.
Кроме того, экспериментально выяснилось, что эта карта с 16ГБ ОЗУ на борту может уверенно работать с 47 контекстами — и не имеет значения, контексты это кодировщики или декодеры.
Повторяю — речь идет конкретно об этом графическом процессоре Tesla M60; на других картах это число может быть другим.
Мы считаем, что если бы на карте было 24 ГБ ОЗУ, количество контекстов могло бы быть другим, но это нужно тестировать.
В результате мы выбрали формулу создания кэша «15 контекстов декодера и 30 контекстов кодера» — которая дает 30 входных потоков и позволяет создавать по 2 разрешения для каждого.
Таким образом, верхние разрешения — 720 и 480 — кодировались на GPU, а остальные — 360, 240 и 160 — отправлялись на CPU. А поскольку ЦП после этого все еще был свободен, мы «добили» свободные ядра новыми потоками, оставив 4 ядра для утилитарных задач.
3. Транскодирование потоков HD 720p.
Сценарий с типовой нагрузкой, т.к.большая часть контента сейчас создается в HD. Даже недавний SuperBowl LI, шоу с самым высоким рейтингом на рынке США, передается в HD , оставив FullHD на будущее.
Для генерации исходных потоков был взят файл в формате HD (1280*720) в Высокий профиль .
По содержанию — любимый эпизод нашего инженера «Хорошая жена», т. е.
это видео средней интенсивности.
В Nimble Streamer было введено 70 одинаковых потоков, которые затем использовались в транскодере в различных сценариях.
Используемый сценарий транскодирования следующий: входящий поток 720p высокий профиль, они сделаны из него Основной профиль 480p, 360p и дальнейшие потоки Базовое разрешение 240p, 160p профиль.
Итого на входе 1 поток, на выходе 4. Сквозная передача исходного потока, как и в предыдущем сценарии, не выполнялась.
В генерируемых потоках также нет звука.
Тест на процессоре, без графического процессора
Как и в предыдущем разделе, мы попробовали перекодировать потоки только на процессоре.В результате удалось обработать только 22 потока на вход при выдаче 88 потокам всех разрешений на выход. Загрузка ЦП — 4700%, т.е.
использовалось 47 ядер.
Потребление оперативной памяти составляет около 20 ГБ.
Тест процессора + графического процессора
Кэш контекстов при запуске настроен как 0:23:23,1:23:23 — т.е.23 контекста на кодирование, 23 на декодирование для каждого графического процессора.
С помощью графического процессора было декодировано 46 потоков 720p. Там кодирование 46 потоков 480p осуществлялось на GPU. Далее на ЦП было произведено кодирование 360p, 240p и 160p — по 46 потоков каждый.
Зарегистрированная загрузка составила 2100% ЦП, 61% декодера, 16% кодера.
Кроме того, было запущено кодирование и декодирование 24 потоков на CPU, на каждый 1 поток приходилось 4 выхода, как и на GPU. Всего получилось 70 входных потоков, 280 выходных потоков .
Нагрузка: 4600%, декодер 61%, кодер 16%, 30 ГБ ОЗУ .
Как и в предыдущем тесте, возможно, больший объем оперативной памяти графического процессора обеспечит большее количество контекстов, и мы сможем обрабатывать больше потоков.
Но это только в теории, это надо проверять.
4. Проблема с созданием контекстов в графическом процессоре NVidia.
Несколько слов о проблеме, которая не позволяла нам обрабатывать больше потоков на GPU. В конце прошлого года мы вместе с командой NVidia провели тестирование нескольких карт. При работе с несколькими GPU выяснилось, что создание контекстов сильно тормозило работу сервера — создание каждого нового контекста отнимало у карты всё больше времени.Если первый контекст создавался примерно за 300 мс, то каждый последующий добавлял по 200-300 мс, а уже в третьем десятке контекстов создание нового занимало по 3-4 секунды каждый.
Когда скрипт транскодирования создается пользователем, ожидается, что он начнет работать сразу и без задержек, и это новое обстоятельство свело на нет все преимущества в скорости Nimble и внесло задержки в создании контекстов, что привело к задержкам начала кодирования.
Сначала подозрение пало на Nimble, но потом мы провели тесты с использованием ffmpeg, который предоставляет клиентам сама NVidia, и результат оказался абсолютно одинаковым — GPU тратит все больше времени на создание каждого нового контекста.
В условиях, когда на сервере уже идет транскодирование и необходимо запускать новые потоки для обработки, это влияет на общую производительность и делает сервер просто непригодным для использования.
Проблема была подробно описана команде NVidia, но стандартного решения пока не предоставлено.
Поэтому на данный момент мы реализовали на нашем сервере механизм кэширования контекста с предварительным созданием контекстов при старте сервера.
Это решило проблему с точки зрения конечного пользователя, но запуск Nimble может занять некоторое время.
Настройка Nimble для эффективной работы с контекстами описано в нашем блоге .
Более того, контексты создавать непросто.
При большом количестве контекстов при включении любого скрипта транскодирования NVENC API начинает выдавать ошибки «Вызов API не выполнен, поскольку не удалось выделить достаточно памяти для выполнения запрошенной операции».
Эмпирическим путем выяснилось, что один GPU может запускаться и уверенно работать с 47 контекстами — и не имеет значения, контексты ли это кодера или декодера.
Было предположение, что это связано с объемом памяти на графическом процессоре.
Сейчас там 16 Гб, если поставить карту на 24 Гб, есть вероятность, что можно создать больше контекстов.
Но это только теория, ее нужно проверять, как уже говорилось ранее.
Полученные данные действительны для конкретной модели графического процессора; другие карты необходимо тестировать отдельно.
Именно ограничение количества контекстов является основным препятствием при работе с большими нагрузками.
5. Выводы
Итак, целью тестирования было изучение эффективности графического процессора для обозначенного круга задач и разработка рецептов его правильного использования.
Что произошло в конце?
Ээкономический эффект
Выше мы видели, насколько различается количество потоков, которые могут быть обработаны на CPU и на тандеме CPU+GPU. Давайте посмотрим, что это значит с точки зрения денег.Возьмем за основу тот же Softlayer и их цены на аренду оборудования.
Конфигурация без графического процессора будет стоить $819 в месяц .
Здесь вы можете выбрать машина.
Конфигурация с графическим процессором будет стоить $1729 в месяц за дата-центр в Амстердаме цены могут быть посмотреть здесь .
При использовании графического процессора цена аренды сервера немного увеличивается, поскольку используется более крупный форм-фактор 2U. Вероятно, экономический эффект будет выше при покупке оборудования (но для этого требуется серьезный анализ совокупной стоимости владения с учетом постоянного обновления линейки графических процессоров NVidia).
Теперь посмотрим на результаты теста: Для FullHD 1080p ЦП без графического процессора: 16 потоков на вход + 80 на выход. CPU + GPU: 36 потоков на вход + 180 на выход Преимущество при использовании графического процессора: 2,25x. Выгода от использования графического процессора: $819*2,25 – $1729 = 113 долларов в месяц при аренде 1 сервера с GPU. Для HD 720p ЦП без графического процессора: 22 потока на вход + 88 на выход. ЦП + графический процессор: вход 70 потоков + вывод 280 потоков Преимущество при использовании графического процессора: 3,18x. Выгода от использования графического процессора: $819*3,18 – $1729 = $875 в месяц при аренде 1 сервера с GPU То есть при арендном варианте экономия весьма заметна.
При этом не учитываются скидки — российский офис IBM обещает скидки на аренду ресурсов в облаке по сравнению с представленными здесь ценами.
Мы не стали углубляться в варианты приобретения, потому что… здесь совокупная стоимость владения сильно зависит от выбора поставщика, стоимости обслуживания в дата-центре и других факторов, хорошо известных тем, кто работает с «голым железом».
Однако предварительные цифры также говорят в пользу решения на базе графического процессора.
Также не забывайте о трафике и ширине канала – они в определенной степени включены в представленные выше тарифы, но вам нужно будет подбирать параметры под свои задачи, исходя из количества потоков, ожидаемого количества пользователей и т. д.
Масштабирование
Вариант с одной видеокартой на сервер нам кажется более экономически выгодным, чем вариант с двумя и более картами.Как мы видим, декодер GPU всегда был более загружен, чем кодер, но даже он оставался недозагруженным из-за проблем с использованием контекстов.
Если мы добавим вторую карту, то декодер будет использоваться еще меньше, мы не сможем загрузить кодеры на полную мощность, а всю работу по кодированию все равно придется переносить на ЦП, что не будет оправдано с точки зрения денег.
Мы также тестировали вариант с двумя графическими процессорами благодаря поддержке Softlayer, но из-за слабого экономического эффекта не приводим подробностей в статье.
Соответственно, для масштабирования нагрузки предпочтительнее добавлять новые серверы с одной видеокартой, чем добавлять карты в существующие машины.
Если количество входящих и исходящих потоков для вашего проекта относительно невелико — скажем, десяток HD-потоков с небольшим количеством выходных разрешений, с относительно небольшим объемом фильтрации, то целесообразнее будет использовать сервер без графического процессора.
.
Также стоит обратить внимание на то, что объем оперативной памяти для задачи преобразования потоков не так важен, как вычислительная мощность.
Так что в некоторых случаях можно еще и сэкономить, уменьшив объем памяти.
Заключение
Представленное аппаратное решение — комбинация процессора и графического процессора Tesla M60 — идеально подходит для перекодирования прямых трансляций при больших нагрузках.Графический процессор берет на себя самые ресурсоемкие операции — декодирование потоков и кодирование их в самые высокие разрешения, а средние и малые разрешения хорошо обрабатываются на ЦП.
Если у кого-то из читателей есть опыт работы и оптимизации производительности видеокарт для прямых трансляций, мы будем рады познакомиться с вашим опытом — напишите в комментариях.
Теги: #nvidia #Видеокарты #Работа с видео #H.264 #транскодирование #кодирование видео #высокая нагрузка #шустрый стример #транскодирование #декодирование видео
-
Наслаждайтесь Бесплатными Онлайн-Флеш-Играми
19 Oct, 24 -
Мейер, Альберт Джеймс
19 Oct, 24 -
Ягода
19 Oct, 24
