Сколько RAM нужно для Matrix (Synapse)

MAATRIX

Synapse — эталонная реализация протокола Matrix, и она же самая прожорливая по памяти из всех совместимых серверов. Официальная документация Matrix.org честно предупреждает: 512 МБ хватит только на пустой сервер без единого пользователя, а реальная цифра сильно зависит не от числа ваших учётных записей, а от того, в каких публичных комнатах федерации вы состоите. Ниже — из чего складывается расход памяти на практике и сколько закладывать под конкретный сценарий, от личного хаба до сервера с активной федерацией.

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

Synapse написан на Python поверх асинхронного фреймворка Twisted, и это первая причина его аппетита: интерпретируемый Python с GIL держит в памяти существенно больше, чем сопоставимый по функциям сервис на компилируемом языке. Сам процесс synapse-homeserver в покое без единого клиента занимает 300-500 МБ — это уже базовая стоимость запуска, до всякой полезной нагрузки.

Дальше память набирается по нескольким направлениям:

• Кеши состояния комнат (state cache) — Synapse держит в памяти текущее состояние (список участников, права, топик) для активных комнат, чтобы не ходить в базу на каждое сообщение.
• Кеш событий (event cache) — последние сообщения и метаданные, размер задаётся через caches.global_factor в конфиге.
• Соединения с PostgreSQL — пул подключений плюс буферы на стороне самого Synapse под ответы запросов.
• HTTP-клиент для федерации — исходящие и входящие запросы к другим серверам Matrix, включая retry-очереди при недоступности удалённых хомсерверов.
• Media repository — если сервер сам раздаёт и кеширует превью медиафайлов, а не проксирует их на CDN.

Проверить фактическое потребление процесса:

sudo apt install -y smem
sudo smem -t -k -P 'synapse|postgres' -c 'name pss rss'

PSS честнее RSS: Python-процессы Synapse активно используют разделяемые библиотеки, и RSS может завышать картину, особенно если у вас несколько worker-процессов.

Сколько RAM нужно: от личного сервера до комьюнити

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

Цифры ориентировочные — точный расход зависит от того, в какие комнаты федерации вступают ваши пользователи, а не только от их числа. Сервер с одним пользователем, который состоит в комнате на 50 000 участников Matrix HQ, реально ест больше памяти, чем сервер с десятком пользователей в закрытых чатах. Проверяйте фактическое потребление после недели работы, а не только на старте.

PostgreSQL — обязательное условие, не опция

Synapse формально поддерживает SQLite, и на этом стоит остановиться отдельно: SQLite годится только для локального теста на несколько минут. Сама документация Matrix.org прямо не рекомендует SQLite для production — однопоточная блокировка на запись означает, что при федерации с несколькими серверами одновременно синхронизация начинает подвисать, а с ростом базы (state-таблицы растут особенно быстро) производительность деградирует нелинейно.

PostgreSQL обязателен уже для сервера с федерацией. Базовый конфиг подключения в homeserver.yaml:

database:
  name: psycopg2
  args:
    user: synapse_user
    password: ваш_пароль
    dbname: synapse
    host: 127.0.0.1
    cpu_limit: -1
    keepalives_idle: 10
    keepalives_interval: 10
    keepalives_count: 3

PostgreSQL — отдельный процесс со своим потреблением памяти, и на сервере с 4-8 ГБ его нужно явно ограничивать, иначе он и Synapse начинают конкурировать за одну и ту же RAM:

# /etc/postgresql/16/main/postgresql.conf
shared_buffers = 1GB          # 25% от RAM, выделенной под Postgres
effective_cache_size = 3GB    # 75% от той же доли
work_mem = 16MB
maintenance_work_mem = 256MB

На сервере с 4 ГБ разумное деление — около 1-1,5 ГБ под PostgreSQL, остальное под Synapse и систему. Подробный разбор параметров и типовых ошибок настройки — в статье тюнинг PostgreSQL на сервере; если база ставится с нуля, пригодится пошаговая установка PostgreSQL на Ubuntu 24.04.

