Требования к серверу Matrix Synapse: пользователи, федерация и железо

Matrix Synapse server requirements: базовая оценка ресурсов

Для Matrix Synapse на 10 пользователей достаточно 2 vCPU, 4 GB RAM, 60 GB NVMe и порта 1 Gbps, но при активной федерации с крупными серверами запас по CPU, памяти и диску нужен уже с первого дня.

Запрос matrix synapse server requirements нельзя сводить только к числу зарегистрированных аккаунтов. Synapse обслуживает локальные комнаты, хранит историю сообщений, индексы PostgreSQL, медиафайлы и постоянно синхронизируется с удалёнными homeserver’ами. Сервер на 20 сотрудников в одной закрытой комнате может работать на 2 vCPU, а инстанс с теми же 20 пользователями в публичных федеративных комнатах потребует в несколько раз больше IOPS и трафика.

Для типичного корпоративного или небольшого community-развёртывания разумный старт — VPS с 4 vCPU, 8 GB RAM и NVMe от 100 GB. Такая конфигурация выдерживает до 50 локальных пользователей, несколько десятков комнат и умеренную федерацию без постоянных задержек синхронизации.

Общий подход к выбору инфраструктуры описан в материале как подбирать железо для self-hosted приложений под нагрузку: сначала оценивают характер операций с данными, затем резерв CPU, RAM, диска и сети. Для Synapse особенно важны производительность PostgreSQL и задержка NVMe, а не только номинальное число ядер.

Что входит в нагрузку Synapse

На одном сервере обычно работают минимум три компонента: сам Synapse, PostgreSQL и reverse proxy — Nginx, Caddy или Traefik. Дополнительно могут потребляться ресурсы Redis, worker-процессами Synapse, Coturn для звонков, Prometheus, Grafana и задачами резервного копирования. Если всё размещено на одном VPS, из общей памяти необходимо оставить минимум 1 GB для Linux page cache и системных процессов.

Synapse использует PostgreSQL интенсивнее, чем многие привычные веб-приложения. Каждое сообщение создаёт события, связи между событиями, записи о состоянии комнаты, обновления индексов и данные для синхронизации клиентов. Поэтому медленный SATA-диск или перегруженный shared-storage часто становится причиной проблем раньше, чем нехватка CPU.

Минимальная практическая конфигурация

• Тестовый сервер: 2 vCPU, 4 GB RAM, 40–60 GB NVMe, без открытой публичной федерации.
• Небольшая команда: 2–4 vCPU, 4–8 GB RAM, 80–100 GB NVMe, PostgreSQL на том же хосте.
• Публичное сообщество: от 4 vCPU, 8 GB RAM, 150 GB NVMe, мониторинг БД и запас свободного места не менее 30%.
• Сервер со звонками: отдельный Coturn и UDP-порт; медиатрафик звонков не должен проходить через Synapse как через обычный HTTP API.

От чего зависят сервер Matrix Synapse требования

Сервер Matrix Synapse требования определяют активные сессии, количество комнат, объём истории и федеративный граф, а не только число пользователей в базе. Учётная запись, которая не подключалась месяцами, почти не создаёт нагрузки; пользователь с Element Desktop, Element Mobile и несколькими устройствами одновременно создаёт больше sync-запросов и уведомлений.

Комнаты и state events важнее числа аккаунтов

Каждая Matrix-комната имеет состояние: участников, права доступа, аватары, закреплённые события, шифрование, темы и другие state events. Чем больше участников и сложнее история комнаты, тем тяжелее расчёт состояния и синхронизация новых устройств. Публичная комната на 2 000 участников, даже если локальных пользователей всего 5, способна создать заметную нагрузку на БД.

Особенно затратны комнаты с частыми сменами участников, ботами, мостами в Telegram, Discord или IRC, а также большие пространства Spaces. Мост может отправлять сотни событий в час и раздувать базу существенно быстрее обычной переписки. Отключать федерацию только ради экономии ресурсов не всегда нужно, но стоит ограничить нежелательные room alias, регистрацию и медиа-загрузки.

Синхронизация клиентов и end-to-end encryption

Клиенты используют endpoint /_matrix/client/v3/sync, часто удерживая long-poll соединение до 30 секунд. При 50 активных пользователях сервер может одновременно обслуживать 50–150 подключений с нескольких устройств. Это не требует сотен ядер, но увеличивает нагрузку на Python-процессы, PostgreSQL и reverse proxy.

