Назад | Перейти на главную страницу

Как уменьшить использование оперативной памяти на моем сервере?

Я недавно запустил сайт, который очень популярен, но у меня проблемы с масштабируемостью. Мой сайт интенсивно использует FFmpeg а в часы пик объем оперативной памяти быстро достигает отметки в 2 ГБ, и файл подкачки начинает использоваться. Загрузка процессора тоже начинает расти.

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

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

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

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

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

Это обычная проблема структурирования, а не проблема памяти. Похоже, вы все запихиваете в одну коробку? Обработка БД, Интернета и MPG? Это не очень хорошо масштабируется!

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

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

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

Удачи!

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

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

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

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

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

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

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