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

MAATRIX

FreeScout — популярный выбор для тех, кто устал платить Help Scout ежемесячно за каждого агента и хочет держать тикеты по почте на своём сервере. Это классический PHP-стек на Laravel, и по опыту эксплуатации похожих Laravel-приложений он не требует много памяти сам по себе — проблемы обычно начинаются не от базового веб-интерфейса, а от очереди отправки писем, крон-задач и модулей, которые администраторы ставят один за другим. Разберём, из чего реально складывается потребление RAM и сколько закладывать под разные размеры команды поддержки.

Из чего состоит стек FreeScout

FreeScout — PHP/Laravel-приложение, и по архитектуре память делят несколько компонентов:

• PHP-FPM воркеры — обрабатывают HTTP-запросы веб-интерфейса: список тикетов, открытие переписки, ответы агентов. По опыту эксплуатации похожих Laravel-приложений один воркер занимает порядка 40-70 MB, но это ориентир, а не гарантия — конкретная цифра зависит от количества установленных модулей и размера открываемых тикетов.
• MySQL или MariaDB — хранит тикеты, переписку, пользователей и настройки. Сами вложения по умолчанию лежат на диске, а не в базе, так что рост базы определяется числом писем и метаданных, а не размером файлов.
• Крон-планировщик — FreeScout полагается на php artisan schedule:run, запускаемый раз в минуту через системный cron. Именно через него по умолчанию идёт получение почты (fetch emails) и другие фоновые задачи. Каждый запуск — короткоживущий PHP-процесс, который стартует, делает работу и завершается, но при плотном потоке писем такие процессы могут пересекаться по времени.
• Очередь отправки (опционально) — если включить асинхронную отправку писем (QUEUE_CONNECTION=database или redis вместо sync), появляется постоянно висящий процесс php artisan queue:work, который держит загруженное Laravel-ядро в памяти всё время работы, а не только на время запроса.
• Веб-сервер (nginx или Apache) — лёгкий сам по себе, десятки мегабайт, если не считать буферы на приём вложений к письмам.

Официальных жёстких требований по RAM для конкретного числа агентов проект не публикует — есть только минимальные требования к версии PHP и наличию MySQL. Поэтому сайзинг ниже — инженерная оценка по компонентам стека, а не цифра из документации.

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

Ориентир на основе типового PHP-FPM/MySQL стека и потока входящих писем. Реальное потребление зависит от количества модулей (особенно интеграций — Slack, WhatsApp, автоответы) и от того, включена ли асинхронная очередь отправки.

Если параллельно с FreeScout на этом же сервере крутится приём и отправка почты — MTA, IMAP-ящики — стоит смотреть на общий сайзинг, а не только на сам хелпдеск: разбор в статье про лучший VPS для почты поможет прикинуть ресурсы под связку целиком.

PHP-FPM: настройка пула под FreeScout

FreeScout, как и любое Laravel-приложение, чувствителен к неверно выставленному pm.max_children — либо воркеров слишком мало и агенты видят таймауты при открытии тикетов, либо слишком много и сервер падает по OOM под пиковой нагрузкой. Типичный конфиг пула для сервера с 2 GB RAM, где FreeScout делит память с MySQL:

; /etc/php/8.x/fpm/pool.d/freescout.conf
[freescout]
user = www-data
group = www-data
listen = /run/php/php-freescout.sock

pm = dynamic
pm.max_children = 8
pm.start_servers = 2
pm.min_spare_servers = 2
pm.max_spare_servers = 4
pm.max_requests = 500

Логика та же, что для любого PHP-FPM пула: если воркер в среднем занимает 50-60 MB, а под PHP-FPM выделено, скажем, 500-600 MB (остальное — MySQL, ОС, крон-процессы), то 8 воркеров — разумный потолок для 2 GB сервера. Реальное потребление стоит проверять, а не брать на веру:

ps --sort=-rss -eo rss,pid,cmd | grep php-fpm | head -10

Отдельно важен memory_limit в php.ini — обработка крупных вложений к письмам (особенно если агенты пересылают целые треды с картинками) может упереться в дефолтный лимит 128M, что выглядит как случайные ошибки при ответе на конкретные тикеты, а не как нехватка RAM в целом.

Очередь отправки писем: sync, database или Redis

