Сервер под self-hosted CRM: сколько памяти, процессоров и диска нужно на 10, 30 и 100 пользователей

Для self-hosted CRM на 10 пользователей я закладываю 2 vCPU, 4 ГБ памяти и 40 ГБ SSD, на 30 — 4 vCPU, 8 ГБ и 80 ГБ, на 100 — 8 vCPU, 16 ГБ и 200 ГБ с отдельной базой. Это оценка, а не бенчмарк. Ниже: из чего складывается нагрузка, где экономить и как проверить, что запаса хватает.

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

Прежде чем выбирать конфигурацию, полезно понять, из чего состоит сервер CRM. Браузеры пользователей приходят на обратный прокси с SSL. За ним веб-приложение: у EspoCRM и SuiteCRM это PHP, у Odoo Python, у Frappe CRM приложение на Frappe. Приложение работает с базой данных (MariaDB или PostgreSQL), а фоновые задачи вроде рассылок, напоминаний и синхронизации почты выполняют воркеры и планировщик. Добавьте файловое хранилище для вложений и почтовый демон. Каждый из этих блоков потребляет память, и узким обычно оказывается не процессор.

Для Frappe-семейства, к которому относится и Frappe CRM, production-стек включает отдельные сервисы redis-cache и redis-queue: кэш и очереди живут отдельно от базы. Redis для кэша в шаблоне bench настраивается с ограничением maxmemory, политикой вытеснения allkeys-lru и без записи на диск (appendonly no, save ""), а массовую вставку документов заменяют очередью и фоновыми воркерами. Для EspoCRM типовой стек в Docker — mariadb, espocrm, espocrm-daemon и reverse proxy, и тег latest в production использовать нельзя, образ закрепляют на версии.

Нагрузка делится на три вида: запросы пользователей (всплески утром и после обеда), фон (рассылки, импорт, синхронизация) и обслуживание (бэкапы, пересчёты). Первый вид зависит от числа людей, второй — от интеграций, третий — от вашего расписания. Если фон и обслуживание сталкиваются с рабочим пиком, пользователи жалуются на «тормоза», хотя среднее потребление далеко от пределов.

Как мы подбираем конфигурацию под CRM с AI-продавцом, описано на странице CRM и AI-отдел продаж. Но этот текст общий: цифры годятся для любой self-hosted CRM, а точные требования конкретной системы смотрите в её документации.

Ориентиры по ресурсам на 10, 30 и 100 пользователей

Сначала таблица, потом оговорки. Это оценка ITfresh на основе практики, а не результат нагрузочного теста, и в ней нет гарантий. Цифры можно скорректировать вниз, если у вас лёгкая система без интеграций, или вверх, если есть тяжёлые отчёты и вложения. | Пользователей | vCPU | Память | Диск (SSD) | Заметка | |---|---|---|---|---| | 10 | 2 | 4 ГБ | 40 ГБ | одна машина, база и приложение вместе | | 30 | 4 | 8 ГБ | 80 ГБ | одна машина, бэкап вне пика | | 100 | 8 | 16 ГБ | 200 ГБ | базу выделяют отдельно |

Для 10 пользователей обычно хватает 2–4 ГБ, для 30 планируют 4–8 ГБ, для 100 — 8–16 ГБ с отдельной базой. Диапазон в памяти — не уклончивость, а реальная вилка: она зависит от системы, числа интеграций, размера вложений и частоты фоновых задач. Я беру верхнюю границу, если в CRM будет поиск по большому объёму писем или подключён AI-продавец.

Официальные требования дают другой ориентир: они описывают минимальную работоспособность, а не комфорт. Например, для EspoCRM документация называет PHP 8.3–8.5, memory_limit не меньше 256M, max_execution_time 180, post_max_size и upload_max_filesize 50M, а базу MySQL 8.0 и выше, MariaDB 10.3 и выше или PostgreSQL 15. Для SuiteCRM 8 последней ветки 8.10 в матрице совместимости указаны PHP 8.2–8.4, MariaDB 10.6–11.8, MySQL 8.0 или 8.4 и Apache 2.4. Это параметры окружения, а не объём памяти под нагрузку.