Сквозное шифрование выполняется в основном на клиенте, однако Synapse хранит ключи, device list updates и to-device события. Большое число устройств на одного пользователя повышает объём sync-данных. Для корпоративного сервера полезно ограничить число сессий, следить за неактивными устройствами и обновлять Synapse без долгих отставаний от актуальных релизов.

Масштаб → спека: synapse homeserver RAM CPU и цена

Synapse homeserver RAM CPU следует выбирать с запасом для PostgreSQL cache: для 50 активных пользователей и умеренной федерации практический минимум составляет 4 vCPU, 8 GB RAM и 100 GB NVMe.

Для 50 активных пользователей с умеренной федерацией достаточно 4 vCPU, 8 GB RAM, 100 GB NVMe и 2 TB трафика в месяц.

Цены указаны как общерыночный ориентир на март 2025 года для VPS с NVMe и не являются предложением конкретного стороннего провайдера. При выборе конфигурации Valebyte важнее проверить доступный объём NVMe, лимит трафика, географию дата-центра и возможность быстро увеличить RAM или диск без длительной миграции.

Как читать эту оценку

Значения подходят для Synapse с PostgreSQL на одном сервере и нормальным использованием клиентов Element. Они не включают тяжёлые медиахранилища, массовые видеофайлы, десятки bridges или собственный TURN-кластер. Если в комнате регулярно передают архивы по 1–5 GB, объём диска и месячный трафик нужно считать отдельно.

CPU важен для обработки запросов, федерации, JSON-сериализации и фоновых задач, но пиковая производительность одного ядра часто важнее большого числа медленных vCPU. Для 4 vCPU желательны современные ядра с частотой от 2,5 GHz, а для PostgreSQL — стабильные IOPS без агрессивного throttling.

Быстрый выбор

Ищете сервер, который просто работает?

Valebyte VPS — NVMe, поддержка 24/7, запуск за 60 секунд.

Тарифы VPS

Сколько RAM для Matrix Synapse и PostgreSQL

На вопрос сколько RAM для Matrix Synapse практический ответ такой: 4 GB подходят для 10 пользователей, 8 GB — для 50, а 16 GB нужны при 200 пользователях или активной федерации. Из этого объёма Synapse обычно использует 1–4 GB в зависимости от числа worker-процессов, остальное необходимо PostgreSQL и файловому кешу Linux.

Как распределить память на одном VPS

На сервере с 8 GB RAM не нужно выдавать всю память PostgreSQL параметром shared_buffers. Рабочая отправная точка — 2 GB shared buffers, 512 MB–1 GB effective cache estimate в настройках приложения и минимум 2 GB, доступных ядру Linux для page cache, Synapse, Nginx и кратковременных пиков. Точные параметры проверяют по статистике, а не копируют из чужой конфигурации.

# /etc/postgresql/16/main/postgresql.conf
shared_buffers = 2GB
effective_cache_size = 5GB
work_mem = 16MB
maintenance_work_mem = 512MB
max_connections = 100
checkpoint_completion_target = 0.9
random_page_cost = 1.1

Значение work_mem нельзя завышать без расчёта: оно применяется к операциям сортировки и соединения, а не является жёстким общим лимитом. При 100 соединениях слишком большое значение может привести к OOM. Для небольшой инсталляции Synapse лучше начать с 16 MB и анализировать медленные запросы.

Признаки нехватки памяти

• процесс postgres или synapse завершается с сообщением OOM Killer;
• время ответа /sync растёт с сотен миллисекунд до нескольких секунд;
• постоянно используется swap, хотя CPU загружен менее чем на 50%;
• PostgreSQL часто читает одни и те же страницы с NVMe вместо кеша RAM;
• после запуска бэкапа, VACUUM или обновления Synapse сервер становится недоступным.

Swap объёмом 1–2 GB допустим как аварийная страховка, но постоянный swap I/O означает, что серверу не хватает RAM. Увеличение памяти с 4 до 8 GB в таком случае обычно полезнее, чем добавление ещё 2 vCPU.

Matrix Synapse federation server sizing: сеть, очереди и медиа

Matrix Synapse federation server sizing начинается с оценки удалённых комнат: федерация с крупными homeserver’ами может создать больше нагрузки, чем 200 локальных пользователей. Synapse получает события, отправляет PDUs, запрашивает missing events, проверяет подписи и обслуживает запросы ключей, поэтому нестабильная сеть быстро накапливает очереди.

