Сколько RAM нужно для Node-RED

MAATRIX

Node-RED выглядит лёгким — это просто редактор потоков поверх Node.js, никакой тяжёлой базы данных под капотом. Но стоит подключить MQTT, Home Assistant, десяток дашбордов и пару функций с большим контекстом — и процесс, который час назад держался в 80 МБ, внезапно съедает 400-500 МБ и начинает подвисать на слабом VPS. Разберём, из чего на самом деле складывается потребление памяти и сколько RAM закладывать под разные сценарии — от одиночного хобби-проекта до связки с полноценным умным домом.

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

Node-RED — это процесс Node.js, и почти вся память, которую он потребляет, укладывается в несколько статей:

• Сам движок Node.js и рантайм — база около 40-60 МБ только на старт процесса, ещё до загрузки единого потока.
• Установленные ноды (палитра) — каждый npm-пакет из node_modules подгружается в память при старте, даже если поток с ним не активен. Чем больше нод установлено через Manage Palette, тем выше базовый расход.
• Флоу и рантайм-объекты — сами потоки (JSON-описание) занимают немного, но каждый активный поток создаёт объекты в памяти для обработки сообщений.
• Context storage — данные, которые вы сохраняете через flow.set(), global.set(), context.set(). По умолчанию это memory-хранилище, и оно живёт в той же куче V8, что и всё остальное.
• Дашборд (node-red-dashboard) — держит в памяти состояние всех виджетов и обслуживает Socket.IO-соединения для каждого открытого браузера.
• Очереди сообщений — если поток генерирует события быстрее, чем следующие ноды успевают их обрабатывать (частая ситуация с MQTT-топиками на большой частоте), сообщения накапливаются в памяти.

Важный нюанс: Node.js (V8) не сразу отдаёт память обратно ОС после сборки мусора — так называемая куча "разогревается" и держит выделенный объём про запас. Поэтому даже спокойный Node-RED месяц спустя после рестарта часто показывает в htop больше, чем в первый день — это не обязательно утечка, а нормальное поведение V8.

Минимальная конфигурация: только автоматизации без дашборда

Если вы используете Node-RED как чистый оркестратор — несколько десятков потоков, обработка MQTT-сообщений, HTTP-запросы к API, простая логика через function-ноды, — базовое потребление держится скромным.

Ориентировочно (именно ориентировочно — цифры сильно зависят от набора установленных нод и активности потоков):

• Свежий Node-RED сразу после старта — 60-100 МБ.
• С 20-40 активными потоками средней сложности и MQTT-клиентом — 120-180 МБ.
• Пиковые всплески при обработке очередей сообщений — плюс 50-100 МБ сверху.

Для такого сценария 1 ГБ RAM — рабочий минимум с запасом, а 512 МБ может хватить, если это единственный процесс на сервере и вы не устанавливаете десятки дополнительных нод. На VPS с 512 МБ стоит сразу настроить swap — это дешёвая страховка от OOM-killer в момент пиковой нагрузки при перезапуске или обновлении палитры.

# Быстрый swap-файл на 1 ГБ, если его ещё нет
sudo fallocate -l 1G /swapfile
sudo chmod 600 /swapfile
sudo mkswap /swapfile
sudo swapon /swapfile
echo '/swapfile none swap sw 0 0' | sudo tee -a /etc/fstab

Node-RED + Home Assistant + MQTT: типичная связка умного дома

Самый частый практический сценарий — Node-RED как визуальный слой автоматизаций поверх Home Assistant, подключённый через node-red-contrib-home-assistant-websocket и MQTT-брокер (Mosquitto).

Здесь память растёт не столько от самого Node-RED, сколько от количества сущностей и частоты событий:

• Плагин Home Assistant websocket при подключении кэширует состояния всех entity — при 200-300 устройствах это заметная прибавка к базовому потреблению.
• Каждая подписка на MQTT-топик добавляет обработчик; при частых обновлениях (датчики движения, энергопотребление раз в секунду) очередь событий может расти быстрее, чем успевает разгребаться однопоточный event loop Node.js.
• Дашборд Node-RED (если используется параллельно с Lovelace в Home Assistant) добавляет ещё один слой состояния поверх того же процесса.

Практический совет: не держите Home Assistant и Node-RED на одной машине с 1 ГБ RAM, если у вас больше сотни устройств. Связка "HA + Mosquitto + Node-RED" на одном сервере комфортно чувствует себя от 2 ГБ RAM, а при активном использовании функций (function-ноды с обработкой истории, интеграция с внешними API погоды/курсов) лучше закладывать 3-4 ГБ, особенно если Home Assistant Core крутится в том же контейнере или рядом.

Если вы разворачиваете обе системы через docker compose, разумно сразу выставить лимиты по памяти на каждый контейнер отдельно — так один процесс не сможет "съесть" всю память соседа при утечке или всплеске нагрузки:

services:
  nodered:
    image: nodered/node-red:latest
    restart: unless-stopped
    ports:
      - "1880:1880"
    volumes:
      - ./node-red-data:/data
    deploy:
      resources:
        limits:
          memory: 512M
        reservations:
          memory: 256M

