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

MAATRIX

Если вы прикидываете, какой VPS брать под FreshRSS, скорее всего уже решили для себя главный вопрос — что читать ленты в чужом облачном сервисе с рекламой и чужой аналитикой не хочется, и ищете замену Google Reader на своих условиях. Хорошая новость: FreshRSS — один из самых экономных self-hosted сервисов вообще, и переплачивать за память здесь почти не за что. Ниже — реальные цифры по RAM в зависимости от числа подписок, способа хранения данных и того, читаете вы ленты в одиночку или заводите агрегатор на всю команду.

Что за нагрузку создаёт FreshRSS

FreshRSS — это PHP-приложение, которое делает две вещи: по расписанию скачивает RSS/Atom-ленты (обычно через cron раз в 15-60 минут) и отдаёт статьи через веб-интерфейс и API (совместимое с Fever и Google Reader — это то, что позволяет подключать мобильные клиенты вроде Reeder, NetNewsWire или ReadYou). Никакого постоянно работающего демона, который жуёт память в фоне — PHP-FPM просыпается на HTTP-запрос или на cron-джобу обновления лент и снова засыпает.

По потреблению ресурсов FreshRSS ближе к лёгким PHP-инструментам вроде Baïkal, чем к тяжёлым комбайнам вроде Nextcloud, где крутится десяток модулей, генератор превью и очереди фоновых задач. Здесь всё проще: получил XML по HTTP, распарсил, сохранил в базу, отдал клиенту. Самая тяжёлая операция — это как раз периодическое обновление лент, когда PHP одновременно ходит в сеть за десятками источников и парсит ответы, но и она укладывается в единицы-десятки мегабайт пиковой нагрузки на процесс.

Если вы ещё не разворачивали FreshRSS и решаете, ставить его вручную или через готовый образ, у нас есть отдельные материалы — пошаговая установка на Ubuntu 24.04 и общий разбор установки и настройки FreshRSS на VPS с SSL и API для мобильных клиентов.

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

Реальное потребление RAM на сервере с FreshRSS — это сумма нескольких компонентов, а не только сам PHP-процесс:

• PHP-FPM воркеры — каждый активный воркер держит 15-35 МБ в зависимости от набора расширений (pdo_sqlite/pdo_mysql, curl, xml, mbstring, intl). При пуле из 3-5 воркеров это 60-150 МБ.
• Веб-сервер — nginx перед PHP-FPM берёт 5-15 МБ базово плюс 1-3 МБ на воркер-процесс. Это стандартная и самая лёгкая связка для FreshRSS.
• Cron-обновление лент — команда php cli/actualize_script.php запускается по расписанию и на время своей работы (обычно 5-30 секунд в зависимости от числа фидов) занимает отдельный процесс с расходом 20-60 МБ, который освобождается сразу после завершения.
• База данных — SQLite не создаёт отдельного процесса вообще, база — это файл. MySQL/MariaDB — это mysqld, который в простое держит 150-300 МБ независимо от того, сколько у вас статей.
• ОС и системные службы — минимальный Ubuntu/Debian без графики съедает 100-200 МБ на ядро, systemd, cron, sshd.

Итог: чистый FreshRSS на SQLite с обновлением по cron — одна из самых лёгких self-hosted связок, которую вообще можно поставить на VPS.

Минимальная конфигурация: 512 МБ

Для личного чтения (одиночный пользователь, до 100-150 подписок) хватает VPS с 512 МБ RAM. На таком объёме реально живут:

• Debian 12 или Ubuntu 24.04 minimal — около 120-150 МБ в простое;
• nginx + php8.3-fpm с пулом на 2-3 воркера — 50-90 МБ;
• FreshRSS на SQLite — база в файле data/users/<login>/db.sqlite, отдельного процесса СУБД нет;
• cron-обновление лент раз в 30-60 минут — кратковременный всплеск на время выполнения скрипта;
• swap 512 МБ-1 ГБ как страховка на случай, если обновление большого числа лент совпадёт с чужим запросом к веб-интерфейсу.

Оговорка сразу: 512 МБ — это конфигурация без запаса под что-то ещё на том же сервере. Если планируете добавить туда VPN, второй сайт или бота — закладывайте больше. Для отдельного изолированного VPS под один FreshRSS это рабочий и проверенный вариант — мы регулярно видим такие связки живыми месяцами без единого OOM.

Таблица: сколько RAM закладывать по сценарию

Цифры ниже — практический ориентир для типовой связки nginx + PHP-FPM + SQLite/MySQL, у вас может отличаться в зависимости от числа PHP-модулей, частоты cron и количества подписок — считайте это отправной точкой, а не гарантией.

Ключевой параметр здесь — не число пользователей, а суммарное число лент и частота их обновления. Один пользователь с 500 активными фидами на cron каждые 15 минут создаёт больше сетевой и парсинг-нагрузки, чем пять пользователей с умеренным набором подписок и обновлением раз в час. Если у вас много «тяжёлых» источников с крупными XML-фидами (агрегаторы новостей, YouTube-каналы через RSS-мост) — закладывайте на ступень выше.

SQLite vs MySQL/MariaDB для FreshRSS

При первой настройке через веб-мастер FreshRSS сам предлагает выбрать СУБД. Разница по памяти и удобству ощутимая:

