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

MAATRIX

Huginn — это самостоятельный конвейер агентов: одни следят за сайтами и API, другие фильтруют и склеивают события, третьи шлют результат в Telegram, почту или вебхук. Удобно и почти бесплатно в эксплуатации, пока не встаёт вопрос — а сколько под это брать сервера. Взять 1 ГБ и через неделю ловить OOM-killer, убивающий процесс в самый неподходящий момент, или сразу переплачивать за 4 ГБ, которые не нужны. Разберём, из чего складывается потребление памяти в Huginn и как посчитать реальную цифру под свой набор агентов.

Что ест память в Huginn: Rails, воркер, планировщик и база

Huginn — это Ruby on Rails приложение, и это ключевой момент для расчёта RAM: сама платформа Rails — не лёгкий процесс. Ruby VM с загруженными гемами занимает заметный объём памяти ещё до того, как приложение начало что-либо делать. По факту Huginn в стандартной поставке — это не один процесс, а три логических роли:

• web — веб-интерфейс (Puma), через который вы создаёте и редактируете агентов, смотрите события;
• worker — обработчик фоновых задач, который реально выполняет работу агентов (сходить по URL, распарсить RSS, дёрнуть API);
• scheduler — планировщик, который по расписанию (every_1m, every_5m, every_1h и так далее) ставит задачи агентам в очередь.

В официальном docker-образе huginn/huginn все три роли по умолчанию поднимаются в одном контейнере через встроенный супервизор, но по памяти это не отменяет того, что фактически работают несколько отдельных Ruby-процессов. Каждый такой процесс на старте — это уже 150–300 МБ только на загрузку Rails-окружения и гемов, без единого выполненного задания. Дальше добавляется база данных (Huginn работает с PostgreSQL или MySQL) и, если вы используете более тяжёлые агенты, headless-браузер для JS-рендеринга страниц.

Отдельно стоит сказать про очередь фоновых задач: Huginn по умолчанию хранит их в самой базе данных (таблица отложенных заданий), а не в Redis — то есть отдельный Redis-контейнер для базовой установки не обязателен, и лишний повод сэкономить память вы получаете сразу. Если в вашей инсталляции Redis всё же поднят (например, для кастомных агентов или расширений), закладывайте под него ещё 50–100 МБ — сам Redis лёгкий, тяжелеет он только при большой очереди необработанных задач.

Сколько RAM нужно: ориентиры по числу и типу агентов

Точная цифра зависит от количества агентов, частоты их запуска и того, что именно они делают — просто дёргают JSON API раз в час или рендерят страницы в headless-браузере каждую минуту. Ниже — ориентировочные диапазоны, которые стоит воспринимать как отправную точку для планирования, а не как гарантированный потолок: у вас будет своя цифра в зависимости от нагрузки.

Ключевой момент, который часто упускают: узкое место — не число агентов само по себе, а количество одновременно выполняющихся задач и размер данных, которые они прогоняют через себя. Агент, который раз в час забирает JSON на 5 КБ, почти не заметен. Агент, который каждую минуту скрапит страницу через headless-браузер и сохраняет весь HTML в событие, за неделю может ощутимо раздуть и память воркера, и базу данных.

Если у вас уже есть похожий опыт с n8n — логика сайзинга там похожая: платформа автоматизации на Node.js/Rails сама по себе не бесплатна по памяти, и добавка идёт за каждый параллельный воркфлоу, а не просто за общее число созданных сценариев.

Docker Compose с лимитами памяти для Huginn

Практичный вариант развёртывания — Huginn в связке с отдельным контейнером PostgreSQL, оба с явными mem_limit, чтобы контейнер, ушедший в утечку или подвисшую задачу, не съел всю память сервера и не уронил соседние сервисы.

version: "3.8"

services:
  postgres:
    image: postgres:16-alpine
    restart: unless-stopped
    environment:
      POSTGRES_USER: huginn
      POSTGRES_PASSWORD: change_me
      POSTGRES_DB: huginn_production
    volumes:
      - huginn_pg:/var/lib/postgresql/data
    command: postgres -c shared_buffers=128MB -c max_connections=50 -c work_mem=8MB
    mem_limit: 512m

  huginn:
    image: huginn/huginn:latest
    restart: unless-stopped
    depends_on:
      - postgres
    environment:
      RAILS_ENV: production
      DATABASE_ADAPTER: postgresql
      DATABASE_HOST: postgres
      DATABASE_NAME: huginn_production
      DATABASE_USERNAME: huginn
      DATABASE_PASSWORD: change_me
      APP_SECRET_TOKEN: замените_на_сгенерированный_секрет
      TIMEZONE: Europe/Moscow
    ports:
      - "3000:3000"
    volumes:
      - huginn_data:/var/lib/huginn
    mem_limit: 1200m

