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

MAATRIX

Heimdall — один из самых популярных стартовых экранов для домашней лаборатории: карточки со ссылками на все ваши сервисы, встроенный поиск, опциональные виджеты статуса приложений. Вопрос «сколько ему нужно RAM» возникает у всех, кто впервые выбирает сервер именно под панель — переплачивать за тариф с 4 ГБ ради одной страницы со ссылками не хочется, но и упасть в OOM через неделю тоже. Разберёмся, из чего складывается потребление памяти у Heimdall и какой минимум реально закрывает задачу.

Из чего сделан Heimdall и почему это важно для RAM

Heimdall — не статическая HTML-страница, а полноценное PHP-приложение на фреймворке Laravel. Внутри официального образа linuxserver/heimdall крутится связка nginx + PHP-FPM + SQLite (база хранится файлом на диске, отдельный процесс СУБД не нужен). Это принципиально отличает Heimdall по профилю памяти от совсем лёгких дашбордов вроде статического Homepage — там весь рендеринг страницы происходит один раз при сборке, а у Heimdall каждый запрос обрабатывает живой PHP-процесс.

Практически это означает две вещи:

• Базовое потребление выше, чем у статических альтернатив, потому что PHP-FPM держит в памяти пул воркеров даже без активных посетителей.
• Потребление растёт не линейно от числа карточек на странице, а в первую очередь от того, сколько воркеров PHP-FPM одновременно обрабатывают запросы — а это уже зависит от настроек пула и от того, включён ли режим Enhanced Application.

Если вы сравнивали Heimdall с Homepage и удивились разнице в требованиях — вот и причина: Homepage статичен, Heimdall — нет.

Сколько RAM Heimdall реально ест: простой и нагрузка

Точные цифры зависят от версии образа, количества карточек, включённых Enhanced Application-виджетов и от того, кто ещё стучится на сервер (боты-сканеры, мониторинг). Дать гарантированное число нельзя, но по практике администраторов домашних лабораторий и по структуре стека можно ориентироваться на такие диапазоны — воспринимайте их как отправную точку, а не паспортные данные:

Enhanced Application — это режим, в котором Heimdall периодически ходит по API других приложений (например, показывает очередь загрузок Sonarr прямо на карточке). Каждый такой запрос — это отдельный PHP-процесс curl, живущий недолго, но кратковременно поднимающий потребление. Если у вас включено 10-15 карточек с таким режимом, разовые всплески памяти будут заметнее, чем у голого дашборда со ссылками.

Отдельно стоит закладывать память на сам PHP-FPM: даже в режиме ondemand (когда воркеры поднимаются по запросу и гасятся при простое) какое-то время после обращения процесс висит в памяти. В режиме dynamic с ненулевым pm.min_spare_servers часть воркеров резидентна постоянно — это стабильнее по отклику, но добавляет базовое потребление.

Минимальная конфигурация сервера

Если Heimdall — единственный сервис на сервере (то есть вы арендуете VPS ровно под одну эту панель, что бывает редко, но встречается для тестов), хватит скромного тарифа:

На практике Heimdall почти никогда не живёт на сервере в одиночестве — это входная точка в домашнюю лабораторию, а не самостоятельный проект. Типичный набор: сам Heimdall, Pi-hole как DNS-фильтр, обратный прокси вроде Traefik для TLS и доменов, плюс Portainer для управления контейнерами. Каждый из них добавляет свои 50-200 МБ, и итоговая сумма быстро съедает тариф в 512 МБ. Если планируете весь этот стек, закладывайте от 2 ГБ — это уже не «сервер под дашборд», а полноценная домашняя лаборатория в облаке, и требования там заметно выше, чем у единичного контейнера.

Что ещё влияет на потребление кроме самого контейнера

RAM самого процесса Heimdall — только часть картины. На типичном VPS с Docker в память дополнительно уходит:

• Docker daemon и containerd — обычно 50-150 МБ, зависит от количества запущенных контейнеров и логов.
• systemd, sshd, базовые сервисы Ubuntu/Debian — 100-200 МБ на свежей системе без лишнего софта.
• Файловый кеш ОС — Linux агрессивно кеширует диск в свободной RAM; это не «утечка», ядро отдаёт эту память приложениям по требованию, но в выводе free -h она выглядит как занятая.
• PHP OPcache внутри контейнера Heimdall — кеширует скомпилированный байт-код, что ускоряет отклик, но резервирует фиксированный кусок памяти независимо от нагрузки (обычно десятки мегабайт).

Если сервер регулярно перезагружает контейнер или падает по OOM, в первую очередь проверяйте не сам Heimdall, а совокупность всех сервисов — часто виноват не дашборд, а соседний контейнер с утечкой (та же Elasticsearch-подобная нагрузка от систем логирования, если вы их тоже развернули рядом).

Как ограничить память в docker-compose

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

services:
  heimdall:
    image: lscr.io/linuxserver/heimdall:latest
    container_name: heimdall
    environment:
      - PUID=1000
      - PGID=1000
      - TZ=Europe/Moscow
    volumes:
      - ./config:/config
    ports:
      - "8080:80"
      - "8443:443"
    mem_limit: 512m
    memswap_limit: 512m
    restart: unless-stopped

mem_limit здесь — жёсткий потолок: если контейнер попытается выйти за него, ядро убьёт процесс внутри (OOM killer на уровне cgroup), и Docker перезапустит контейнер согласно политике restart. memswap_limit, равный mem_limit, запрещает контейнеру уходить в своп — это осознанный выбор для сервисов, где вы предпочитаете быстрый рестарт медленной деградации через свопинг.

Если запускаете через Docker Compose v2 в режиме Swarm или хотите более гибкий контроль (soft limit + hard limit), используется секция deploy.resources:

    deploy:
      resources:
        limits:
          memory: 512M
        reservations:
          memory: 128M

Учтите: deploy.resources в обычном (не Swarm) docker compose up большинством версий игнорируется — для одиночного сервера практичнее классический mem_limit, показанный в первом примере.

Как проверить реальное потребление на вашем сервере

Ориентиры из таблиц — это чужие цифры на чужом железе с чужим набором карточек. Проверить свою реальность несложно:

# Мгновенный снимок потребления по всем контейнерам
docker stats --no-stream

# Только Heimdall, с обновлением в реальном времени
docker stats heimdall

# Общая картина по серверу
free -h
htop

docker stats покажет колонку MEM USAGE / LIMIT — если контейнер стабильно упирается в заданный mem_limit, это сигнал поднять лимит или разобраться, что именно ест память (обычно — включённые Enhanced Application виджеты или слишком щедрые настройки pm.max_children, если вы их меняли через кастомный конфиг). Стоит снять пару замеров в течение недели в разное время суток, а не полагаться на однократный запуск сразу после старта контейнера — свежий процесс всегда легче прогретого.

Если система в целом уже находится на грани по памяти ещё до Heimdall, возможно, для вашего набора сервисов вообще нужен другой подход к подбору сервера — здесь может пригодиться более широкий разбор: сколько ресурсов нужно VPS для обучения и экспериментов, где логика подбора конфигурации под несколько параллельных сервисов разобрана подробнее, чем в рамках одного приложения.

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