Вопрос: Как уменьшить использование ОЗУ на моем сервере?


Недавно я запустил сайт, который очень популярен, но у меня проблемы с масштабируемостью. Мой сайт сильно использует FFmpeg и в пиковые времена использование ОЗУ быстро достигает точки 2 ГБ, и файл подкачки начинает использоваться. Использование ЦП также начинает расти.

Пользователи жалуются, что сайт работает медленно. Они говорят это, потому что все экземпляры FFmpeg работают очень медленно из-за числа, запущенного одновременно. Пользователи используют FFmpeg на моем сервере в режиме реального времени.

Есть ли что-нибудь, что я могу рассмотреть или сделать, чтобы облегчить использование сервера и ОЗУ, просто стреляя? Может быть, есть что-то лучше, чем FFmpeg (!).

Единственное решение «бросать деньги» на более мощный сервер?

Я дал небольшую информацию, пожалуйста, попросите больше, так что эта проблема может быть решена.


4
2018-05-22 22:42


Источник


У вас есть статический контент, который вы обслуживаете через HTTP? [например, обработанные фильмы?] Используете ли вы Apache? Если это так - перейдите на какой-нибудь сервер, который лучше подходит для этого - например mathopd, lighthttpd или Nginx, И да - предложения от crunchyt и Arkain очень хорошие, если ваш сервис будет расти. Рано или поздно вам нужно будет изолировать задачи и распределить нагрузку, используя некоторую систему очередей. Просто убедитесь, что вы разрабатываете с самого начала с учетом этого [и осколки], поэтому вам не нужно переписывать всю систему - pQd
Извините, я должен ответить в ответ, но я не могу комментировать. Мне не хватает репутации, я делаю в stackoverflow :) Во всяком случае, очень хорошие ответы. Arkain - Я мог бы это сделать, но веб-приложение должно быть в режиме реального времени. Использование какой-либо системы quering или scheduling будет означать, что некоторым пользователям все равно придется ждать больше, чем нужно. crunchyt - Ты прав, одна коробка делает все! Может потребоваться некоторая работа, чтобы закодировать мое приложение, чтобы оно могло распространяться во многих ящиках, но это должно быть легко сделать. Спасибо за ссылки, прочитайте! PQD - У меня есть статический контент. Я действую - Abs
Не думайте, что это подходит для вики сообщества. - Jonathan Prior
Вы перекодируете в режиме реального времени? Если да, то в чем источник? Является ли он живым или заранее записанным? Если вы предварительно записали, можете ли вы кэшировать вывод из предыдущих прогонов ffmpeg, чтобы вы не повторяли повторные передачи одних и тех же данных? - Alnitak
Да, это в реальном времени, и видео предварительно записано. - Abs


Ответы:


Ну, простым решением было бы поставить очередь задач Ffmpeg, поэтому только фиксированное число будет работать в любое время. И вы действительно должны рассмотреть возможность запуска процессов Ffmpeg на отдельной машине с веб-сервера.


12
2018-05-22 22:42





Это общая проблема структурирования, а не проблема памяти. Похоже, вы набиваете все на одну коробку? DB, Web и MPG? Это не очень хорошо масштабируется!

Независимо от вашего приложения, любая интенсивная обработка будет работать лучше на нескольких машинах с использованием пакетной системы. Распространяя нагрузку на несколько ящиков и сохраняя действительно интенсивную работу вдали от веб-уровня, ваши пользователи будут благодарны вам!

Ваш веб-уровень должен обслуживать только интерфейс. У вас должно быть 1+ машин, предназначенных для обработки видео в фоновом режиме. Затем это должно стать доступным для обслуживания веб-уровня после его готовности.

Лучшая ссылка на эту тему, которую я нашел, - это создание масштабируемых веб-сайтов Калом Хендерсоном, бывшим техническим директором Flickr. Предыдущая ссылка на Amazon, поэтому вы можете просмотреть книгу по дешевке. Эта ссылка на Google Книги также позволит вам прочитать.

Удачи!


4
2018-05-22 22:42





Я думаю, вы, вероятно, могли бы кое-что сделать, чтобы улучшить использование памяти, но когда все будет сказано и сделано, вы, скорее всего, выйдете лучше, купив еще немного памяти. Я уверен, что меня отпустят за этот ответ, но я просто думаю об экономике решения этой проблемы.


1
2018-05-22 23:51



Вы еще не проголосовали. :) Это, вероятно, должно быть быстрым решением сейчас, когда я работаю над переписыванием и улучшением работы приложения. - Abs


Я думаю, что проще всего было бы просто купить новый сервер. Серьезно, Dell 2950 с 32 ГБ оперативной памяти и 8 ядер 3,2 ГГц, я думаю, был всего 8 или 10 тыс. Долларов CAD, Было бы легко потратить половину этого и все равно получить что-то, что может запускать множество задач parrallel и иметь много оперативной памяти. У вас определенно не было бы ограничения на 2 ГБ и замена на диск.


1
2018-05-23 18:44



Err ... это то, что от 8 000 до 10 000 долларов в месяц? Боже, у меня нет таких денег! - Abs
нет ... это стоимость сервера, купленного и оплаченного. - Kevin Nisbet


ffmpeg очень привязан к процессору, а не только к памяти. Приложение вряд ли будет быстрее, потому что в коробке больше оперативной памяти - больше экземпляров означает, что каждый из них работает медленнее и имеет меньше процессорных ресурсов.

Если вы не можете оптимизировать сам ffmpeg или использовать асинхронную очередь, вам нужно получить больше машин.

Идите, прежде всего, с процессором с достаточным объемом ОЗУ, чтобы не начинать замену до того, как вы полностью отключите использование всех процессоров.


0
2018-05-23 03:39



Вы тоже используете CPU, а также ракеты. Я сейчас изучаю способы оптимизации ffmpeg, я сомневаюсь, что придумаю все, что будет радикально изменяться по производительности. :( - Abs
Вы можете попробовать пойти на EC2 или другое решение для облачных вычислений - это может быть дешевле. - Artem Russakovskii


Из-за того, что это похоже на маркетинговый дроид от компании облачных вычислений, для этого предназначены облачные вычисления.

Я бы предложил использовать что-то вроде Amazon EC2 или Rackspace Cloud. Создайте базовое изображение, содержащее ffmpeg, и интерфейс, который позволяет ffmpeg называться удаленно из вашего приложения. Создайте несколько экземпляров этого изображения и убедитесь, что с использованием поставщика облачных вычислений вы можете создавать и уничтожать экземпляры этого изображения в соответствии с нагрузкой. Затем ваше приложение должно делегировать все задачи ffmpeg на ваши облачные серверы и контролировать количество облачных серверов, которые основаны на количестве заданий ffmpeg, которые необходимо обрабатывать синхронно. Это сохранит то, что я воспринимаю как узкое место в вашем приложении, транскодирование видео и т. Д., Отдельно от вашего приложения и способное масштабироваться по желанию.


0
2018-05-30 14:23