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

MAATRIX

Airsonic — форк Subsonic, который вырос из желания сообщества сохранить открытый стриминг музыки после того, как оригинальный проект ушёл в закрытую freemium-модель. С памятью тут всё иначе, чем у видео-медиасерверов: аудио легче на порядок, а главный потребитель RAM — не транскодирование, а сама JVM, на которой Airsonic крутится. Разберём, сколько закладывать под ядро, индексацию библиотеки и одновременных слушателей, чтобы не переплачивать за сервер и не упереться в своп в вечерний час пик.

Сколько нужно памяти самой JVM

Airsonic — Java-приложение на Spring Boot, и это определяет профиль памяти сильнее, чем что-либо ещё. Даже в полном простое, без единого активного стрима, процесс JVM держит 250-400 МБ — это не сам Airsonic «ест» память, а накладные расходы виртуальной машины Java: загруженные классы, куча (heap), метаданные JIT-компилятора.

По умолчанию Airsonic (в standalone-jar или Docker-образе) запускается с ограничением кучи в районе -Xmx512m, но на практике этого маловато при сколько-нибудь заметной библиотеке — процесс начинает упираться в лимит и чаще запускать сборку мусора (GC), что видно по кратковременным подвисаниям веб-интерфейса. Разумный старт — поднять лимит:

JAVA_OPTS="-Xms256m -Xmx1024m"

Это не «займёт» гигабайт сразу — -Xmx задаёт потолок, к которому куча может вырасти под нагрузкой, а -Xms — стартовый размер. Реальное потребление на старте будет ближе к 300-400 МБ и будет расти по мере работы с библиотекой и стримами.

Библиотека и индексация — что добавляет к базе

Airsonic использует Lucene для полнотекстового поиска по библиотеке (артисты, альбомы, треки). Индекс строится при сканировании и живёт в памяти частично, частично на диске:

• Первое сканирование библиотеки — самый тяжёлый момент. На коллекции в 10000-20000 треков память кратковременно поднимается на 300-600 МБ сверх базы, пока Airsonic парсит ID3/Vorbis-теги, строит индекс и (если включено) тянет обложки альбомов из внешних источников. После завершения сканирования потребление откатывается.
• Размер индекса в устоявшемся режиме — на библиотеке до 5000 треков разница почти незаметна, на 20000-50000 треков часть индекса Lucene стабильно держится в памяти и добавляет условно 100-300 МБ к базовому потреблению JVM.
• Плейлисты и подкасты — если используете встроенную поддержку подкастов Airsonic (периодическая проверка RSS-лент и загрузка эпизодов), это фоновая задача с небольшим, но не нулевым отпечатком — обычно десятки МБ, ощутимо только при большом числе подписок.

Цифры ориентировочные — точный расход зависит от формата тегов, наличия встроенных обложек в файлах и настроек сканирования (полное vs инкрементальное). Считайте их отправной точкой, а не гарантированным значением для вашей коллекции.

Транскодирование аудио — почему это не то же самое, что видео

Здесь Airsonic заметно легче любого видео-медиасервера. Транскодирование аудио через ffmpeg или LAME при переключении битрейта (например, отдать mp3 320kbps клиенту с ограничением на 128kbps для мобильной сети) — это на порядки меньший поток данных, чем видео:

Даже десяток одновременных транскодируемых аудиопотоков добавит условно 150-400 МБ — сравнимо с одним-единственным потоком видео-транскодирования 1080p на медиасервере вроде Emby или Plex. Это ключевое отличие Airsonic от видео-стриминга: RAM-бюджет почти целиком уходит в JVM и индекс, а не в кодирование самого контента.

Важный нюанс: транскодер (ffmpeg-бинарник) должен быть установлен и доступен Airsonic отдельно — сам JVM-процесс им не является, это внешний вызов. На потребление памяти JVM это влияет слабо, но сам ffmpeg-процесс кратковременно занимает свою порцию памяти операционной системы на время активного стрима.

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