Для Frappe v15 документация называет MariaDB 10.6.6 и выше, Python 3.10 и выше, Node.js 18 и выше, Redis 6; для v16 — MariaDB 11.8, Python 3.14, Node.js 24. Минимальный объём оперативной памяти в этой документации не указан, поэтому цифры по Frappe CRM в таблице выше — моя оценка с оговоркой, и её надо подтвердить замером на вашей версии. Для Odoo ориентиры по воркерам зависят от числа ядер, смотрите документацию вашей версии.

Правило, которое я применяю: сервер выбирается под пик, а не под среднее, и подтверждается мониторингом через месяц работы. Если запас по памяти меньше 30 % в рабочий пик, берите следующий размер.

Что съедает память на самом деле: поиск, воркеры, импорт и вложения

Четыре пожирателя памяти встречаются чаще всего. Первый — полнотекстовый поиск и индексы: по мере роста базы они требуют больше оперативной памяти, а при её нехватке поиск и отчёты начинают мешать работе. Второй — воркеры: каждый воркер держит процесс приложения, и их число, умноженное на размер процесса, часто больше, чем кажется. Третий — импорт: загрузка большого файла контактов в одном запросе упирается в лимиты PHP или Python.

Четвёртый — вложения и почта. Файлы лежат на диске, но обработка писем с большими вложениями ест память и процессор. Если ваши менеджеры прикрепляют к карточкам сканы договоров по десять мегабайт, закладывайте диск и лимиты загрузки заранее. Отдельная тема — бэкап: команда bench backup на крупных базах делает логический дамп и сжимает его, это заметная нагрузка на процессор и диск, поэтому бэкап я ставлю вне рабочих часов, а для очень больших баз рассматриваю физические копии средствами MariaDB. Сколько именно ядер займёт дамп, зависит от размера базы: замерьте на своём сервере в первую же ночь.

Для самопроверки на сервере с Docker:

free -h
df -h /var/lib/docker
docker stats --no-stream

Первая команда показывает свободную память и swap, вторая — место под тома, третья — потребление памяти и процессора каждым контейнером. В MariaDB стоит проверить размер буфера: SHOW VARIABLES LIKE 'innodb_buffer_pool_size'; — если он намного меньше базы, поиск и отчёты будут читать диск.

Тонкость с Redis: кэш с политикой вытеснения не должен записываться на диск и не должен превращаться в хранилище. Если очередь и кэш смешаны в одном экземпляре, нехватка памяти может выбросить задачи. Поэтому в Frappe-стеке очередь и кэш разделены.

Отдельно скажу про всплески. Среднее потребление памяти обманывает: CRM может пять дней работать на 40 % и в день сдачи квартальной отчётности упереться в потолок. Поэтому смотрите на пик за период, а не на среднее. Я прошу заказчика отметить в календаре «тяжёлые» даты: квартальный отчёт, массовую рассылку, миграцию данных, и в эти дни следить за памятью вручную. Для бухгалтерской фирмы это конец квартала, для оптовой компании — день прайс-листа, для учебного центра — старт набора.

Где можно сэкономить и где нельзя: диск, swap, бэкапы

Экономить можно на процессоре в первые месяцы: для 10 пользователей два ядра хватает, и они простаивают большую часть дня. Можно экономить на красивом дисковом классе, если диск SSD и под ним нормальный канал. Можно взять скромный VPS для 5–10 пользователей без AI и тяжёлых отчётов, если есть бэкапы и мониторинг. Опасность в таком VPS не в цене, а в отсутствии запаса по памяти и swap.

Нельзя экономить на бэкапе. Минимум для EspoCRM: дамп SQL плюс архив томов приложения, ежедневно, с проверкой восстановления. Хранить копию на том же диске, что и CRM, бессмысленно: диск умрёт вместе с данными. Нельзя экономить и на мониторинге: без него вы узнаете о нехватке памяти от пользователей. Минимальный набор: свободная память, загрузка, место на диске, состояние контейнеров и бэкапа.

Swap — страховка, а не расширение памяти. Небольшой swap спасает от внезапного убийства процесса, но если машина постоянно в swap, она работает на порядок медленнее. Если вы видите, что swap растёт, не добавляйте его, а увеличивайте память или разгружайте фон.

