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

MAATRIX

Dashy (Lissy93/Dashy) — самостоятельно размещаемый дашборд-стартовая страница на Vue.js с упором именно на живой статус-мониторинг: каждая карточка сервиса может показывать зелёный или красный индикатор по результатам периодического пинга, плюс виджеты погоды, RSS, статистики Docker и произвольных API. Официальная документация проекта не даёт точной цифры RAM «на все случаи», а разница между запуском готового Docker-образа и сборкой из исходников по расходу памяти отличается в разы — и именно это чаще всего ловит новичков на слабой VPS. Разберём, где Dashy реально тратит память и сколько закладывать под разные сценарии.

Сколько RAM нужно Dashy: короткий ответ

Ключевое различие для Dashy — не столько во время работы, сколько на этапе установки. Готовый Docker-образ lissy93/dashy содержит уже собранные статические файлы и лёгкий Node-сервер, который их раздаёт — сам процесс в простое держит на глаз около 40-80 МБ. А вот сборка образа из исходников (docker build с нуля или сборка через yarn build на самом сервере) — это webpack/Vite-пайплайн для Vue-приложения, который на слабой машине легко упирается в 1 ГБ и падает по OOM ещё до того, как дашборд вообще запустится.

Практический ориентир:

Это ориентиры, а не измеренные бенчмарки — точный расход зависит от числа сервисов, интервала опроса статусов и от того, включены ли тяжёлые виджеты вроде Docker-статистики. Дальше — почему память расходуется именно так.

Готовый образ vs сборка из исходников

Это разделение — главное, что стоит понимать про ресурсы Dashy.

Готовый образ (lissy93/dashy с Docker Hub или GHCR). Здесь Vue-приложение уже собрано в статические HTML/CSS/JS файлы на этапе публикации образа. Контейнер просто раздаёт их через встроенный лёгкий сервер и выполняет фоновые запросы status-check. Это тот же принцип, что у Homepage — тяжёлая часть (сборка фронтенда) вынесена из рантайма, и на сервере остаётся только раздача статики плюс опрос сервисов.

Сборка из исходников. Если вы клонируете репозиторий и собираете образ сами — например, чтобы внести правки в код, а не только в конфиг — на этапе RUN yarn build внутри Dockerfile запускается полноценная сборка Vue-приложения. Webpack и связанные с ним инструменты по своей природе прожорливы к памяти при компиляции и минификации JS-бандлов: на серверах с 512 МБ и без свопа такая сборка — частая причина падения docker build с ошибкой Killed или JavaScript heap out of memory, ещё до того, как Dashy успел хоть раз запуститься. Если кастомизация не критична, использование готового образа снимает эту проблему полностью.

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

Когда контейнер уже запущен на готовом образе, расход памяти растёт из трёх источников.

Базовый Node-процесс. Сервер, который раздаёт собранные файлы и обслуживает API для конфигурации, держит в памяти основные структуры JS-рантайма — это плата, аналогичная любому Node.js-приложению, и она почти не зависит от числа сервисов на дашборде.

Status-check (пинг-мониторинг). Ключевая фишка Dashy — карточка сервиса может проверяться по HTTP/ping с заданным интервалом (statusCheckInterval в conf.yml, по умолчанию не самый частый) и показывать индикатор доступности. Каждая такая проверка — отдельный сетевой запрос по таймеру. При 5-10 сервисах это незаметно, но при полусотне сервисов с интервалом в 10-30 секунд фоновая нагрузка на CPU и память от параллельных запросов становится ощутимой, особенно если часть проверяемых адресов отвечает медленно и запросы накапливаются в очереди.

Виджеты. Как и в Homepage, каждый виджет в conf.yml — источник дополнительной сетевой активности: погода через внешний API, RSS-лента, статистика Docker-контейнеров через сокет, курсы валют, произвольный JSON через generic-виджет. Виджеты с коротким интервалом обновления и большим объёмом ответа (например, список из полусотни Docker-контейнеров) дают заметно больше нагрузки, чем статичная ссылка-карточка без виджета.

Что происходит при нехватке памяти

Симптом различается в зависимости от того, где именно не хватает памяти.

При сборке из исходников на слабой машине процесс docker build обрывается посреди этапа yarn build, и в логе видно что-то вроде JavaScript heap out of memory или просто Killed без внятного объяснения — это ядро Linux остановило процесс сборки через OOM killer (Out-Of-Memory killer — механизм, который принудительно завершает процесс, когда система не может выделить память даже с учётом свопа). Проверить, было ли это OOM, можно так:

dmesg | grep -i "killed process"
journalctl -k --since "-30min" | grep -i oom

