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

MAATRIX

Ampache — один из самых старых self-hosted музыкальных серверов (проект живёт с 2001 года), и в этом его сила: он поддерживает почти всё — Subsonic-совместимый API, DAAP, UPnP/DLNA, WebDAV, подкасты, интернет-радио, скробблинг в Last.fm. Но именно из-за этой всеядности вопрос «сколько же ему нужно памяти» не имеет одного ответа — он зависит от того, какими протоколами вы реально пользуетесь. Разберём по частям, что ест RAM и сколько закладывать под свой сценарий.

Что такое Ampache и почему память считается иначе, чем для соседей

Ampache — это классическое PHP-приложение поверх MySQL или MariaDB, а не отдельный демон на Go или Rust, как у более молодых конкурентов. Это значит, что его потребление памяти складывается не из одного процесса, а из связки: веб-сервер (nginx или Apache), PHP-FPM с пулом воркеров, СУБД и, при необходимости, ffmpeg для транскодирования на лету.

Из-за этого сравнивать Ampache «в лоб» с Navidrome (Go, встроенная SQLite, единый бинарник) некорректно — при одинаковом размере библиотеки Ampache почти всегда просит больше памяти именно за счёт связки PHP + СУБД. Это не недостаток, а плата за широту поддерживаемых клиентов и протоколов — если вам нужен DAAP для старого iTunes или WebDAV-доступ к файлам, у Navidrome и подобных решений этого просто нет.

Из чего складывается потребление RAM

Реальный расход памяти на сервере с Ampache раскладывается на пять статей:

• PHP-FPM воркеры — каждый активный воркер держит в памяти интерпретатор PHP плюс загруженные классы Ampache; на практике один воркер в простое — это условно 25–50 МБ, под нагрузкой (отдача API-запросов, генерация превью обложек) — заметно больше.
• MySQL/MariaDB — буфер InnoDB, кеш запросов и служебные структуры. Для библиотеки в десятки тысяч треков база данных (метаданные, теги, плейлисты, статистика прослушиваний) может занимать сотни мегабайт на диске, и чем больше буфер в памяти, тем быстрее поиск и сортировка.
• Веб-сервер — nginx в роли прокси перед PHP-FPM ест немного, единицы-десятки мегабайт даже под нагрузкой; Apache с mod_php тяжелее.
• Сканирование каталога — при добавлении новой музыки или полном пересканировании библиотеки Ampache парсит теги всех файлов и обновляет базу; на большой коллекции это кратковременный, но заметный пик потребления памяти и CPU.
• Транскодирование — отдельный процесс ffmpeg на каждый активный поток, который конвертируется на лету (например, FLAC → MP3 для клиента с медленным интернетом). Это самая непредсказуемая статья расходов, разберём её отдельно.

Если вы слушаете музыку локально или через клиент, который умеет напрямую отдавать оригинальные файлы (direct play), транскодирования вообще не происходит — и тогда основной расход памяти это PHP-FPM и MySQL, оба довольно скромные.

Сколько нужно на практике: три сценария

Дать одну цифру нечестно — приведём три реалистичных сценария с ориентировочными цифрами. Это именно ориентир: у вас библиотека может состоять из FLAC высокого разрешения или из компактных MP3, и это уже сдвигает цифры.

Для первого сценария 1 ГБ теоретически хватает, но на практике лучше закладывать 2 ГБ — операционная система, SSH, возможный Cron для бэкапов и системные обновления тоже требуют памяти, и на «впритык» сервере любой всплеск (например, полное пересканирование каталога) приводит к своппингу и заметным тормозам интерфейса. Общие принципы такого запаса разобраны в статье сколько оперативной памяти закладывать с запасом — рекомендации оттуда прямо применимы и к Ampache.

Транскодирование — главный пожиратель ресурсов