Про стоимость. В обзорах для SuiteCRM встречаются оценки расходов на VPS в диапазоне от нескольких до двух-трёх десятков долларов в месяц, но это внешний обзор, и к российским ценам и вашему провайдеру его переносить нельзя. Я не называю цену сервера: она зависит от провайдера и даты. Сравнивайте предложения по памяти, диску и сетевому каналу, а не по названию тарифа.

«Баланс Первого Дня»: бухгалтерская фирма на 13 рабочих мест

Условный пример, цифры вымышленные. Аутсорсинговая бухгалтерия «Баланс Первого Дня» ведёт клиентов, в штате 13 человек, из них 4 менеджера по работе с клиентами. CRM нужна для карточек клиентов, договоров, задач по срокам отчётности и переписки. База небольшая: около 900 клиентов, 5 тысяч договоров и 20 тысяч писем.

Изначально CRM развернули на самом дешёвом VPS: 1 vCPU и 2 ГБ памяти без swap. Первые два месяца всё работало, потом начались жалобы: поиск по клиентам зависает в конце квартала, когда бухгалтеры одновременно выгружают отчёты, а ночью перестаёт приходить почта. Мониторинга не было, бэкап лежал на том же диске.

Диагностика заняла вечер. Память заканчивалась в пике: процессы базы и приложения выбивали друг друга, воркеры не успевали разбирать очередь, а письма висели в очереди. Мы увеличили машину до 2 vCPU и 4 ГБ, добавили небольшой swap как страховку, подняли буфер базы, вынесли бэкап на внешнее хранилище и включили мониторинг. После этого жалобы прекратились. Для примера этого достаточно, а ваши цифры будут другими.

Вывод для читателя: для 13 человек верхняя граница ориентира для 10 пользователей была правильной, а исходная конфигурация — ошибкой не в цене, а в отсутствии запаса. Если бы фирма вырастала до 30 человек, мы бы шли по второй строке таблицы, но не раньше, чем мониторинг покажет запас менее 30 % в пик.

Что стоило бы сделать с самого начала, и в этом случае тоже: описать в одном документе, где лежит CRM, как делается бэкап, кто получает алерт о нехватке места и памяти и как восстанавливать систему. Для фирмы на 13 человек это одна страница. Без неё через год никто не вспомнит, на каком диске лежат тома и в какое время запускается копия, а восстановление в день аварии превращается в раскопки. Проверку восстановления из копии я предлагаю делать раз в квартал на отдельной машине, и именно по ней видно, что бэкап настоящий.

Как проверить, что сервера хватает, и когда пора расти

Критерии простые. Свободная память в рабочий пик не падает ниже 30 % от объёма. Swap не растёт в течение дня. Загрузка процессора не держится выше 70 % дольше нескольких минут. Диск заполнен не больше чем на 70 %, и вы знаете, как быстро он растёт. Очередь фоновых задач не копится. Если одно из условий нарушено, это сигнал, а не приговор: сначала ищите причину, потом увеличивайте ресурсы.

Симптомы и причины. Тормозит поиск и отчёты: мало памяти под базу, вынести базу или поднять буфер. Падает при импорте: нет памяти или лимит PHP, импорт делать порциями и поднять лимиты. Письма и задачи висят: не хватает воркеров, увеличить их число. Диск заполнился: вложения и логи, настроить ротацию и вынести файлы.

Отдельный случай — рост в 3–4 раза. При переходе с 30 на 100 пользователей базу выносят на отдельный сервер или выделяют ей часть памяти: иначе поиск и отчёты мешают работе остальных. Нужен ли отдельный сервер базы до 30 пользователей? Чаще нет, одного сервера с базой и приложением достаточно.

Про AI-продавца: модель обычно вызывается по API, поэтому процессор и память под CRM растут умеренно. Если ставится локальный запуск модели, требования определяются моделью и считаются отдельно, это уже не расчёт CRM. Практическое правило: сначала замер, потом покупка. Прочитайте инструкции по установке и эксплуатации конкретной системы: EspoCRM на VPS, YetiForce, Odoo 19 Community, регламент SuiteCRM, а перед обновлениями используйте staging-среду.

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