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

MAATRIX

Miniflux рекламируют как самый лёгкий self-hosted RSS-ридер — и это почти правда: бинарник на Go без рантайма, без интерпретатора, без отдельного веб-сервера. Но «почти» здесь ключевое слово: единственная зависимость — PostgreSQL, и именно она, а не сам Miniflux, определяет реальный аппетит связки к памяти. Разберём, сколько RAM закладывать под личный поток из полусотни фидов и что меняется, когда подписок становится несколько сотен, а обновление идёт каждые 15 минут.

Почему Miniflux и правда лёгкий

Технически Miniflux — это один статический бинарник, скомпилированный из Go-кода. Никакого PHP-FPM с пулом воркеров, никакого Node.js с V8-хипом, который растёт от запроса к запросу, никакого интерпретатора вообще. Процесс стартует, резервирует небольшой стек памяти и держит его практически неизменным вне зависимости от того, сколько запросов обслуживает — горутины Go дешёвые, а сборщик мусора у рантайма предсказуемый и не склонен к резким скачкам, характерным для Node.js или Ruby.

На практике сам процесс miniflux в состоянии покоя занимает 20–40 МБ, и это число почти не меняется, будь у вас 10 подписок или 500. Разница появляется не в самом Miniflux, а в двух других местах:

• PostgreSQL — единственная поддерживаемая СУБД (SQLite и MySQL не поддерживаются в принципе, это осознанное архитектурное решение авторов), и именно она хранит все статьи, их полный текст, метаданные фидов и историю прочтения;
• Фоновый воркер обновления фидов — встроен в тот же бинарник, но при большом количестве источников и высокой параллельности запросов кратковременно поднимает потребление CPU и, в меньшей степени, памяти на время цикла опроса.

Официальная документация Miniflux заявляет о работе на серверах от 100 МБ RAM — и это не маркетинг, а честная цифра для связки с внешней, уже существующей PostgreSQL. Но если вы разворачиваете сервер под Miniflux с нуля, считать нужно вместе с базой, а не отдельно.

Личное чтение: до 100 фидов

Для личного использования — до сотни подписок, обновление раз в час, один читающий пользователь — типичная раскладка на VPS с 512 МБ–1 ГБ RAM выглядит так:

512 МБ технически хватает — многие держат Miniflux именно на таком тарифе годами без проблем. Но это без запаса: если под ту же машину вы добавите Nginx как reverse-proxy с SSL, cron-бэкапы или соседний контейнер, комфортнее взять 1 ГБ. На 1 ГБ вы забываете о памяти вообще — это тот случай, когда сервис настолько лёгкий, что разница между «работает» и «работает с запасом» стоит дешевле часа вашего времени на диагностику OOM.

# docker-compose.yml — минимальная связка на 512 МБ–1 ГБ RAM
version: "3"
services:
  db:
    image: postgres:16-alpine
    environment:
      POSTGRES_USER: miniflux
      POSTGRES_PASSWORD: changeme
      POSTGRES_DB: miniflux
    volumes:
      - miniflux-db:/var/lib/postgresql/data
    healthcheck:
      test: ["CMD", "pg_isready", "-U", "miniflux"]
      interval: 10s
      timeout: 5s
      retries: 5
    restart: unless-stopped

  miniflux:
    image: miniflux/miniflux:latest
    depends_on:
      db:
        condition: service_healthy
    environment:
      DATABASE_URL: postgres://miniflux:changeme@db/miniflux?sslmode=disable
      RUN_MIGRATIONS: 1
      CREATE_ADMIN: 1
      ADMIN_USERNAME: admin
      ADMIN_PASSWORD: changeme-too
    ports:
      - "8080:8080"
    restart: unless-stopped

volumes:
  miniflux-db:

Первый запуск с RUN_MIGRATIONS: 1 создаёт схему БД сам — отдельно накатывать миграции не нужно. Перед сервером стоит поставить обратный прокси с SSL, чтобы не открывать 8080 порт наружу — как это настроить, разобрано в статье Nginx как reverse-proxy на VPS.

Активное чтение: 300+ фидов и несколько пользователей

Когда счёт подписок идёт на сотни, а читателей на сервере несколько (семья, небольшая команда, публичный self-hosted инстанс для друзей), нагрузка растёт не столько на сам процесс Miniflux, сколько на PostgreSQL — из-за объёма хранимых статей и параллельности фонового опроса фидов.

Miniflux по умолчанию хранит полный текст статей (если не включена опция очистки контента после прочтения), и при 300–500 активных фидах с частым обновлением база за несколько месяцев легко разрастается до гигабайтов. Для такого сценария ориентир — 2 ГБ RAM:

