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

MAATRIX

«Сколько RAM нужно для Mailtrain» — вопрос, который обычно задают на этапе выбора тарифа, а не после того как ночная рассылка на пару десятков тысяч адресов положила сервер вместе с сайтом на нём же. Mailtrain — это не веб-форма поверх стороннего сервиса рассылок, а полноценный стек: Node.js-сервер, MySQL/MariaDB с историей каждого клика и открытия, Redis и несколько фоновых процессов, которые едят память независимо от того, сколько подписчиков у вас сегодня. Разберём, из чего складывается расход, как его измерить у себя и какой сервер взять, чтобы рассылка не упиралась в память на третьей тысяче писем.

Короткий ответ: сколько RAM нужно для Mailtrain

Аппетит Mailtrain определяется не столько интерфейсом, сколько тем, что стоит рядом на той же машине — MySQL и, если вы не выносите почту наружу, ещё и MTA для отправки.

Главное из таблицы: сам Mailtrain в покое — это несколько сотен мегабайт на Node-процессы. Дальше расход растёт не от количества установленных плагинов, а от объёма базы подписчиков и от того, храните ли вы историю кликов и открытий по каждой кампании.

Из чего складывается память Mailtrain

Mailtrain (актуальная ветка — версия 2 с React-клиентом и Express-сервером, поддерживаемая сообществом mailtrain-org) состоит не из одного процесса: отправка кампаний, импорт списков и построение отчётов вынесены в фоновые воркеры, чтобы долгая рассылка не подвешивала веб-интерфейс. Посмотреть список процессов после запуска:

ps aux | grep -i mailtrain
pm2 list

Набор процессов зависит от способа установки — через pm2, systemd-юнит из комплекта или Docker (в контейнере смотрите через docker exec mailtrain ps aux).

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

MySQL/MariaDB — главный потребитель на большой базе

Mailtrain хранит в MySQL не только список подписчиков и текст кампаний, но и событийную историю: каждый клик по ссылке и каждое открытие письма — строка в таблице статистики, привязанная к подписчику и кампании. На базе в тысячу человек это незаметно. На базе в сто тысяч с активной рассылкой раз в неделю таблицы кликов и открытий за полгода легко перерастают саму таблицу подписчиков.

Проверить размер таблиц под своей базой:

mysql -u mailtrain -p -e "
SELECT table_name, ROUND((data_length + index_length) / 1024 / 1024, 1) AS mb
FROM information_schema.tables
WHERE table_schema = 'mailtrain'
ORDER BY (data_length + index_length) DESC LIMIT 10;"

Главный рычаг под память — буфер InnoDB. По умолчанию в свежих установках MySQL/MariaDB он часто занижен под маленькие сайты, а не под аналитическую нагрузку рассылок. Правило для сервера, где MySQL стоит один на весь VPS вместе с Mailtrain, — отдавать буферу 50–60% доступной памяти:

# /etc/mysql/mysql.conf.d/mailtrain.cnf
[mysqld]
innodb_buffer_pool_size = 2G
innodb_buffer_pool_instances = 2
innodb_log_file_size = 256M
max_connections = 50

На 4 ГБ сервере это будет 2 ГБ буфера, на 8 ГБ — 4–4,5 ГБ. Занижать буфер, чтобы «сэкономить» память под Node, — ложная экономия: индексы по подписчикам перестают помещаться в кэш, отчёты по кампаниям начинают читать с диска, и на NVMe это терпимо, а на сетевом медленном диске превращается в подвисающий интерфейс при каждом открытии статистики.

Redis и очередь отправки

Redis у Mailtrain — не хранилище данных, а служебный слой: кэш часто запрашиваемых значений, распределённые блокировки между воркерами и учёт скорости отправки (rate limiting), чтобы не долбить принимающие почтовые серверы быстрее разрешённого. В спокойном режиме это условно 20–100 МБ — заметно меньше, чем MySQL или Node.

Проблема начинается, когда кампания застревает: принимающий сервер временно отклоняет письма (4xx), Mailtrain по логике retry держит незавершённые задания в очереди дольше обычного, и Redis накапливает состояние по каждому подписчику. На большой рассылке с проблемным списком это заметная, хоть и не катастрофическая прибавка. Ограничить верхнюю границу и не дать Redis вытеснить память соседей:

# /etc/redis/redis.conf
maxmemory 256mb
maxmemory-policy allkeys-lru

