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

MAATRIX

Официальная документация Chatwoot требует минимум 4 ГБ RAM, и на первом же запуске docker compose up многие видят, как сервер уходит в своп, а Sidekiq падает по OOM. Разберём, куда именно уходит память — по компонентам стека — и как подобрать реальный объём под ваш инбокс: от одного агента-фрилансера до саппорт-команды на 20 человек.

Из чего состоит Chatwoot и почему это не просто "одно приложение"

Chatwoot — это не монолит вроде WordPress, а связка из четырёх-пяти отдельных процессов, каждый со своим аппетитом к памяти:

• Rails-приложение (Puma) — веб-сервер, обслуживает и агентскую панель, и виджет чата на сайте клиента, и REST API. Именно он держит соединения агентов, у которых открыт дашборд.
• Sidekiq — фоновый воркер на той же кодовой базе Rails. Обрабатывает отправку писем, вебхуки, интеграции с Telegram/WhatsApp/Instagram, пересчёт отчётов. Грузит память отдельно от Puma, потому что это отдельный процесс с собственной копией Rails-окружения.
• PostgreSQL — основная БД: диалоги, контакты, сообщения, вложения (метаданные). Единственная база, обязательная для работы.
• Redis — очереди задач для Sidekiq, кеш сессий, счётчики непрочитанных. Без него Chatwoot не запустится вообще.
• (опционально) Elasticsearch — полнотекстовый поиск по диалогам. В официальном docker-compose из коробки не включён, добавляется отдельно и в старых версиях требовал от 512 МБ до 1+ ГБ heap — если у вас небольшая команда, лучше обойтись без него: поиск по PostgreSQL ILIKE работает медленнее, но памяти не просит.

Важный нюанс: Rails-процессы (Puma и Sidekiq) грузят в память весь код приложения и все гемы при старте — это создаёт "базовый вес" в 300–500 МБ на процесс ещё до обработки первого запроса. Дальше добавляется память под каждое воркер-соединение и под кеш ActiveRecord.

Официальный минимум и что происходит на практике

В документации Chatwoot указано: минимум 2 CPU и 4 ГБ RAM для продакшн-инсталляции через официальный install-скрипт (Docker Compose со всеми сервисами на одной машине). Это не маркетинговый минимум с запасом — это буквально порог, ниже которого docker compose up часто падает на этапе миграций базы или воркер убивается OOM killer.

Что происходит на разных объёмах памяти (без свопа, чистый RAM):

Цифры в таблице — ориентир по опыту эксплуатации, а не гарантированный бенчмарк: конкретное потребление сильно зависит от числа одновременных диалогов, размера истории переписок и того, сколько вебхуков/интеграций подключено. У вас может быть иначе — проверяйте по факту через docker stats.

Сколько памяти съедает каждый компонент отдельно

Если разложить типовую установку на 4 ГБ по процессам (данные из docker stats на среднем инбоксе с 2-3 активными агентами):

CONTAINER          MEM USAGE
chatwoot-rails      ~600-900 MiB
chatwoot-sidekiq    ~500-800 MiB
postgres            ~150-400 MiB (растёт с размером БД)
redis               ~30-80 MiB

PostgreSQL и Redis — самые предсказуемые: их потребление напрямую регулируется конфигом (shared_buffers, maxmemory), об этом ниже. А вот Rails-процессы — переменная величина, потому что каждый воркер Puma и каждый поток Sidekiq — это отдельный "клон" приложения в памяти. Именно тут находится главный рычаг тюнинга под конкретный объём RAM.

Тюнинг Puma и Sidekiq под доступную память

Chatwoot управляется переменными окружения, которые напрямую задают число параллельных процессов/потоков — а значит, и потребление памяти. Три ключевых параметра:

# .env для docker-compose
WEB_CONCURRENCY=1        # число процессов Puma (по умолчанию 1)
RAILS_MAX_THREADS=5      # потоков на процесс Puma
SIDEKIQ_CONCURRENCY=5    # потоков Sidekiq (не процессов!)

Логика простая: WEB_CONCURRENCY=1 — это один Puma-процесс с несколькими потоками. Каждый дополнительный процесс (WEB_CONCURRENCY=2) — это ещё одна полная копия загруженного Rails-приложения в памяти, то есть плюс 300-500 МБ. На серверах с 4 ГБ почти всегда есть смысл держать WEB_CONCURRENCY=1 и увеличивать RAILS_MAX_THREADS, а не количество процессов — потоки в рамках одного процесса делят загруженный код приложения и стоят намного дешевле по памяти.

SIDEKIQ_CONCURRENCY определяет число одновременных фоновых задач: чем выше, тем быстрее разгребаются очереди (например, массовая рассылка через кампании), но и тем больше открытых соединений к PostgreSQL и Redis. На 4 ГБ разумный диапазон — 5-10, на 8+ ГБ можно поднимать до 15-25.