Если контейнер уже запущен на готовом образе и падает при рестарте или при пиковом всплеске status-check-запросов, проверьте конкретно его:

docker inspect dashy --format='{{.State.OOMKilled}}'
docker stats dashy --no-stream

true в первой команде — прямое подтверждение OOM. Второй частый сценарий на слабом сервере — не падение, а вялая реакция интерфейса: индикаторы статуса подгружаются с задержкой, потому что процесс постоянно уходит в своп вместо оперативной памяти. Про грамотный расчёт свопа под такие пики есть отдельный разбор — правильный размер swap для VPS, а общие признаки нехватки RAM на сервере до того, как что-то реально упадёт, разобраны в статье что делать при нехватке RAM.

Как снизить потребление RAM

Если сервер ограничен по памяти, есть рабочие способы уменьшить нагрузку без потери функциональности мониторинга.

Использовать готовый образ вместо сборки на сервере. Это снимает основной пик потребления памяти целиком — сборку Vue-приложения лучше вообще не выполнять на слабой VPS, а брать готовый тег с Docker Hub или GHCR.

Увеличить интервал status-check для некритичных сервисов. В conf.yml интервал задаётся на уровне секции appConfig или индивидуально для сервиса:

appConfig:
  statusCheckInterval: 60  # секунд, вместо более частого опроса по умолчанию

sections:
  - name: Инфраструктура
    items:
      - title: Backup-сервер
        url: https://backup.example.com
        statusCheck: true
        statusCheckInterval: 300  # для некритичного сервиса — раз в 5 минут достаточно

Для сервисов, где секундная актуальность не нужна (бэкап-хосты, редко используемые внутренние панели), интервал в 3-5 минут вместо дефолтного заметно снижает фоновую сетевую нагрузку.

Отключать status-check и виджеты там, где они не нужны. Простая карточка-ссылка без statusCheck: true и без виджета почти ничего не стоит по памяти — расход даёт именно активный опрос. Если сервис нужен просто как быстрый переход, не подключайте к нему проверку статуса.

Ограничить память контейнера явно:

services:
  dashy:
    image: lissy93/dashy:latest
    container_name: dashy
    volumes:
      - ./conf.yml:/app/public/conf.yml
    ports:
      - "8080:8080"
    deploy:
      resources:
        limits:
          memory: 256M
    restart: unless-stopped

Если контейнер регулярно упирается в лимит и получает OOM, это сигнал поднять его или сократить число активных проверок — а не убирать ограничение вслепую.

Установка на VPS: практическая конфигурация

Официально рекомендуемый способ — готовый Docker-образ, он же самый предсказуемый по ресурсам. Минимальный рабочий docker-compose.yml:

services:
  dashy:
    image: lissy93/dashy:latest
    container_name: dashy
    volumes:
      - ./conf.yml:/app/public/conf.yml
    ports:
      - "8080:8080"
    healthcheck:
      test: ["CMD", "node", "/app/services/healthcheck"]
      interval: 30s
      timeout: 10s
      retries: 3
    restart: unless-stopped

Вся конфигурация — сервисы, секции, виджеты, тема — живёт в одном YAML-файле conf.yml, который удобно версионировать в git отдельно от образа. Встроенный healthcheck-скрипт полезен именно на слабой машине: он позволяет системе (или внешнему монитору вроде Uptime Kuma) отличить «контейнер жив, но подвисает» от «контейнер реально упал» — про настройку такого внешнего наблюдения есть отдельная статья: как установить и настроить Uptime Kuma на VPS.

Если Dashy должен быть доступен снаружи, а не только в локальной сети, поставьте перед ним реверс-прокси с TLS — разбор настройки под Docker есть в статье Traefik как reverse proxy для Docker, а общий процесс подготовки Docker Compose для продакшена — в статье Docker Compose для продакшена на Ubuntu 24.04.

По CPU Dashy не требователен в рантайме — 1 vCPU достаточно почти всегда, единственный момент, где процессор реально нагружается, это именно сборка из исходников, которой на VPS лучше избегать. Отдельный сервер под один Dashy — почти всегда избыточное решение: как и Homepage, он обычно ставится рядом с десятком других сервисов домашней лаборатории или небольшой инфраструктуры, статус которых как раз и отображает, — и именно их совокупный аппетит к памяти, а не сам дашборд, определяет реальный тариф VPS. Если рядом с Dashy держите свой собственный self-hosted статус-монитор, а не только карточки со status-check, похожий разбор ресурсов есть для Gatus и для Homarr — обе альтернативы решают близкую задачу немного по-разному.

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