Для домашнего или небольшого семейного использования редко бывает больше 2-3 одновременных активных стримов, даже если учётных записей создано больше. Прямое воспроизведение (когда клиент поддерживает формат файла без изменений) вообще не грузит транскодер — а среди современных Subsonic-совместимых приложений (DSub, play:Sub, Substreamer, Symfonium) это частый случай.

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

RAM = база JVM (0.4 ГБ)
    + индекс библиотеки (0.1-0.3 ГБ, зависит от размера)
    + (число одновременных транскодируемых стримов × 0.02-0.04 ГБ)
    + запас ОС и файловый кеш (0.5-1 ГБ)

Пример на библиотеку 15000 треков и 4 одновременных слушателя, из них 2 с транскодированием:

0.4 + 0.2 + (0.03 + 0.03) + 0.7 ≈ 1.4 ГБ

С запасом на пики и фоновое сканирование это укладывается в комфортные 2 ГБ. Даже при десятке одновременных слушателей с транскодированием прирост от самих стримов остаётся в пределах пары сотен мегабайт — в отличие от видео, где каждый новый транскодируемый зритель ощутимо двигает нижнюю границу.

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

Эти цифры — под сам Airsonic и его JVM. Если на том же сервере крутится обратный прокси (nginx перед Airsonic для TLS), торрент-клиент для пополнения библиотеки или бэкап-агент, добавляйте под них отдельно — обычно ещё 200-500 МБ суммарно на лёгкий сопутствующий стек. Общий подход к тому, сколько памяти закладывать с запасом на сервер целиком, разобран в статье сколько оперативной памяти закладывать с запасом.

Airsonic, Airsonic Advanced или Navidrome — что выбрать по памяти

Здесь стоит сказать прямо: оригинальный репозиторий Airsonic заморожен — активная разработка перешла в форк Airsonic Advanced, который чинит баги, обновляет зависимости и остаётся ближайшим по духу к оригиналу (тот же Spring Boot, тот же профиль памяти на JVM). Если планируете новый инстанс с нуля, разумнее ставить именно Airsonic Advanced, а не архивную версию.

Если память — приоритет, у Airsonic-семейства есть более лёгкая альтернатива: Navidrome написан на Go и компилируется в нативный бинарник без накладных расходов JVM. Базовое потребление Navidrome в простое обычно в 2-3 раза ниже, чем у Airsonic — сказывается разница между интерпретируемой Java-виртуальной машиной и компилируемым Go. Функционально Navidrome покрывает тот же Subsonic API (те же мобильные клиенты работают без изменений), так что миграция технически возможна без смены экосистемы приложений.

Если решите попробовать Navidrome вместо Airsonic, пошаговая установка есть в статье как установить и настроить Navidrome на VPS, а готовый файл для контейнерного разворачивания — в Navidrome в Docker Compose. Про восстановление после сбоя стоит почитать заранее, а не когда библиотека уже пропала: бэкап и восстановление Navidrome.

Если же вам важна именно экосистема Subsonic/Airsonic с её историей плагинов и настроек — оставаться на Airsonic Advanced с адекватным -Xmx полностью оправдано, разница в реальном потреблении при разумной библиотеке не критична для большинства домашних сценариев.

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

Для личного использования и небольшой семьи Airsonic комфортно живёт на самом скромном VPS — конфигурации на 1-2 ГБ RAM закрывают сценарий с 1-4 слушателями и библиотекой до 20000 треков без всяких компромиссов. Это заметно дешевле, чем сервер под видео-медиацентр, именно потому что аудио-транскодирование почти не давит на память.

Если планируете большую community-библиотеку (50000+ треков), активный шаринг с десятком одновременных слушателей или держите на том же сервере ещё несколько сервисов, разумнее сразу брать VPS на 4 ГБ и выше — запас пригодится не столько под сам Airsonic, сколько под пиковую нагрузку сканирования и фоновые задачи, которые совпадают по времени с активным прослушиванием.

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