Готовый пример docker-compose для самого Home Assistant разобран в статье про Home Assistant в Docker Compose, туда же можно добавить сервис Node-RED через network_mode: service:homeassistant или отдельную docker-сеть с доступом по имени контейнера.

С дашбордом node-red-dashboard: цена визуальных виджетов

Если поверх автоматизаций вы держите node-red-dashboard с десятками gauge, chart и switch-виджетов, добавляется отдельная статья расходов:

• Каждое открытое соединение браузера с дашбордом держит активный Socket.IO-канал на сервере — 5-10 одновременных вкладок (телефон, планшет на стене, ноутбук) заметно прибавляют к базовой памяти.
• Виджеты типа ui_chart хранят историю точек в памяти на стороне сервера для построения графика — если история не ограничена явно, объём хранимых точек растёт со временем.
• Каждая перезагрузка страницы дашборда пересчитывает состояние всех виджетов заново, создавая кратковременный всплеск потребления.

Для дашборда с 30-50 виджетами и парой одновременных подключений закладывайте дополнительные 150-250 МБ сверх базового потребления автоматизаций. Если вы строите полноценную панель "умного дома" на большой экран с автообновлением графиков каждую секунду — это уже сценарий на 2-3 ГБ RAM минимум, отдельно от Home Assistant.

Отдельный совет по ui_chart: явно ограничивайте removeOlder и removeOlderPoints в настройках ноды, иначе история графика будет копиться в памяти месяцами без ограничения.

Context storage: где реально прячется утечка памяти

Самая частая причина "Node-RED со временем начинает тормозить" — неограниченный рост context storage. По умолчанию flow.set() и global.set() пишут в memory-хранилище — то есть прямо в кучу процесса, без какого-либо ограничения по объёму.

Типичная ошибка: накопление массивов или объектов в глобальном контексте без очистки — например, ведение истории показаний датчика в global.set('history', [...]) с добавлением новой точки каждую секунду и без обрезки старых значений. За неделю такой массив легко может занять десятки мегабайт на один датчик, а если их пять-десять — счёт идёт на сотни.

Что с этим делать:

• Переключите context storage на файловое хранилище (localfilesystem) для данных, которые не нужны в реальном времени в памяти — это добавляет небольшую задержку на диск, но убирает бесконтрольный рост кучи.
• Явно очищайте старые записи в массивах через .slice() перед сохранением, если вам нужна история — храните последние N точек, а не всё подряд.
• Используйте context.set() (уровень ноды) вместо global.set() там, где данные нужны только внутри одного потока — это не экономит память напрямую, но упрощает поиск утечки при отладке.

Настройка в settings.js:

contextStorage: {
    default: "memoryOnly",
    memoryOnly: { module: "memory" },
    file: { module: "localfilesystem" }
}

Как посмотреть реальное потребление и ограничить его

Прежде чем закладывать RAM "с запасом на глаз", посмотрите, что реально происходит на вашей текущей установке.

Для голой установки (не в Docker):

# PID процесса Node-RED
pgrep -f node-red

# Потребление памяти конкретного процесса
ps -o pid,rss,vsz,cmd -p $(pgrep -f node-red)

# Живой мониторинг
htop -p $(pgrep -f node-red)

Колонка RSS — это реальная физическая память, которую процесс держит в ОЗУ, а не виртуальный размер (VSZ), который может быть сильно больше и вводить в заблуждение.

Для установки в Docker:

docker stats nodered --no-stream

Если Node-RED запущен через systemd, можно жёстко ограничить память юнита — при превышении процесс будет убит OOM-killer'ом ядра, что часто предпочтительнее, чем зависание всей системы из-за общей нехватки памяти:

# /etc/systemd/system/nodered.service.d/override.conf
[Service]
MemoryMax=512M
MemoryHigh=400M

Для Node.js есть и собственный флаг ограничения кучи --max-old-space-size (в мегабайтах), но учтите: он ограничивает только heap V8, а не полный RSS процесса (буферы, нативные модули и стек считаются отдельно) — жёстко полагаться только на него не стоит, лучше комбинировать с лимитом на уровне systemd или Docker.

node --max-old-space-size=256 $(which node-red)

Если у вас часто не хватает памяти и непонятно, где узкое место — разбор общих причин и способов диагностики есть в статье что делать при нехватке RAM.

Сравнение с похожими инструментами автоматизации

Если вы выбираете между Node-RED и альтернативами для оркестрации автоматизаций, память — не единственный, но заметный критерий:

Node-RED в чистом виде легче большинства альтернатив на старте, но его память менее предсказуема при росте: она сильно зависит от того, что именно вы кладёте в context storage и сколько нод установлено, а не только от сложности логики.

Итоговые рекомендации по объёму RAM

Сведём всё в практическую таблицу — с запасом на систему и рестарт без падений:

Если вы разворачиваете связку с нуля, разумная стартовая точка — VPS на 2 ГБ RAM с возможностью апгрейда без переустановки: начинаете с малого, смотрите реальное потребление через docker stats или htop первую неделю, и увеличиваете ресурсы по факту, а не по прогнозу.

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