Федерация и большие публичные комнаты — главный пожиратель памяти

Это специфика именно Matrix, которой нет у изолированных мессенджеров вроде Rocket.Chat или Mattermost. Протокол построен на state resolution — алгоритме, который при получении события из федерации пересчитывает текущее состояние комнаты, сверяя его с версиями, известными разным серверам. Чем больше участников в комнате и чем активнее в ней меняются права/топики/список участников, тем тяжелее и чаще идёт этот пересчёт.

Публичные комнаты с тысячами участников (типичный пример — технические комьюнити на Matrix HQ или крупные open-source проекты) создают ощутимую фоновую нагрузку даже если ваши локальные пользователи в этих комнатах молчат: сервер обязан обрабатывать входящие события федерации и участвовать в state resolution наравне со всеми остальными серверами-участниками.

Что реально помогает держать память под контролем:

# homeserver.yaml — ограничение кешей под доступную RAM
caches:
  global_factor: 0.5
  per_cache_factors:
    get_users_who_share_room_with_user: 2.0

federation_sender_instances: null

global_factor ниже 1.0 снижает размер всех кешей событий и состояния пропорционально — платите за это чуть большей задержкой при обращении к недавней истории, но избегаете OOM на пиках федерационного трафика. Занижать сильно ниже 0.5 не стоит: сервер начинает чаще ходить в PostgreSQL за тем, что раньше отдавал из памяти, и это заметно на отзывчивости клиентов.

Дополнительно снижает нагрузку отказ от лишних публичных комнат для тестовых аккаунтов и явное ограничение rc_federation — лимитов на входящий федерационный трафик, если сервер явно захлёбывается запросами от конкретных удалённых хомсерверов.

Workers: масштабирование Synapse на несколько процессов

Когда один процесс Synapse упирается в потолок — типично это происходит уже на 8-16 ГБ при активной федерации — следующий шаг не «добавить ещё RAM», а разнести нагрузку по нескольким процессам-workers. Это штатная возможность Synapse: главный процесс (main process) продолжает писать в базу, а отдельные worker-процессы берут на себя федерацию, синхронизацию клиентов, media repository — каждый со своим, отдельно ограничиваемым потреблением памяти.

Типичное разделение для сервера среднего размера:

# workers/federation_sender.yaml
worker_app: synapse.app.federation_sender
worker_name: federation_sender1
worker_replication_host: 127.0.0.1
worker_replication_http_port: 9093
worker_listeners:
  - type: http
    port: 8034

# workers/synchrotron.yaml
worker_app: synapse.app.generic_worker
worker_name: synchrotron1
worker_listeners:
  - type: http
    port: 8035
    resources:
      - names: [client]

Перед workers нужен reverse-proxy, который маршрутизирует запросы между главным процессом и воркерами по типу эндпоинта — обычно это nginx или Traefik. Если Synapse уже развёрнут в Docker, схема с Traefik описана в статье Traefik как reverse-proxy для Docker.

Каждый worker — это ещё 150-300 МБ базового потребления Python-процесса, так что переход на workers сам по себе не экономит память, а перераспределяет пиковую нагрузку так, чтобы федерация не блокировала синхронизацию клиентов и наоборот. Смысл появляется от 16 ГБ и выше, когда сервер уже упирается не в общий объём памяти, а в то, что один поток event loop не успевает обрабатывать всё сразу.

Легче Synapse: Dendrite и Conduwuit как альтернатива

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

Разница не только в базовом потреблении, но и в том, как эти серверы масштабируются под нагрузку — компилируемые языки без GIL заметно эффективнее используют многоядерность на federation-нагрузке. Обратная сторона: у Dendrite и особенно Conduwuit меньше зрелость по редким фичам (некоторые виды мостов, часть admin API), и переезд с уже работающего Synapse на другую реализацию — не тривиальная операция, требующая экспорта данных пользователей и комнат. Для нового сервера с нуля и небольшой командой они — разумная экономия RAM с первого дня; для уже работающего продакшена на Synapse смена реализации обычно не оправдывает риск миграции ради экономии 1-2 ГБ.

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