Сколько RAM нужно для Emby

MAATRIX

Emby — не самый прожорливый по памяти сервис, но именно RAM чаще всего оказывается не тем ресурсом, о котором думают заранее, когда собирают домашний медиасервер. Обычно все считают диски и CPU для транскодирования, а память добавляют «с запасом», не понимая откуда этот запас берётся. Разберём по цифрам: что жрёт Emby в состоянии покоя, что добавляют библиотека, транскодирование и одновременные зрители, и какую конфигурацию брать под разные сценарии — от одного пользователя до семейного медиацентра на 4-5 активных стримов.

Сколько нужно памяти самому Emby Server

Сам процесс Emby Server (это .NET-приложение) в простое, без активных стримов, обычно держит 150-300 МБ RAM. Это база — процесс индексации метаданных, веб-интерфейс, фоновые задачи мониторинга библиотеки.

Дальше добавляется:

• Сканирование библиотеки — при первом добавлении большой коллекции (тысячи файлов) память кратковременно растёт до 500 МБ-1 ГБ, пока Emby парсит метаданные, качает постеры и обложки из интернет-баз (TMDB, TVDB). После завершения сканирования память откатывается к базовому уровню.
• Размер базы метаданных — чем больше файлов в библиотеке (не размер в гигабайтах, а именно количество элементов — фильмов, серий), тем больше держится в памяти индексов SQLite-базы. На библиотеке в 500-1000 единиц контента разница некритична, но на 10000+ файлов процесс может стабильно занимать 500 МБ и выше даже без активных стримов.
• Плагины — каждый включённый плагин (субтитры, уведомления, дополнительные метаданные-провайдеры) добавляет по 10-50 МБ. Обычно набор из 3-5 плагинов не даёт заметного прироста.

Итого простой Emby с библиотекой среднего размера (2000-5000 файлов) и парой плагинов — это 300-600 МБ. Это база, на которую накладывается транскодирование.

Транскодирование — главный потребитель памяти

Вот где разница становится существенной. Прямое воспроизведение (Direct Play) — когда клиент поддерживает формат файла и Emby просто отдаёт поток без изменений — почти не грузит память сверх базы. А вот транскодирование (перекодирование на лету под возможности клиента или ограничения сети) — совсем другая история.

Ffmpeg-процесс транскодирования одного потока в зависимости от разрешения и настроек буферизации потребляет:

Цифры ориентировочные и сильно зависят от конкретного контента (битрейт исходника, кодек, наличие HDR-обработки) и настроек буфера сегментов в Emby — считайте их отправной точкой, а не точным ориентиром. На CPU-транскодировании память растёт заметнее, чем на аппаратном (через QuickSync/NVENC), потому что программный ffmpeg держит больше буферов кадров в оперативке.

Ключевой момент: каждый одновременный стрим с транскодированием — это отдельный ffmpeg-процесс со своим потреблением памяти. Если у вас три человека одновременно смотрят с транскодированием 4K→1080p, это не 700 МБ, а условно 3×500-700 МБ поверх базы Emby.

Сколько зрителей одновременно вы реально обслуживаете

Планировать нужно не «сколько у меня есть Emby-пользователей», а сколько одновременных активных стримов реально бывает. Для домашнего использования это редко больше 2-4 одновременно, даже если аккаунтов создано десять.

Практический расчёт памяти:

RAM = база Emby (0.5 ГБ)
    + (число одновременных стримов с транскодированием × 0.3-0.7 ГБ)
    + запас ОС и файлового кеша (1-2 ГБ)

Пример на 3 одновременных стрима, из них 2 требуют транскодирования 1080p и 1 — 4K:

0.5 + (0.3 + 0.3 + 0.7) + 1.5 ≈ 3.3 ГБ

Округляем с запасом на пики — получаем комфортные 4 ГБ. Если большинство зрителей смотрят на устройствах, которые поддерживают Direct Play (умные телевизоры, современные приложения Emby на TV, браузеры с поддержкой нужных кодеков), транскодирование не включается вообще, и тогда даже 5-6 одновременных зрителей укладываются в 2 ГБ.

Готовые ориентиры по конфигурациям

Эти цифры — для самого Emby и его нагрузки. Если на том же сервере крутится что-то ещё (torrent-клиент для пополнения библиотеки, *arr-стек — Sonarr/Radarr/Prowlarr, обратный прокси), добавляйте под них отдельно: связка автоматизации обычно требует ещё 1-2 ГБ.

CPU и диск — не забываем про остальные ресурсы

Память — не единственное узкое место. Если у сервера нет аппаратного ускорения транскодирования (QuickSync у Intel, NVENC у Nvidia), CPU станет проблемой раньше RAM: одно 4K→1080p транскодирование на голом CPU способно упереться в 4-6 ядер современного процессора. Виртуальным серверам без проброса GPU программное транскодирование даётся тяжелее, чем выделенным серверам с процессором, поддерживающим QuickSync (линейка Intel с встроенной графикой).

По диску ориентируйтесь на объём самой коллекции плюс запас под временные файлы транскодирования — Emby по умолчанию пишет транскодируемые сегменты во временную папку, и на активном сервере с несколькими параллельными стримами это может быть несколько гигабайт временных данных, которые нужно не забыть чистить или вынести на отдельный быстрый диск (SSD снижает задержки старта воспроизведения при перемотке).

Если система на пределе и транскодирование начинает сыпать ошибками или тормозить, вопрос часто не только в объёме RAM, но и в том, как она расходуется — с этим стоит разобраться отдельно: что делать при нехватке RAM разбирает конкретные признаки и способы диагностики.

Emby, Jellyfin или Plex — на что это влияет по памяти

Emby, Jellyfin и Plex построены на схожей архитектуре (Jellyfin — форк Emby с открытым кодом), поэтому по базовому потреблению памяти они близки: разница в единицы-десятки процентов, а не в разы. Основные факторы потребления одинаковы для всех трёх — размер библиотеки, число активных транскодирований, наличие аппаратного ускорения.

Если вы выбираете между ними именно с точки зрения серверных ресурсов, сравнение стоит смотреть в комплексе — не только память, но и удобство, экосистему клиентов, лицензионные ограничения: обзор Jellyfin или Plex — что выбрать для сервера разбирает разницу подробно. А если решите ставить Jellyfin вместо Emby, пошаговая инструкция есть в статье как установить и настроить медиасервер Jellyfin на VPS.

Как выбрать сервер под свой сценарий

Для личного использования и небольшой семьи вполне хватает обычного VPS — конфигурации на 2-4 ГБ RAM закрывают сценарий с 1-3 зрителями и умеренной библиотекой. Если планируете активный шаринг с друзьями, регулярное 4K-транскодирование на несколько человек одновременно или библиотеку от 10000 файлов — разумнее сразу смотреть на выделенный сервер с процессором, поддерживающим аппаратное ускорение видео: там транскодирование не съедает CPU целиком и оставляет запас под рост библиотеки.

Общий подход к тому, сколько памяти закладывать на медиасервер в принципе (не только под Emby, но и с учётом связанных сервисов), разобран в статье сколько оперативной памяти закладывать с запасом — полезно свериться, если сервер будет тянуть не только Emby.

Частые вопросы