Для Mailtrain это безопасно: ключи, которые вытеснит LRU-политика, пересоздаются заново, а не хранят единственную копию критичных данных — те лежат в MySQL.

Как проверить реальный расход и не словить OOM

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

free -h
ps aux --sort=-%mem | head -15
dmesg -T | grep -i "out of memory"

Если в dmesg есть строка вида Out of memory: Killed process ... (mysqld) или (node) — сервер уже упирался в память, и дело не в отдельном компоненте, а в суммарном балансе. Отдельно по MySQL полезно смотреть текущее потребление против выделенного буфера:

mysql -u root -p -e "SHOW ENGINE INNODB STATUS\G" | grep -A2 "BUFFER POOL"

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

pm2 start server/index.js --name mailtrain --max-memory-restart 400M

Жёсткого OOM-killer'а в контейнере лучше не дожидаться: он убивает процесс без предупреждения и без внятной записи в логах приложения, только строка в dmesg.

Настройки, которые снижают нагрузку

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

• Ограничить innodb_buffer_pool_size разумно под доступную RAM, а не оставлять автовыбор MySQL — на маленьких VPS автонастройка иногда отдаёт слишком много системе и слишком мало базе.
• Архивировать старые кампании со статистикой, которую вы реально не смотрите: перенос строк кликов/открытий старше года в отдельную таблицу или выгрузка в CSV с последующим DELETE заметно облегчает основные таблицы и, как следствие, объём, который должен помещаться в буфер.
• Отключить general_log и держать slow_query_log включённым только на время диагностики — общий лог в проде растёт быстро и грузит диск операциями записи, что на HDD ощутимо тормозит и MySQL, и весь сервер.
• Не держать сессии редактирования шаблонов открытыми пачками — каждая вкладка админки с живым предпросмотром кампании добавляет память на стороне Node-процесса.
• Разнести MySQL и Mailtrain по разным серверам, если база подписчиков переросла 100–150 тысяч записей с активным трекингом — тогда буфер СУБД можно отдать под неё полностью, не деля с Node-процессами. Подробнее о балансе ресурсов для почтовых задач — в статье сколько ресурсов нужно VPS для почтовой рассылки.

Если после тюнинга сервер всё равно упирается в потолок — это, как правило, признак того, что база данных переросла тариф, а не что Mailtrain «тяжёлый» сам по себе. Общий разбор поведения при нехватке RAM на сервере справедлив и здесь: сначала swap как временная страховка, потом — реальное увеличение памяти.

Какой сервер взять в MAATRIX под Mailtrain

Честный минимум для рабочей установки — 2 vCPU, 4 ГБ RAM, 40 ГБ NVMe. Меньше технически стартует, но буфер MySQL приходится урезать до сотен мегабайт, и уже импорт списка на несколько тысяч строк ощутимо подвешивает интерфейс.

Комфортный вариант для активной рассылки на базе 20–100 тысяч подписчиков — 4 vCPU, 8 ГБ RAM, 80 ГБ NVMe: сюда помещаются Mailtrain, MySQL с адекватным буфером и Redis без взаимной конкуренции за память, плюс запас на рост таблиц статистики за год-полтора без немедленного архивирования. Если база растёт дальше сотни тысяч и рассылки идут параллельно по нескольким спискам — на этом объёме уже разумно выносить MySQL на отдельный сервер, а не наращивать один VPS до предела.

Отдельный вопрос — сам почтовый транспорт. Mailtrain не отправляет письма напрямую: он передаёт их в настроенный SMTP-релей — свой Postfix, стороннее API или транзакционный сервис. Если вы разворачиваете собственный релей рядом, закладывайте под него отдельный запас памяти и диска под очередь — установка описана в статье настройка почтового сервера Postfix на VPS, а базовую подпись писем стоит сразу настроить по инструкции SPF, DKIM и DMARC на VPS — без неё письма массовой рассылки быстро оседают в спаме независимо от того, сколько памяти на сервере.

По локации для самого Mailtrain принципиальной разницы между Россией, США и Великобританией нет — репутация исходящего IP и корректная настройка DNS-записей значат для доставляемости больше, чем география хостинга. Россию стоит выбирать, если в базе подписчиков персональные данные российских граждан и важен 152-ФЗ; США или Великобританию — если основная аудитория рассылки зарубежная и удобнее держать IP в том же регионе. Оплата — картами российских банков, по СБП, криптовалютой или токеном MAAT, без необходимости в иностранной карте для любой из локаций.

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