Сколько трафика потребляет федерация

Текстовые сообщения обычно занимают немного места: 1 000 коротких сообщений могут уложиться в десятки мегабайт с учётом JSON и служебных данных. Однако история комнат, изображения, voice messages, файлы и повторные скачивания меняют картину. Для 50 пользователей с обычной корпоративной перепиской достаточно от 2 TB в месяц, а публичный сервер с медиа и внешними комнатами может потреблять 5–10 TB и больше.

Порт 1 Gbps достаточен почти для всех инсталляций на 10–200 пользователей. Критичнее стабильность маршрута, низкий packet loss и отсутствие жёсткого ограничения на число соединений. Для TURN-сервера следует отдельно учитывать UDP: один HD-звонок может использовать сотни Kbit/s или несколько Mbit/s в зависимости от кодека, участников и условий сети.

Как ограничить ненужную федеративную нагрузку

Не стоит открывать регистрацию без captcha, лимитов и антиспам-политики. Для сервера небольшой организации полезны закрытая регистрация, подтверждение email, moderation bots и контроль публичных комнат. Также нужно своевременно удалять неиспользуемые bridges: каждый мост добавляет синхронизацию, события и записи в PostgreSQL.

# Проверка очередей и состояния Synapse через systemd
systemctl status matrix-synapse
journalctl -u matrix-synapse -p warning --since "1 hour ago"

# Проверка сетевой активности и свободного места
ss -s
df -h
iostat -xz 1

Если awaiting full state sync, ошибки federation retries или медленные транзакции появляются регулярно, сначала проверяют DNS, TLS, MTU, packet loss и latency до крупных серверов. Добавление RAM не исправит сетевую проблему, а открытие дополнительных worker-процессов без диагностики иногда лишь увеличит давление на PostgreSQL.

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

PostgreSQL следует выносить с Synapse, когда на сервере с 8–16 GB RAM база стабильно потребляет IOPS, задержки запросов растут, а CPU Synapse и БД конкурируют за ресурсы. Для 10–50 пользователей это обычно избыточно, но для 200 пользователей, bridges и активной федерации отдельная БД упрощает масштабирование и обслуживание.

Практические триггеры для разделения ролей

Решение оправдано при нескольких признаках одновременно: p95-задержка SQL превышает 50–100 ms на пике, диск загружен более чем на 70% длительное время, VACUUM мешает обслуживать sync-запросы, резервное копирование создаёт заметные паузы, а рост базы составляет десятки гигабайт за квартал. Отдельный PostgreSQL-сервер также удобен для репликации и независимого увеличения NVMe.

Между Synapse и PostgreSQL нужна приватная сеть с низкой задержкой, желательно менее 1 ms в пределах одного дата-центра. Размещать БД на удалённом сервере через публичный интернет не рекомендуется: задержка каждого SQL-запроса складывается, а защита канала и отказоустойчивость усложняются.

Схема для 200 пользователей

Рабочая схема: Synapse на 4–8 vCPU и 8–12 GB RAM, PostgreSQL на 4–8 vCPU и 12–16 GB RAM с 250 GB NVMe, reverse proxy на фронтенде и отдельный Coturn при необходимости звонков. Если есть media repository больше 100 GB, его можно вынести в S3-совместимое объектное хранилище или выделить отдельный диск.

Резервные копии PostgreSQL должны быть логическими или физическими и проверяться восстановлением. Для задачи хранения и проверки копий полезны принципы из статьи о требованиях к серверу Proxmox Backup Server и дедупликации: бэкап без тестового restore не подтверждает возможность восстановления.

Быстрый выбор

Ищете сервер, который просто работает?

Valebyte VPS — NVMe, поддержка 24/7, запуск за 60 секунд.

Тарифы VPS

Настройка Synapse: workers, диск и мониторинг

После выполнения базовых matrix synapse hardware requirements производительность зависит от конфигурации worker-процессов, PostgreSQL maintenance и наблюдаемости. До 50 пользователей обычно достаточно одного процесса Synapse, а workers стоит вводить только после измерения реальной нагрузки.

Когда нужны workers