SQLite — база в одном файле на пользователя, никакого отдельного процесса. Плюсы: минимальный расход RAM, нулевая настройка, простой бэкап (скопировал файл — перенёс всю базу подписок и прочитанных статей). Минусы: при большом числе одновременных пользователей, активно листающих ленту одновременно с фоновым cron-обновлением, SQLite сериализует блокировки записи на уровне файла — для личного и малогруппового использования это практически никогда не заметно.

MySQL/MariaDB — отдельный процесс mysqld, добавляющий 150-300 МБ постоянного расхода даже без единого запроса. Плюсы: лучше держит параллельную нагрузку многих пользователей, привычнее для регулярных бэкапов через mysqldump, логичный выбор, если на сервере уже крутится MySQL под другие проекты (тогда FreshRSS просто заводит свою базу в существующем инстансе без второго mysqld).

Практический вывод: для личного или семейного использования берите SQLite и не тратьте память впустую. MySQL имеет смысл разворачивать, если у вас уже есть СУБД на сервере для других сервисов, либо число одновременных пользователей и лент реально большое.

Docker Compose и лимиты памяти

Если разворачиваете FreshRSS через Docker (официальный образ freshrss/freshrss), разумно сразу поставить mem_limit, чтобы контейнер не разрастался бесконтрольно:

services:
  freshrss:
    image: freshrss/freshrss:latest
    container_name: freshrss
    restart: unless-stopped
    ports:
      - "8080:80"
    environment:
      - TZ=Europe/Moscow
      - CRON_MIN=*/30
    volumes:
      - ./data:/var/www/FreshRSS/data
      - ./extensions:/var/www/FreshRSS/extensions
    deploy:
      resources:
        limits:
          memory: 256M
        reservations:
          memory: 96M

Переменная CRON_MIN задаёт частоту автообновления лент прямо внутри контейнера — не нужен внешний cron. Для варианта с MySQL добавляется отдельный контейнер базы:

  db:
    image: mariadb:11
    restart: unless-stopped
    environment:
      MYSQL_ROOT_PASSWORD: change_me
      MYSQL_DATABASE: freshrss
      MYSQL_USER: freshrss
      MYSQL_PASSWORD: change_me_too
    volumes:
      - ./mysql-data:/var/lib/mysql
    deploy:
      resources:
        limits:
          memory: 384M

С такой связкой (FreshRSS-контейнер + MariaDB) закладывайте VPS от 1 ГБ, чтобы под ОС и Docker-демон осталось хотя бы 300-400 МБ — сама контейнеризация добавляет 50-100 МБ накладных расходов сверх голого процесса. Если вы впервые настраиваете прод-окружение с Docker Compose, общий порядок (сети, restart-политики, лимиты памяти) разобран в статье про пошаговую установку Docker Compose на Ubuntu 24.04.

Оптимизация PHP-FPM и cron под ограниченную память

На сервере с 512 МБ-1 ГБ главный рычаг экономии — пул PHP-FPM в /etc/php/8.3/fpm/pool.d/www.conf:

pm = dynamic
pm.max_children = 4
pm.start_servers = 2
pm.min_spare_servers = 1
pm.max_spare_servers = 3
pm.max_requests = 500

pm.max_children ограничивает число одновременных PHP-процессов сверху. Для FreshRSS с редкими короткими веб-запросами и периодическим cron-обновлением 4 воркеров с запасом хватает даже при активном личном использовании — веб-интерфейс и cron почти никогда не нагружают сервер синхронно на пике. pm.max_requests перезапускает воркер после N обработанных запросов, что подчищает медленные утечки памяти в самом PHP почти без потерь в производительности.

Второй рычаг — частота cron-обновления лент. Значение */60 (раз в час) вместо */15 (раз в 15 минут) в разы снижает суммарную сетевую и CPU-нагрузку ценой чуть менее свежих статей — для большинства читателей разница в актуальности между 15 и 60 минутами не критична. Третий рычаг — отключить неиспользуемые PHP-расширения: FreshRSS реально нужны pdo_sqlite или pdo_mysql, curl, xml, mbstring, gd (для миниатюр), intl (если нужна многоязычность интерфейса) — остальное можно убрать из php.ini.

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

Прежде чем брать тариф побольше, проверьте реальное потребление:

free -h
docker stats --no-stream   # если через Docker
systemctl status php8.3-fpm

Если своп используется стабильно, а не разово во время пикового cron-обновления — это сигнал реального дефицита, а не запас на будущее. Типичные признаки нехватки памяти у FreshRSS: PHP-FPM пишет в лог WARNING: [pool www] server reached pm.max_children, обновление лент по cron начинает занимать заметно дольше обычного или обрывается по таймауту, dmesg показывает killed-процессы через OOM killer при совпадении веб-запроса и cron-джобы.

Если ресурсов не хватает — сначала снизьте pm.max_children, увеличьте интервал cron-обновления и добавьте своп (это быстро и бесплатно), и только если проблема сохраняется при разумной нагрузке — переходите на VPS с большим объёмом RAM. Для FreshRSS это требуется редко: даже активные личные развёртывания с сотнями лент стабильно держатся в 1 ГБ, если не тащить на том же сервере что-то более тяжёлое.

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