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

MAATRIX

SuiteCRM — открытый форк SugarCRM Community Edition, который тянет за собой всю тяжесть классической PHP-архитектуры середины 2010-х: огромные vardefs, ORM-бины (beans), которые пересобираются на каждый запрос, и планировщик, гоняющий десятки cron-задач. Официальная документация скромно указывает «2 GB RAM минимум», но на практике это работает только на демо-стенде без пользователей. Разберём, сколько памяти реально нужно под разные сценарии — от теста до продакшена на сотню менеджеров.

Из чего складывается нагрузка SuiteCRM

SuiteCRM — классический LAMP/LEMP-стек, но с оговорками, из-за которых он памяти просит больше, чем обычный PHP-сайт:

• PHP-FPM — сам движок SuiteCRM. Каждый HTTP-запрос загружает метаданные модулей (vardefs), собирает объекты-бины через SugarBean, применяет language-паки. Это дороже, чем типичный CRUD-фреймворк: один PHP-процесс под SuiteCRM в среднем занимает заметно больше памяти, чем аналогичный под Laravel или WordPress — конкретную цифру для вашей сборки лучше смотреть через ps aux --sort=-%mem | grep php-fpm, но закладывайтесь на диапазон 100–250 МБ на процесс с включёнными модулями типа Reports и Workflow.
• MySQL/MariaDB — вся бизнес-логика лежит в БД: связи many-to-many через relationship-таблицы, аудит изменений (_audit), история активности. У активной CRM база растёт быстро, и innodb_buffer_pool_size начинает иметь значение уже на 5–10 тысячах записей в основных модулях.
• Веб-сервер (Apache с mod_php или Nginx + PHP-FPM) — сам по себе лёгкий, но именно он держит очередь одновременных запросов и определяет, сколько PHP-процессов будет одновременно жить в памяти.
• Cron-планировщик — cron.php запускается раз в минуту и поочерёдно гоняет Scheduled Jobs: обработку входящей почты (Inbound Email), воркфлоу, отчёты, чистку логов. Каждая задача — это ещё один PHP-процесс с тем же memory_limit, что и у веб-запросов, и он может наложиться по времени на пиковую нагрузку от пользователей.
• Elasticsearch (опционально) — если включён глобальный полнотекстовый поиск, это отдельная JVM со своим heap, полностью независимая от PHP и MySQL по памяти.

Именно сумма этих компонентов, а не сама SuiteCRM как «одно приложение», определяет требования к серверу.

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

Ниже — ориентировочные диапазоны для типовой конфигурации: Ubuntu 24.04 или AlmaLinux 9, Nginx + PHP-FPM, MariaDB, без внешнего кеша сессий. Это отправная точка для планирования, а не гарантированная цифра — конкретное потребление зависит от количества кастомных модулей, воркфлоу и объёма базы.

Ключевой нюанс: «пользователей одновременно» — это не общее число аккаунтов в системе, а те, кто реально работает с CRM в моменте пиковой нагрузки (обычно 20–30% от штата отдела продаж в рабочие часы). Если у вас 200 аккаунтов, но одновременно активны 30–40 человек, ориентируйтесь на строку «средний отдел продаж», а не на 200 пользователей буквально.

Минимальная конфигурация: тест и демо-стенды

Для ознакомления с SuiteCRM, обучения сотрудников или тестирования кастомизаций перед продакшеном хватает 2 GB RAM — но с оговорками:

• Отключите или ограничьте cron до необходимого минимума (не гоняйте все Scheduled Jobs каждую минуту).
• Держите pm.max_children в PHP-FPM низким (3–4), иначе при параллельном заходе нескольких вкладок сервер уйдёт в swap.
• Обязательно настройте swap-файл хотя бы на 2 GB — на такой памяти это не резерв «на всякий случай», а рабочая необходимость: подробно про расчёт размера — в статье про правильный размер swap для VPS.

На 2 GB интерфейс будет открываться заметно медленнее, чем на 4+ GB — это ощутимо уже при первом входе в систему. Для реальной работы 3–5 человек берите минимум 4 GB: это тот порог, где PHP-FPM и MySQL перестают конкурировать за последние мегабайты.

Настройка PHP-FPM и MySQL под доступную RAM

Правильные лимиты в конфигах экономят память эффективнее, чем добавление ГБ «про запас». Базовый расчёт для сервера с 8 GB RAM (LEMP, PHP 8.1/8.2):

php.ini (/etc/php/8.2/fpm/php.ini):

memory_limit = 256M
upload_max_filesize = 100M
post_max_size = 100M
max_execution_time = 3600
max_input_time = 3600
opcache.enable = 1
opcache.memory_consumption = 256
opcache.max_accelerated_files = 20000