На 4 vCPU и 8 GB RAM один Synapse-процесс часто работает стабильнее простой установки с несколькими workers, потому что каждый worker добавляет подключения к PostgreSQL и потребляет память. Горизонтальное разделение имеет смысл при сотнях активных sync-соединений, высоком CPU или заметной очереди федерации. Перед включением workers нужно настроить reverse proxy, Redis и лимиты PostgreSQL connections.

Для диагностики полезны Prometheus-метрики: длительность запросов, число активных процессов, размер базы, rate federation, latency event persistence и свободное место. Алерт на 80% заполнения диска нужен обязательно: при полном томе PostgreSQL может аварийно остановиться, а восстановление после этого займёт часы.

Диск, очистка и рост базы

Не планируйте диск впритык. Для базы 70 GB нужен том минимум 120–150 GB, поскольку VACUUM, индексы, временные файлы, обновления и бэкапы требуют свободного пространства. Медиафайлы обычно растут быстрее событий: включите лимиты upload, настройте retention для ненужных файлов и отдельно контролируйте каталог media store.

Команда ниже показывает, какие каталоги занимают место, а запрос PostgreSQL помогает увидеть крупнейшие таблицы. Выполняйте тяжёлые операции обслуживания в период низкой активности.

sudo du -xh /var/lib/matrix-synapse | sort -h | tail -20

sudo -u postgres psql synapse -c "
SELECT relname,
       pg_size_pretty(pg_total_relation_size(relid)) AS total_size
FROM pg_catalog.pg_statio_user_tables
ORDER BY pg_total_relation_size(relid) DESC
LIMIT 15;"

Если VPS одновременно обслуживает другие сервисы — Git, Nextcloud, мониторинг или CI — ресурсы Synapse нельзя считать изолированно. Для сравнения подхода к CPU-нагрузке полезна статья о том, как масштаб нагрузки влияет на требования к CPU сервера: число подключений само по себе не заменяет измерения фактических операций.

Часто задаваемые вопросы

Ответы по ресурсам и масштабированию Synapse

Сколько пользователей выдерживает Synapse на 4 vCPU и 8 GB RAM?

При NVMe-диске и PostgreSQL на том же VPS 4 vCPU и 8 GB RAM обычно достаточно для 30–50 активных локальных пользователей, 30–100 комнат и умеренной федерации. Если участники состоят в крупных публичных комнатах, используют bridges или часто загружают медиа, практический предел может наступить раньше. Контролируйте latency PostgreSQL и свободное место на диске.

Нужен ли SSD или обязательно NVMe для Matrix Synapse?

Обычный SSD может работать на тестовом сервере с 10 пользователями, но для production рекомендуется NVMe. PostgreSQL выполняет много мелких случайных операций чтения и записи, а низкая задержка NVMe заметно улучшает sync и федерацию. Для инсталляции на 50 пользователей разумно выделить минимум 100 GB NVMe и сохранить 30% свободного пространства.

Когда Synapse нужно разделять на workers?

Workers обычно не нужны до 50 активных пользователей. Их стоит рассматривать при 200 и более активных пользователях, большом количестве одновременных sync-подключений или высокой загрузке одного процесса Synapse. Перед масштабированием добавьте Redis, настройте reverse proxy и убедитесь, что PostgreSQL имеет 8–16 GB RAM и достаточное число подключений.

Сколько места занимает база Matrix Synapse?

Для небольшой команды история сообщений и служебные таблицы могут занимать 10–30 GB, но размер быстро растёт из-за больших комнат, bridges и медиа. На сервере с прогнозируемой БД 50 GB выделяйте не менее 100–150 GB NVMe. Медиафайлы лучше учитывать отдельно: несколько архивов по 1 GB меняют расчёт сильнее тысяч текстовых сообщений.

Выводы

Рекомендация по стартовой конфигурации

Для Matrix Synapse на 10 пользователей выбирайте 2 vCPU, 4 GB RAM и 60 GB NVMe, а для 50 пользователей с федерацией — 4 vCPU, 8 GB RAM и 100 GB NVMe. При 200 пользователях, bridges или крупных комнатах переходите на 8 vCPU, 16 GB RAM, 250 GB NVMe и выносите PostgreSQL при росте SQL-задержек или дефиците IOPS.

SSD NVMe

Готовы запустить свой VPS?

NVMe VPS с активацией за 60 секунд: полный root-доступ, 20+ локаций, оплата картой или криптой.

Выбрать тариф