volumes:
  huginn_pg:
  huginn_data:

Имена переменных окружения у образа Huginn менялись между релизами — перед разворачиванием сверьтесь с актуальным описанием образа, которое вы используете, чтобы не потерять данные из-за опечатки в названии переменной подключения к базе.

С такими лимитами (512 МБ на БД + 1.2 ГБ на приложение) суммарно выходит около 1.7 ГБ занятой памяти под пиковой нагрузкой — то есть комфортно чувствует себя VPS с 2 ГБ RAM для среднего набора агентов, и лучше сразу закладывать 4 ГБ, если планируете агентов с headless-рендерингом или десятки параллельных задач. Подробнее про то, как вообще работают mem_limit и cgroup-лимиты в Docker, — в статье про лимиты CPU и памяти в Docker.

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

Если сервер тесноват, а переезжать на тариф больше не хочется — есть несколько рабочих способов ужаться:

1. Ограничьте число параллельных воркеров. Чем меньше задач Huginn обрабатывает одновременно, тем ниже пиковое потребление памяти, ценой более медленной обработки очереди. Для небольших инсталляций это разумный компромисс.
2. Настройте MALLOC_ARENA_MAX=2 в переменных окружения контейнера — известный приём для Ruby/glibc-приложений, снижающий фрагментацию памяти при выделении/освобождении объектов в многопоточном режиме. Эффект не гарантирован на 100%, но на практике часто заметно сглаживает пики RSS.
3. Ограничьте keep_events_for в настройках агентов — старые события продолжают жить в базе и раздувать таблицу, из-за чего PostgreSQL требует больше памяти под кэш страниц для эффективной работы. Регулярная чистка старых событий — дешёвый способ держать базу компактной.
4. Избегайте параллельного запуска нескольких headless-браузерных агентов на одном сервере — разнесите их расписание так, чтобы не запускались одновременно. Один экземпляр Chromium в разы дороже по памяти, чем весь остальной стек Huginn вместе взятый.
5. Настройте своп-раздел как страховку, а не как основной ресурс — если о том, зачем и как это делать, у вас нет ясности, почитайте что делать при нехватке RAM: там разобраны и своп, и oom-killer, и как читать dmesg после падения процесса.

Важно понимать границу: своп спасает от разового всплеска, но не решает системную нехватку памяти — если Huginn регулярно упирается в лимит, это сигнал брать тариф с большим объёмом RAM, а не бесконечно тюнинговать конфиги.

Тюнинг PostgreSQL под небольшой VPS

Отдельная точка экономии — сама база данных. PostgreSQL по умолчанию рассчитан на серверные объёмы памяти и без тюнинга может занимать больше, чем нужно для скромной инсталляции Huginn. На VPS с 1–2 ГБ RAM разумные стартовые значения:

shared_buffers = 128MB       # обычно 25% от выделенной под БД памяти
work_mem = 8MB                # на сортировки/джойны; не завышайте — умножается на число соединений
maintenance_work_mem = 64MB
max_connections = 50          # Huginn не открывает сотни соединений на маленьких инсталляциях
effective_cache_size = 384MB

Если хотите разобраться в теме подробнее — общий подход к настройке описан в статье про тюнинг PostgreSQL на сервере (общие принципы применимы и к контейнерному развёртыванию, просто задавайте параметры не в postgresql.conf, а через аргументы команды postgres или volume с конфигом).

Держите max_connections вменяемым: каждое открытое соединение PostgreSQL — это дополнительная память на бэкенд-процесс, и если Huginn настроен с большим пулом на приложение, а max_connections на базе избыточен, вы просто резервируете память впустую.

Мониторинг: как заметить нехватку памяти до падения

Проще предупредить проблему, чем разбирать, почему контейнер внезапно перезапустился. Базовый набор проверок, которого достаточно для небольшой инсталляции:

# Текущее потребление по контейнерам в реальном времени
docker stats

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

# Если контейнер падал — ищите OOM в системном логе
dmesg -T | grep -i "out of memory"
journalctl -k | grep -i oom

Признаки того, что памяти уже не хватает: контейнер huginn периодически перезапускается без видимой причины в логах приложения (а в dmesg при этом есть запись про OOM), веб-интерфейс подвисает при попытке открыть список событий, очередь фоновых задач растёт быстрее, чем обрабатывается. Отдельно стоит поставить лёгкий мониторинг с алертами — если ресурсов на полноценный стек метрик жалко, достаточно простого скрипта с cron, который раз в 5–10 минут проверяет free -h и шлёт уведомление в Telegram при превышении порога.

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