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

MAATRIX

Discourse — стандартный выбор, если вы делаете форум сообщества open-source проекта, техническую поддержку или базу знаний с обсуждениями. Официальная документация прямо говорит: меньше 2 GB RAM даже не пытайтесь — установка просто не соберётся. Но 2 GB — это порог входа, а не комфортная эксплуатация, и разница между «стартует» и «нормально работает под живой нагрузкой» может быть в разы. Разберём, сколько памяти реально нужно на каждом этапе — от ./launcher rebuild app до форума на несколько тысяч активных участников.

Почему у Discourse минимум 2 GB, а не 512 MB

Discourse — это Ruby on Rails приложение, и уже сам по себе Rails прожорливее, чем условный Go- или Node-сервис из той же категории self-hosted сайтов. Но основная причина жёсткого порога в 2 GB не в рантайме, а в процессе сборки.

Discourse ставится и обновляется через ./launcher rebuild app — это не просто docker pull новой версии, а полная пересборка образа: компиляция ассетов (JS, CSS через Ember CLI), миграции базы, прекомпиляция Rails-приложения. На этом этапе кратковременно нужно 1.5-2 GB RAM только под сам процесс сборки, помимо памяти, которую уже держат Postgres и Redis внутри контейнера. На сервере с 1 GB RAM без свопа rebuild падает по OOM практически гарантированно, и это самая частая жалоба новичков на форумах поддержки Discourse.

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

• Unicorn/Puma-воркеры Rails — обрабатывают HTTP-запросы, по умолчанию несколько воркеров, каждый держит свою копию загруженного приложения (порядка 200-400 MB на воркер в зависимости от версии и плагинов).
• PostgreSQL — хранит темы, посты, пользователей, полнотекстовые индексы для поиска. Растёт с объёмом контента и историей форума.
• Redis — кэш сессий, счётчики непрочитанного, очередь заданий для Sidekiq. Обычно некритичен по памяти, если форум не огромный.
• Sidekiq — фоновые задания: отправка email-уведомлений, генерация превью ссылок, пересчёт статистики бейджей, индексация поиска. Держит собственный пул воркеров и может давать заметные пики при массовой рассылке digest-писем.

Все эти компоненты по умолчанию живут в одном Docker-контейнере через sv (runit) — это официальный способ установки Discourse, и именно он держит суммарный бюджет памяти, который вы считаете как единое целое.

Сколько RAM нужно по размеру сообщества

Официальные рекомендации Discourse ориентированы на количество активных пользователей в месяц, но точнее считать по одновременно активным читателям и постящим — именно они держат открытые соединения и генерируют нагрузку на Rails и Postgres.

Это ориентир, а не гарантия — форум с активной модерацией, множеством плагинов (например, для голосований, кастомных полей профиля, интеграций с Discord или Slack) и агрессивной индексацией для поиска будет заметно тяжелее форума того же размера пользователей, которые просто читают темы без глубокого вовлечения. Официальная минимальная рекомендация Discourse для продакшна — 8 GB, и если вы разворачиваете форум не для теста, а для реального сообщества, отталкивайтесь именно от неё, а не от абсолютного минимума в 2 GB.

PostgreSQL внутри Discourse: тюнинг под свои плагины

PostgreSQL в стандартной установке Discourse настраивается автоматически конфигом discourse.pgtune, который сам подбирает параметры под объём RAM, доступной контейнеру — это удобно и в большинстве случаев работает сразу неплохо. Но если вы плотно используете плагины с активным поиском по большим темам или у форума выросла база до сотен тысяч постов, стоит свериться с параметрами вручную.

Посмотреть текущие настройки внутри контейнера:

./launcher enter app
sudo -u postgres psql -c "SHOW shared_buffers;"
sudo -u postgres psql -c "SHOW work_mem;"
sudo -u postgres psql -c "SHOW effective_cache_size;"

Ориентировочные значения, которые pgtune обычно выставляет для контейнера с выделенными 4 GB RAM:

shared_buffers = 1GB           # около 25% от RAM, выделенной контейнеру
effective_cache_size = 3GB     # 50-75% от RAM, подсказка планировщику запросов
work_mem = 20MB                 # на операции сортировки/хеширования в запросах
maintenance_work_mem = 256MB
max_connections = 200           # Discourse держит собственный пул через PgBouncer-подобный механизм

Если форум тормозит на поиске по большим темам или растёт время ответа при массовых операциях (например, пересчёт бейджей по всей базе ночью), это чаще вопрос настроек PostgreSQL, чем нехватки RAM как таковой — подробный разбор параметров и типичных ошибок есть в статье про тюнинг PostgreSQL и частые ошибки. Отдельно стоит следить за autovacuum — на форуме с активными реакциями (лайки на посты) и постоянными UPDATE счётчиков таблицы разрастаются быстрее, чем кажется на глаз, и подробнее об этом — в статье про медленный vacuum в PostgreSQL.