Проверить реальное потребление после запуска:

docker stats --no-stream
# или для конкретного контейнера
docker exec -it chatwoot-rails-1 ps aux --sort=-rss | head -10

PostgreSQL и Redis: где урезать без потери надёжности

PostgreSQL по умолчанию (в конфиге из коробки в официальном docker-compose) настроен консервативно и не является узким местом на старте — проблемы начинаются, когда база разрастается до десятков тысяч сообщений. Базовые параметры, которые стоит выставить осознанно даже на небольшом сервере:

# postgresql.conf (или через параметры контейнера)
shared_buffers = 256MB        # ~25% от RAM, выделенной под Postgres
effective_cache_size = 768MB  # ~50-70% от RAM
work_mem = 8MB
maintenance_work_mem = 64MB

Это уже достаточно подробно раскрыто применительно к любому сервису на Postgres — если работаете с базой отдельно от Chatwoot, пригодится общий разбор в статье Redis или Memcached — что выбрать для сервера, где сравниваются подходы к кешу и оперативным данным.

Redis в Chatwoot используется не как кеш с вытеснением, а как очередь задач — это значит, что maxmemory-policy noeviction тут единственный безопасный вариант: если Redis начнёт вытеснять ключи под нагрузкой (allkeys-lru), Sidekiq может потерять задачи из очереди. Достаточно 128-256 МБ maxmemory для небольшой установки — Redis в Chatwoot не хранит историю сообщений, только очереди и сессии. Если сталкивались с ростом потребления Redis на других проектах, разбор причин есть в статье Redis: высокое потребление памяти — причины и решение.

Рабочий docker-compose с лимитами памяти

Официальный docker-compose Chatwoot не задаёт memory limits по умолчанию — это плохая идея на общем сервере, потому что один "разогнавшийся" Sidekiq-воркер может выесть всю память и уронить PostgreSQL через OOM killer. Добавьте deploy.resources (или mem_limit для Compose v2 без Swarm):

services:
  rails:
    image: chatwoot/chatwoot:latest
    mem_limit: 1200m
    environment:
      - WEB_CONCURRENCY=1
      - RAILS_MAX_THREADS=5

  sidekiq:
    image: chatwoot/chatwoot:latest
    mem_limit: 900m
    environment:
      - SIDEKIQ_CONCURRENCY=5

  postgres:
    image: postgres:15
    mem_limit: 700m

  redis:
    image: redis:7-alpine
    mem_limit: 256m
    command: redis-server --maxmemory 200mb --maxmemory-policy noeviction

Сумма лимитов (1200+900+700+256 ≈ 3 ГБ) сознательно не забивает всю RAM 4-гигабайтного сервера — системе, SSH-сессии и Docker-демону тоже нужна память. Если видите частые перезапуски контейнера rails или sidekiq в docker ps, это почти всегда сигнал упереться в mem_limit — проверяйте через docker inspect <container> | grep OOMKilled.

Свопом на такой конфигурации можно закрыть кратковременные пики (например, разовую массовую рассылку), но не системную нехватку RAM — если Sidekiq регулярно уходит в своп, это верный признак того, что 4 ГБ вашей нагрузке уже недостаточно. Базовая настройка swap для дистрибутивов на Debian/Ubuntu описана в статье Ubuntu 24.04: настройка swap и производительности с нуля.

Как масштабировать по мере роста команды

Chatwoot неплохо растёт вертикально — большинству команд до 20-30 агентов не нужен отдельный кластер, достаточно поднять RAM и аккуратно увеличить concurrency:

• 4 ГБ → 1-3 агента, 1-2 канала: WEB_CONCURRENCY=1, SIDEKIQ_CONCURRENCY=5, без Elasticsearch.
• 8 ГБ → 5-10 агентов, 3-5 каналов: можно поднять RAILS_MAX_THREADS=8, SIDEKIQ_CONCURRENCY=10, добавить отдельный контейнер под периодические отчёты.
• 16 ГБ → 15-25 агентов: имеет смысл вынести PostgreSQL на отдельный volume с быстрым диском, добавить Elasticsearch (от 1 ГБ heap отдельно), рассмотреть managed PostgreSQL вместо контейнера в том же compose-стеке.
• Дальше: разносить Rails/Sidekiq/PostgreSQL по разным серверам — это уже horizontal scaling, отдельная тема, актуальная при 50+ одновременных агентах.

Если вы уже держите на том же сервере другие Docker-сервисы (свою CRM, аналитику, почтовый релей), считайте RAM не только для Chatwoot, а суммарно — конкуренция за память между контейнерами Docker бьёт по отзывчивости первым делом.

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