memory_limit = 256M — это не то, сколько процесс займёт постоянно, а потолок на пиковый запрос (тяжёлые отчёты, экспорт списков, массовые действия). Для рутинной работы процесс обычно использует заметно меньше.

PHP-FPM пул (/etc/php/8.2/fpm/pool.d/www.conf), формула — сколько памяти вы готовы отдать PHP-FPM, делённое на реалистичный размер процесса:

pm = dynamic
pm.max_children = 20
pm.start_servers = 4
pm.min_spare_servers = 2
pm.max_spare_servers = 8

На 8 GB, если под PHP-FPM выделено ~3 GB (остальное — MySQL, ОС, буферы), и процесс в среднем занимает 150 МБ, pm.max_children = 20 — разумный потолок с запасом. Проверяйте фактическое потребление через systemctl status php8.2-fpm и ps aux, а не берите цифру из статьи как аксиому — она зависит от того, сколько у вас кастомных модулей и логик-хуков.

MariaDB (/etc/mysql/mariadb.conf.d/50-server.cnf):

[mysqld]
innodb_buffer_pool_size = 3G
innodb_log_file_size = 256M
innodb_flush_log_at_trx_commit = 1
max_connections = 100
table_open_cache = 2000

innodb_buffer_pool_size — самый весомый параметр для MySQL. Общее правило — 50–70% свободной RAM после того, как вы зарезервировали память под PHP-FPM и ОС. На 8 GB сервере это обычно 2,5–4 GB. Если база небольшая (до 1–2 GB), нет смысла отдавать буферу больше размера самой базы — просто оставите память ОС под файловый кеш. Про выбор между MySQL и MariaDB — в отдельном разборе MariaDB или MySQL: что выбрать для сервера, а базовая настройка LEMP — в статье LEMP против LAMP: что выгоднее и когда.

Elasticsearch и полнотекстовый поиск: когда добавлять и сколько это стоит по памяти

По умолчанию SuiteCRM ищет по базе через SQL LIKE, что на большом объёме данных (десятки тысяч контактов, сделок, обращений) становится ощутимо медленным. Модуль глобального поиска на Elasticsearch решает проблему, но это отдельный сервис с собственными требованиями:

• Минимум — 1 GB heap для JVM (-Xms1g -Xmx1g в jvm.options), плюс накладные расходы самой JVM — реалистично закладывайте от 2 GB RAM, выделенных под Elasticsearch отдельно от PHP и MySQL.
• Для базы с сотнями тысяч записей и активным индексированием — от 4 GB.
• Elasticsearch не стоит ставить на ту же машину, что и продакшен-CRM, если суммарной RAM меньше 16 GB — конкуренция за память между JVM и InnoDB buffer pool даёт непредсказуемые просадки именно в моменты пиковой нагрузки.

Если полнотекстовый поиск не критичен (небольшая база, поиск в основном по email/телефону через стандартные фильтры), можно спокойно обойтись без Elasticsearch и сэкономить 2–4 GB на сервере — это честный компромисс, а не недоделка.

Что незаметно съедает память сверх расчёта

Три типичные причины, по которым сервер, рассчитанный «по формуле», всё равно уходит в swap:

• Import Wizard на больших CSV. Мастер импорта SuiteCRM исторически не умеет эффективно стримить большие файлы — он тянет в память заметную часть датасета при валидации дублей. Импорт файла на 50–100 тысяч строк на сервере с memory_limit = 256M может просто упасть с ошибкой нехватки памяти. Решение — либо временно поднять memory_limit до 512M–1G только для CLI/импорта (в отдельном .ini-оверрайде для php-cli), либо бить файл на батчи по 5–10 тысяч строк.
• Upgrade Wizard. Обновление SuiteCRM между минорными версиями — одна из самых прожорливых операций: пересборка кеша vardefs, миграция схемы БД, перегенерация языковых файлов. На проде с memory_limit = 256M апгрейд нередко обрывается на середине. Практика — временно поднять лимит до 1–2 GB именно на время апгрейда и вернуть обратно после.
• Наложение cron и пиковой нагрузки. Если Scheduled Jobs настроены гонять каждую минуту, а у вас длинные воркфлоу или обработка входящей почты с вложениями, cron-процесс может стартовать в момент, когда веб-сервер и так держит максимум pm.max_children. В результате — либо cron ждёт освободившийся процесс и всё копится в очередь, либо сервер уходит в swap. Смотрите разницу между запланированной и фактической частотой задач в Admin → Scheduled Jobs и разносите тяжёлые джобы (например, полную переиндексацию) на ночное время.

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

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