Это главная развилка, которая определяет, нужен ли FreeScout постоянно висящий процесс. По умолчанию QUEUE_CONNECTION=sync — письмо отправляется прямо в момент, когда агент нажимает «Отправить», и запрос браузера ждёт, пока это произойдёт. Для маленькой команды это нормально, но при активной переписке и медленном исходящем SMTP агенты начинают ждать несколько секунд на каждый ответ.

Переход на асинхронную очередь решает это, но добавляет фоновый процесс:

# .env
QUEUE_CONNECTION=database

# запуск воркера очереди (обычно через supervisor)
php artisan queue:work --sleep=3 --tries=3

Процесс queue:work держит в памяти загруженное Laravel-ядро постоянно, а не только на время HTTP-запроса — по опыту эксплуатации похожих Laravel-воркеров это дополнительные 60-100 MB, которые не видны, пока вы не запустите его и не сравните ps до и после. Драйвер database не требует Redis и на команде до 10-15 агентов работает вполне терпимо; redis даёт более надёжную и быструю очередь, но добавляет ещё один процесс в памяти — сравнение вариантов есть в статье Redis или Memcached, если решаете, что ставить для кэша и очереди одновременно.

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

; /etc/supervisor/conf.d/freescout-worker.conf
[program:freescout-worker]
process_name=%(program_name)s_%(process_num)02d
command=php /var/www/freescout/artisan queue:work --sleep=3 --tries=3
autostart=true
autorestart=true
numprocs=1
user=www-data

Крон, получение почты и модули

FreeScout получает входящие письма по крону: php artisan schedule:run запускается раз в минуту, и внутри него по расписанию срабатывает fetch-команда для каждого подключённого ящика. На малом потоке это не заметно по памяти — процесс живёт секунды и завершается. Проблема возникает, когда почтовых ящиков много или письма приходят пачками: если один запуск не успевает обработать очередь до следующего тика крона, процессы начинают накладываться друг на друга, и суммарное потребление PHP-FPM/CLI процессов на сервере растёт незаметно для администратора, который смотрит только на «висящую» память приложения.

* * * * * php /var/www/freescout/artisan schedule:run >> /dev/null 2>&1

Модули — вторая по частоте причина, почему сервер, «которому хватало 1 GB», внезапно начинает упираться в память. Каждый установленный модуль (авто-ответы, интеграция с мессенджерами, кастомные поля) грузится в PHP-FPM воркер при инициализации приложения — это не постоянная утечка, а фиксированная надбавка к базовому потреблению одного воркера, которая множится на число одновременно активных воркеров. На команде с 3-4 модулями закладывайте на 20-30% больше, чем в таблице выше для голого FreeScout без модулей.

MySQL/MariaDB: буфер и рост базы

Для FreeScout на небольшой команде MySQL почти незаметен на фоне остального — переписка в текстовом виде занимает немного места, и база в десятки-сотни мегабайт целиком работает из кэша ОС. Рост становится заметен, когда счёт идёт на годы истории переписки и десятки тысяч тикетов — поиск по архиву и открытие старых тредов упираются в innodb_buffer_pool_size.

Ориентировочный конфиг для сервера с 4 GB RAM, где база делит машину с самим FreeScout:

[mysqld]
innodb_buffer_pool_size = 1G
innodb_log_file_size = 256M
innodb_flush_log_at_trx_commit = 1
max_connections = 50

Правило по буферу такое же, как для любого PHP/MySQL приложения — держать его в районе 50-70% от памяти, которую вы готовы отдать под базу (не под весь сервер), и наращивать по мере роста объёма переписки, а не числа агентов: именно объём накопленных данных определяет, насколько буфер должен превышать размер базы, чтобы она читалась преимущественно из RAM. Если ставите базу с нуля, есть отдельный разбор установки MySQL на VPS с базовыми шагами, а выбор между MySQL и MariaDB для такой нагрузки — тема статьи MariaDB или MySQL.

Что делать, если сервер регулярно упирается в память

Если на сервере с FreeScout память заканчивается не разово (как бывает при пиках Composer во время установки модулей), а стабильно, при обычной дневной нагрузке — это сигнал, что текущий тариф уже мал для реального размера команды и потока писем, а не повод бесконечно подкручивать pm.max_children в минус. Временный костыль — своп, который спасёт от аварийного падения по OOM во время разовой операции вроде обновления модулей через Composer:

sudo fallocate -l 1G /swapfile
sudo chmod 600 /swapfile
sudo mkswap /swapfile
sudo swapon /swapfile

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

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