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

MAATRIX

Первый вопрос, который встаёт при переносе команды со Slack на Mattermost — какой сервер под него брать. Официальная документация даёт вилку «от 4 GB», но на практике то ли не хватает при 50 пользователях, то ли простаивает половина памяти при пятистах. Разберём, из чего складывается потребление RAM в Mattermost, что скрыто съедает память сверх нормы и как посчитать бюджет под конкретную команду, а не гадать по общей таблице.

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

Mattermost — это не один процесс, а минимум связка из трёх компонентов, и память нужно считать по каждому отдельно, а не одной цифрой на «сервер»:

• Сервер приложения (написан на Go) — держит WebSocket-соединение с каждым онлайн-пользователем, кэширует сессии, каналы, права доступа. Память растёт с числом одновременно подключённых клиентов, а не с числом аккаунтов в системе — офлайн-пользователи почти ничего не стоят.
• PostgreSQL — хранит сообщения, файлы (метаданные, если файлы лежат не в базе), права, историю. Это отдельный процесс с собственным бюджетом памяти, и его часто забывают посчитать сверх памяти самого Mattermost.
• Поиск — по умолчанию Mattermost ищет через сам PostgreSQL (полнотекстовый поиск средствами БД), это экономит память, но медленнее на больших объёмах. Elasticsearch или OpenSearch как отдельный поисковый движок подключается опционально и добавляет собственный, довольно прожорливый процесс — обычно от 1-2 GB только под JVM.
• Файловое хранилище — если файлы лежат локально на диске (по умолчанию) или в S3/MinIO, само по себе на RAM почти не влияет, но при обработке превью изображений и видео кратковременно даёт всплески.
• Плагины и звонки (Calls) — отдельная история, разберём ниже, потому что именно они чаще всего ломают аккуратные расчёты «по табличке».

Если считать честно, минимальная конфигурация из Mattermost-сервера и PostgreSQL на одной машине — это база, а звонки, поиск и плагины — надстройка, которую нужно закладывать отдельно, если планируете ими пользоваться.

Сколько RAM нужно по размеру команды

Официальные рекомендации Mattermost ориентированы на количество зарегистрированных пользователей, но реальное потребление памяти сильнее зависит от того, сколько людей одновременно онлайн и как активно они пишут, шлют файлы и созваниваются. Ниже — ориентировочные цифры для сценария «обычный офисный чат без агрессивной нагрузки»: подставьте свои значения, если у вас много вложений или постоянных видеозвонков.

Это именно ориентир, а не гарантия — у команды с активным использованием тредов, реакций, интеграций с ботами (например, бота для модерации чата в похожей логике) и десятками каналов профиль нагрузки будет заметно тяжелее, чем у команды того же размера, которая просто переписывается текстом. Практический подход: берите нижнюю границу диапазона под свой размер команды, ставьте мониторинг памяти с первого дня и наращивайте, если видите, что резерв стабильно тает.

Отдельно держите в голове, что для команды до 50-100 человек вполне хватает одного VPS на 4-8 GB RAM с Mattermost и PostgreSQL на одной машине через Docker Compose — разносить сервисы по разным серверам на этом масштабе избыточно и только добавляет сетевых задержек.

PostgreSQL: отдельный бюджет памяти, который часто забывают

PostgreSQL под Mattermost — не «мелкая база», а полноценная СУБД со своими настройками потребления памяти. Дефолтная конфигурация из коробки (shared_buffers = 128MB) рассчитана на слабое железо и на реальной нагрузке будет тормозить поиск и загрузку истории каналов.

Базовые ориентиры для тюнинга postgresql.conf под Mattermost:

# при выделенных под PostgreSQL 4 GB RAM
shared_buffers = 1GB          # обычно 25% от RAM, отданной под Postgres
effective_cache_size = 3GB    # 50-75% от RAM — подсказка планировщику, не резервирование
work_mem = 16MB                # на сложные запросы поиска; при max_connections больших значений — осторожнее
maintenance_work_mem = 256MB
max_connections = 100          # Mattermost сам держит пул соединений, 100-200 обычно достаточно

Ключевой момент: work_mem умножается на число одновременных операций сортировки/хеширования, а не выделяется один раз — при 100 подключениях и work_mem = 64MB можно легко уйти в OOM на пике поисковых запросов. Если база растёт быстро или тормозит на поиске по истории, подробный разбор параметров — в статье про тюнинг PostgreSQL и частые ошибки, там же про autovacuum, который на Mattermost с активными тредами и реакциями работает заметно чаще, чем на «спокойной» базе.

Если разворачиваете PostgreSQL впервые именно под этот проект, порядок установки и базовая настройка — в статье как установить и настроить PostgreSQL на VPS.

Звонки, плагины и интеграции — скрытые потребители RAM

Табличные расчёты выше не учитывают то, что реально ломает бюджет памяти на практике:

• Mattermost Calls — встроенный видеозвонок работает через SFU-медиасервер (mediasoup), который живёт в отдельном процессе внутри контейнера Mattermost. Каждый параллельный звонок с несколькими участниками добавляет ощутимую нагрузку и на CPU, и на RAM — заранее закладывайте отдельный запас, если в команде принято созваниваться группами по 5-10 человек одновременно, а не считайте звонки «бесплатным довеском» к чату.
• Elasticsearch/OpenSearch — если подключаете для полнотекстового поиска на больших объёмах истории, это отдельная JVM с собственными требованиями к heap-памяти, обычно от 1-2 GB и вверх в зависимости от объёма индекса. Не ставьте на ту же машину, где и так впритык с RAM.
• Плагины (GitHub, Jira, Zoom-интеграции, кастомные боты через API) — большинство лёгкие, но плагины с собственным state или частым polling внешних API постепенно накапливают память между рестартами контейнера. Если ставите много плагинов, закладывайте +10-20% к базовому расчёту.
• Webhooks и боты — сами по себе почти не грузят Mattermost, но при высокой частоте сообщений (например, алерты мониторинга, льющиеся потоком) стоит следить за очередью уведомлений — она держится в памяти до отправки.

Практическое правило: если в команде активно используются звонки и больше 10-15 плагинов, накидывайте к цифрам из таблицы выше ещё 30-50% сверху, а не рассчитывайте впритык.

Docker Compose: как выставить лимиты и не словить внезапный OOM

Большинство self-hosted инсталляций Mattermost разворачивают через Docker Compose. Без явных лимитов памяти контейнеры по умолчанию могут использовать всю RAM хоста — это удобно, пока не начнётся конкуренция между Mattermost и PostgreSQL за одну и ту же память на пике нагрузки.

Минимальный рабочий пример с лимитами под сервер на 8 GB:

services:
  mattermost:
    image: mattermost/mattermost-team-edition:10.5
    mem_limit: 3g
    mem_reservation: 1.5g
    environment:
      - MM_SQLSETTINGS_DATASOURCE=postgres://mmuser:mmpass@postgres:5432/mattermost?sslmode=disable
    depends_on:
      - postgres
    volumes:
      - ./data:/mattermost/data
      - ./config:/mattermost/config
      - ./logs:/mattermost/logs
    ports:
      - "8065:8065"
    restart: unless-stopped

  postgres:
    image: postgres:16
    mem_limit: 3g
    shm_size: 256mb
    environment:
      - POSTGRES_USER=mmuser
      - POSTGRES_PASSWORD=mmpass
      - POSTGRES_DB=mattermost
    volumes:
      - ./pgdata:/var/lib/postgresql/data
    restart: unless-stopped

mem_limit — жёсткий потолок: контейнер, упёршийся в него, получит SIGKILL от ядра, а не мягко замедлится. mem_reservation — мягкая граница для планировщика при конкуренции ресурсов, полезна, если на том же хосте крутятся другие сервисы. Общие принципы выставления таких лимитов и типичные ошибки разобраны в статье про лимиты CPU и памяти в Docker — там же про то, почему лимит впритык к реальному потреблению хуже, чем лимит с запасом 20-30%.

Проверить фактическое потребление и убедиться, что лимиты не занижены:

docker stats --no-stream mattermost postgres
free -h
dmesg -T | grep -i "killed process"
docker inspect mattermost --format='{{.State.OOMKilled}}'

Если последняя команда вернула true — контейнер уже упирался в лимит, и цифру mem_limit пора поднимать, а не списывать падение на «глюк».

Когда пора выносить PostgreSQL на отдельный сервер

Пока команда укладывается в пару сотен активных пользователей, Mattermost и PostgreSQL прекрасно живут на одной машине. Сигналы, что пора разделять:

• PostgreSQL стабильно занимает больше половины доступной RAM хоста даже после тюнинга shared_buffers.
• docker stats показывает, что при пиках (утренний наплыв сообщений, массовые созвоны) оба контейнера одновременно упираются в лимиты.
• Появилась потребность в High Availability — Mattermost Enterprise поддерживает кластер из нескольких нод приложения за балансировщиком, но все ноды должны ходить в одну и ту же базу, и тогда она физически обязана жить отдельно.
• Растёт объём файлов и истории настолько, что бэкапы базы начинают заметно нагружать диск и память во время снимка — вынос БД снимает эту конкуренцию с самим чатом.

Для команды от 500-1000 человек разумная схема — Mattermost-сервер отдельно, PostgreSQL отдельно (можно с репликой на чтение), опционально Elasticsearch третьим узлом. Для команд с чувствительными к юрисдикции данными и требованием держать сервер конкретно в России, США или Великобритании стоит заранее прикинуть, где физически будет жить каждый узел — разбор вариантов есть в статье VPS в России для мессенджеров и звонков.

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