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

MAATRIX

osTicket — классическая open-source тикет-система на PHP и MySQL, и вопрос «сколько ей нужно RAM» упирается не в саму программу (она лёгкая), а в стек вокруг неё: веб-сервер, PHP-FPM, база данных и почтовый poller, который тянет письма в тикеты. Если взять минимальный сервер «на глаз», через пару месяцев с ростом числа агентов и тикетов сервер начинает свопиться и тормозить на самых простых операциях — открытии очереди или поиске по тикетам. Разберём, из чего складывается потребление памяти и сколько RAM закладывать под конкретный размер команды поддержки.

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

osTicket — это классика LAMP/LEMP: PHP-приложение поверх Apache или nginx+PHP-FPM, с MySQL или MariaDB в качестве хранилища. Память съедают четыре компонента:

• Операционная система и базовые сервисы — 300-500 МБ на Ubuntu/Debian с минимальным набором пакетов, cron, systemd, ssh.
• MySQL/MariaDB — самый прожорливый компонент. InnoDB buffer pool, кэш соединений, временные таблицы для сложных фильтров и поиска по тикетам.
• PHP-FPM (или mod_php под Apache) — каждый воркер-процесс держит от 20 до 60 МБ, в зависимости от того, сколько плагинов osTicket подключено (кастомные поля, интеграции, API).
• Email piping / cron — если письма забираются через IMAP/POP3-поллинг по cron (api/cron.php), это кратковременный, но заметный всплеск памяти на каждый прогон, особенно с вложениями.

Сама PHP-логика osTicket не тяжёлая: страница тикета рендерится быстро, ORM простой. Узкое место почти всегда — это MySQL под нагрузкой поиска и Apache/PHP-FPM при нескольких одновременных агентах.

Сколько RAM нужно для разных сценариев

Ниже — ориентировочные цифры по опыту эксплуатации похожих LAMP-стеков. Точные цифры зависят от объёма базы (истории тикетов), числа кастомных полей, вложений и активности агентов, поэтому это отправная точка, а не гарантия.

На 1 ГБ osTicket формально запускается, но margin для MySQL и PHP-FPM почти нулевой — первый же пик обращений (например, после рассылки клиентам) уронит сервер в своп. Для боевой работы даже небольшой команды практический минимум — 2 ГБ, и именно с этого порога стоит начинать закладывать бюджет на сервер, если система будет использоваться ежедневно, а не в тестовом режиме.

Настройка PHP-FPM под доступную память

По умолчанию PHP-FPM в пуле www часто настроен без учёта реальной памяти сервера, из-за чего либо простаивают ресурсы, либо OOM killer убивает процессы в пик нагрузки. Формула простая: возьмите объём RAM, которую можно отдать под PHP (обычно 40-50% от общей, остальное — MySQL и система), и разделите на средний вес одного PHP-процесса.

Средний воркер osTicket с типовым набором плагинов занимает 30-40 МБ. Для сервера на 4 ГБ, где под PHP отведено ~1.5 ГБ:

; /etc/php/8.3/fpm/pool.d/www.conf
pm = dynamic
pm.max_children = 35
pm.start_servers = 8
pm.min_spare_servers = 5
pm.max_spare_servers = 15
pm.max_requests = 500

Расчёт: 1500 МБ / 40 МБ ≈ 37, берём с запасом чуть меньше — 35. Если после apache2ctl -M или systemctl status php8.3-fpm вы видите частые рестарты воркеров по pm.max_requests или в логах WARNING: [pool www] server reached pm.max_children, это прямой сигнал, что либо мало памяти, либо лимит выставлен без расчёта.

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

ps --no-headers -o rss -C php-fpm8.3 | awk '{sum+=$1; n++} END {print sum/n/1024 " MB avg"}'

Настройка MySQL/MariaDB под память сервера

InnoDB buffer pool — главный потребитель и главный рычаг производительности. Для сервера, где MySQL — единственная серьёзная нагрузка помимо PHP, ориентир — 40-60% от общей RAM.

# /etc/mysql/mariadb.conf.d/50-server.cnf
[mysqld]
innodb_buffer_pool_size = 1500M   # для сервера с 4 ГБ RAM
innodb_buffer_pool_instances = 1
innodb_log_file_size = 128M
max_connections = 50
tmp_table_size = 32M
max_heap_table_size = 32M
query_cache_type = 0

На серверах с 1-2 ГБ буфер приходится держать скромным (128-256 МБ), и здесь помогает статья про оптимизацию MySQL под ограниченную память — там разобраны компромиссы, когда буфера физически не хватает на весь рабочий набор данных.

Проверить, достаточно ли буфера, можно по коэффициенту попаданий:

SHOW STATUS LIKE 'Innodb_buffer_pool_read%';

Если Innodb_buffer_pool_reads (чтения с диска) растёт быстрее Innodb_buffer_pool_read_requests (логические чтения), буфер мал относительно размера базы — со временем, когда база с историей тикетов и вложениями разрастётся, это первое, что стоит пересчитать.

Email piping и cron: скрытая нагрузка

Многие рассматривают только веб-интерфейс, забывая про фоновую обработку почты. Если osTicket настроен на пассивный piping (письмо сразу передаётся в PHP через MTA), каждое входящее письмо — это отдельный короткоживущий PHP-процесс, который парсит вложения и создаёт тикет. При всплеске почты (массовая рассылка клиентам, инцидент у провайдера, DDoS-жалобы) это может дать десятки одновременных процессов.

Если вместо piping используется активный опрос по cron (api/cron.php тянет письма по IMAP раз в 1-5 минут), нагрузка предсказуемее, но каждый прогон при большом ящике и вложениях кратковременно поднимает потребление памяти на 100-300 МБ. Держите это в уме при расчёте — на серверах с 1-2 ГБ такой всплеск может совпасть по времени с пиком в веб-интерфейсе и вызвать своп.

# пример cron-задачи опроса почты каждые 2 минуты
*/2 * * * * www-data /usr/bin/php /var/www/osticket/upload/api/cron.php

Диагностика нехватки RAM

Признаки, что памяти не хватает, обычно видны раньше, чем сервер падает целиком:

free -h                        # своп начал заполняться — тревожный знак
vmstat 1 5                     # столбец si/so показывает активный своп
dmesg | grep -i "out of memory"  # OOM killer уже вмешивался
top -o %MEM                    # кто именно ест память прямо сейчас

Если free -h показывает, что available меньше 10-15% от общей памяти в обычные рабочие часы (не в пик), а swap used растёт день ото дня — это не «подождёт», а сигнал переезжать на тариф с большим объёмом RAM или пересчитывать буферы. Своп для MySQL особенно болезненен: страница тикета, которая раньше открывалась за 100-200 мс, при активном свопе может грузиться секундами.

Для оперативного слежения за памятью на проде пригодится статья про мониторинг диска на VPS — те же принципы (пороги, алерты в Telegram) применимы и к памяти, только источник метрик другой.

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