• Miniflux — 50–100 МБ, рост умеренный за счёт большего числа одновременных HTTP-запросов к внешним фидам во время цикла опроса;
• PostgreSQL — 500 МБ–1 ГБ с адекватным shared_buffers под растущую базу статей;
• запас под ОС, бэкапы БД и возможные пики при массовом добавлении OPML-импорта.

Ключевая переменная, которая реально двигает нагрузку — WORKER_POOL_SIZE: количество параллельных воркеров, обновляющих фиды. По умолчанию 16, и при большом числе источников с медленными или недоступными серверами каждый воркер держит открытое соединение до таймаута — это нагружает скорее сеть и CPU, чем память, но при совсем тесном сервере стоит знать, где крутить рычаг:

# переменная окружения Miniflux
WORKER_POOL_SIZE=8       # меньше параллельных воркеров = меньше пиковая нагрузка
POLLING_FREQUENCY=60     # минуты между циклами опроса всех фидов
BATCH_SIZE=50            # сколько фидов обрабатывается за один проход воркера

Снижение WORKER_POOL_SIZE не экономит память напрямую в разы — эффект заметен в первую очередь на CPU и на скорости, с которой обновляется вся лента фидов за один цикл. На памяти это сказывается опосредованно, через меньшее число одновременно открытых сетевых соединений и буферов.

PostgreSQL: единственная точка, где стоит настраивать

Так как SQLite не поддерживается, а PostgreSQL обязателен даже для одного пользователя, именно её тюнинг — единственный реальный рычаг для управления памятью Miniflux-стека:

# postgresql.conf
shared_buffers = 128MB          # для сервера с 512 МБ–1 ГБ RAM
effective_cache_size = 384MB    # ориентир ОС+кэш, не жёсткий лимит
work_mem = 4MB
maintenance_work_mem = 32MB

Для сервера с 2 ГБ и растущей базой статей эти значения стоит увеличивать пропорционально — общее правило shared_buffers около 25% от общей RAM хоста, если PostgreSQL не делит машину с другими тяжёлыми сервисами. Подробный разбор установки и первичной настройки — в статье как установить и настроить PostgreSQL на VPS, а частые практические проблемы — в статье PostgreSQL на сервере: частые ошибки и решения.

Отдельный нюанс именно для Miniflux: если включить опцию CLEANUP_ARCHIVE_READ_DAYS (автоматическое удаление старых прочитанных статей), база не растёт бесконечно — это прямой способ держать объём данных, а значит и потребность в shared_buffers, под контролем на долгой дистанции, не жертвуя ничем в UX для типичного читателя RSS.

Сравнение с FreshRSS: похожая ниша, разная модель памяти

Miniflux часто сравнивают с FreshRSS как ближайшим конкурентом в нише self-hosted RSS-ридеров, и разница в модели памяти между ними принципиальная:

FreshRSS с SQLite формально может уложиться в чуть меньший объём для совсем небольшого личного использования — не нужен отдельный процесс PostgreSQL. Но Miniflux с PostgreSQL стабильнее ведёт себя под параллельной нагрузкой (несколько читателей одновременно, активное обновление фидов), поскольку не упирается в блокировки SQLite на запись. Если вы уже сравниваете варианты, детальный расчёт по FreshRSS — в статье как установить и настроить FreshRSS на VPS.

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

Сценарий нехватки памяти у Miniflux выглядит иначе, чем у Node.js- или Java-приложений: сам Go-бинарник крайне редко падает по OOM первым — его собственный расход стабилен и предсказуем. Обычно первой не выдерживает PostgreSQL, особенно на серверах с 512 МБ и меньше при одновременном пике (массовый OPML-импорт сотен фидов сразу, или цикл опроса совпал с ручным обновлением через веб-интерфейс).

Симптомы:

• в логах контейнера db появляются сообщения вида out of memory или could not fork new process;
• docker compose ps показывает контейнер БД в состоянии Restarting;
• Miniflux при этом продолжает отвечать на HTTP, но операции с базой (загрузка ленты, отметка прочитанного) начинают падать с ошибками 500.

Быстрая диагностика — docker stats в момент подозрения на пик, а системный лог ядра (dmesg | grep -i oom на хосте, не в контейнере) покажет, если сработал OOM-killer. Лечится либо увеличением RAM сервера, либо снижением shared_buffers у PostgreSQL и WORKER_POOL_SIZE у Miniflux как временной мерой. Общий подход к тому, какой запас закладывать сверх расчётного минимума на любом self-hosted сервисе — в статье сколько оперативной памяти закладывать с запасом.

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