Именно транскодирование, а не размер библиотеки, чаще всего вынуждает переезжать на более мощный тариф. Каждый активный поток, который Ampache конвертирует на лету через ffmpeg (например, из FLAC в Opus для мобильного клиента на медленной сети), — это отдельный процесс со своим потреблением памяти и, что важнее, ощутимой нагрузкой на CPU. Точные цифры сильно зависят от кодека и битрейта на выходе, но по опыту закладывайте по CPU-ядру на каждый одновременный транскодируемый поток, если хотите, чтобы конвертация успевала за реальным временем воспроизведения.

Практический совет — не боритесь с симптомом через RAM, если проблема в CPU. Если у вас 2 ГБ памяти, но всего 1 виртуальное ядро, три одновременных транскодируемых потока всё равно будут заикаться, сколько бы памяти вы ни добавили. Для сервера с расчётом на несколько одновременных транскодирований лучше брать тариф с 2–4 vCPU, а не просто с большим объёмом RAM.

Второй практичный вариант — минимизировать транскодирование в принципе. Если у вас в библиотеке уже лежат MP3/AAC умеренного битрейта, большинство современных клиентов (включая мобильные Subsonic-клиенты) отдадут предпочтение прямой раздаче файла, и ffmpeg вообще не запускается. Транскодирование обычно включается автоматически только когда исходный формат клиент не умеет проигрывать (например, FLAC на iOS-клиенте без соответствующего кодека) или явно настроено принудительное понижение битрейта под мобильный трафик.

Тонкая настройка MySQL/MariaDB и PHP-FPM под память

Правильно выставленные лимиты СУБД и PHP-FPM экономят память эффективнее, чем покупка более дорогого тарифа. Для MariaDB на сервере с Ampache стоит явно задать буфер InnoDB в /etc/mysql/mariadb.conf.d/50-server.cnf:

[mysqld]
innodb_buffer_pool_size = 256M
innodb_buffer_pool_instances = 1
max_connections = 50
query_cache_type = 0

Для библиотеки до 30 000 треков 256 МБ буфера обычно достаточно, чтобы горячие данные (недавно проигранные треки, часто запрашиваемые плейлисты) помещались в память целиком. На библиотеке от 50 000 треков имеет смысл поднять до 512 МБ, если позволяет объём RAM сервера.

Для PHP-FPM пул стоит настраивать не «по умолчанию», а исходя из реального объёма памяти:

[www]
pm = dynamic
pm.max_children = 6
pm.start_servers = 2
pm.min_spare_servers = 1
pm.max_spare_servers = 3

При 2 ГБ RAM pm.max_children = 6 — разумный компромисс: даже если каждый воркер разово займёт 60–80 МБ под нагрузкой, суммарно это не выйдет за пределы доступной памяти с учётом MySQL и системных процессов. Отдельно проверьте memory_limit в php.ini — для Ampache с большими каталогами (тысячи обложек альбомов, обработка тегов) значение по умолчанию в 128 МБ иногда мало, разумный минимум — 256 МБ.

Docker или bare metal — что экономнее

Официальный образ Ampache в Docker Compose разворачивает как минимум два контейнера — сам Ampache и MySQL/MariaDB, иногда ещё Redis для кеширования сессий. Каждый контейнер — это отдельное адресное пространство памяти, и накладные расходы контейнеризации (изоляция cgroups, отдельные процессы внутри каждого контейнера) добавляют условно 50–150 МБ сверх того, что заняла бы связка на голой ОС.

Взамен вы получаете простоту обновлений (docker compose pull && docker compose up -d) и изолированность — если что-то пойдёт не так с PHP-версией после обновления, откат к предыдущему образу занимает секунды. На сервере с 2 ГБ RAM и скромной библиотекой разница между Docker и bare-metal установкой не критична, но на минимальном тарифе (1 ГБ) лишние сотни мегабайт под контейнеризацию уже ощутимы — там разумнее ставить Ampache напрямую через пакетный менеджер или из исходников, без Docker-прослойки.

Если вы уже держите на том же сервере Navidrome или сравниваете варианты, статья сколько RAM нужно для Navidrome даёт цифры для более лёгкого решения на Go — полезно для контраста, если гибкость Ampache вам не критична и хочется сэкономить память.

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