Redis и Sidekiq: где прячутся всплески памяти

Redis в Discourse редко становится узким местом по памяти сам по себе — типичное потребление на среднем форуме укладывается в 100-300 MB. Но есть нюансы, которые ломают аккуратные расчёты «по табличке»:

• Очередь Sidekiq при массовой рассылке. Когда включена ежедневная email-дайджест-рассылка на большую базу подписчиков или когда после долгого простоя форума накапливается очередь отложенных уведомлений, Sidekiq может кратковременно раздуть память Redis и собственных воркеров в разы относительно базового уровня. Если видите резкий скачок памяти по ночам — почти наверняка это плановая рассылка дайджестов, а не утечка.
• Кэш полнотекстового поиска и hot-данные. При интенсивном использовании поиска Redis кэширует горячие результаты, и на форумах с десятками тысяч постов это добавляет ощутимый, но предсказуемый прирост.
• Плагины с собственными очередями. Некоторые сторонние плагины Discourse заводят свои Sidekiq-задания (например, интеграции с внешними CRM или синхронизация с Discord) — это дополнительная, часто не задокументированная нагрузка на Redis и воркеры.

Если Redis у вас уже выведен за пределы discourse-контейнера в рамках более крупной инфраструктуры или вы просто хотите разобраться в его поведении под нагрузкой отдельно, общие принципы диагностики высокого потребления памяти разобраны в статье Redis: высокое потребление памяти — многое из неё применимо и к инстансу Redis внутри Discourse-контейнера.

app.yml: где выставить лимиты и не словить OOM на rebuild

Стандартная установка Discourse через discourse_docker использует containers/app.yml как единый конфиг для всего стека. Явных mem_limit там по умолчанию нет — контейнер может занять всю доступную память хоста, что удобно в спокойном режиме, но опасно именно в момент rebuild, когда одновременно работают компиляция ассетов, миграции и обычная нагрузка от живых пользователей, если форум не уходит в даунтайм на пересборку.

Фрагмент app.yml, где обычно настраивают память под воркеры Unicorn — сам процесс сборки лимитом не ограничивается, но число воркеров напрямую определяет базовый бюджет памяти в рабочем режиме:

env:
  UNICORN_WORKERS: 3
  DISCOURSE_DB_POOL: 25
  RAILS_MAX_THREADS: 8

Меньше воркеров — меньше памяти в простое, но ниже параллелизм при пиковой нагрузке. Правило для сервера с 4 GB RAM — 2-3 воркера, для 8 GB — 4-6, дальше нужно смотреть по факту через docker stats, а не следовать одной цифре для всех конфигураций.

Проверка потребления и признаков нехватки памяти:

docker stats --no-stream app
free -h
dmesg -T | grep -i "killed process"

Если rebuild падает по OOM на сервере с малым объёмом RAM, временный обходной путь — добавить swap перед пересборкой (это не решает проблему на постоянной основе, но даёт rebuild шанс завершиться):

sudo fallocate -l 2G /swapfile
sudo chmod 600 /swapfile
sudo mkswap /swapfile
sudo swapon /swapfile

Подробнее о том, как правильно настроить своп и не превратить его в постоянную заплатку вместо апгрейда RAM — в статье своп-файл: когда нужен и как настроить. Держать Postgres на постоянном свопе — плохая идея: задержки диска резко растут под нагрузкой, и форум начинает тормозить на каждом запросе к базе.

Когда выносить PostgreSQL и Redis из контейнера

Пока форум укладывается в несколько тысяч активных пользователей, весь стек Discourse прекрасно живёт в одном контейнере на одном сервере — это официально поддерживаемая и самая простая в обслуживании схема. Сигналы, что пора разделять сервисы:

• PostgreSQL стабильно занимает больше половины RAM, выделенной контейнеру, даже после ручной проверки pgtune-конфига.
• rebuild регулярно падает по OOM даже с временным свопом, и апгрейд RAM на том же сервере уже упирается в потолок тарифа.
• Форум растёт за пределы 20-30 тысяч активных пользователей в месяц, и пики Sidekiq (массовые рассылки, ночная переиндексация) начинают конкурировать с живым трафиком за одну и ту же память.
• Нужна отказоустойчивость — Discourse официально поддерживает вынос PostgreSQL и Redis на отдельные хосты через переменные в app.yml (DISCOURSE_DB_HOST, DISCOURSE_REDIS_HOST), это штатный сценарий для крупных инсталляций, а не хак.

Для форума такого масштаба разумная схема — отдельный сервер под сам Discourse-контейнер, отдельный под PostgreSQL (можно с репликой на чтение для поиска и статистики), Redis можно оставить на сервере приложения дольше остальных — он редко становится узким местом первым. Если на растущем форуме уже видите первые признаки нехватки памяти и не уверены, оптимизировать конфиг или сразу добавлять RAM — пошаговая диагностика и решения разобраны в статье что делать при нехватке RAM.

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