CRM и внутренние SaaS-сервисы редко нагружают сервер всплесками, как интернет-магазин в распродажу, но держат ровную нагрузку на базу данных и память весь рабочий день. Готовый тариф общего хостинга под такую задачу обычно не подходит — нужен VDS с собственным расчётом ресурсов. Разбираем, что считать первым: процессор, память или диск, и как понять, что текущий тариф пора менять.
Что определяет нагрузку CRM и SaaS на ресурсы
Главный потребитель ресурсов в CRM и SaaS — не веб-сервер, а база данных: каждый открытый отчёт, поиск по клиентам или фильтр в таблице превращается в запрос к СУБД. Число одновременно работающих сотрудников напрямую умножается на число параллельных запросов к базе, и именно это, а не число посетителей сайта, задаёт реальную нагрузку.
Как посчитать память и диск под базу данных
Отправная точка — размер самой базы данных на диске плюс запас для её роста за год-два; к этому добавляется память, которую СУБД держит под кеш часто запрашиваемых данных — чем больше этот кеш, тем реже база обращается к диску напрямую. Проверить текущее потребление памяти процессом базы данных можно прямо на сервере.
# Текущее потребление памяти процессом базы данных
ps -o rss,cmd -C mysqld | awk '{sum+=$1} END {print sum/1024, "MB"}'Как посчитать процессор и число ядер
Параллельные запросы от разных сотрудников лучше распределяются по нескольким ядрам, чем в сценарии с одним тяжёлым процессом, поэтому для CRM на 10–20 одновременных пользователей число ядер обычно важнее их частоты. Какую архитектуру процессора выбирать под такой тип нагрузки — с акцентом на многопоточность, а не на пиковую частоту одного ядра — разобрано в статье про выбор процессора для сервера.
Что означают лимиты тарифа и как их читать
Помимо процессора, памяти и диска у тарифа почти всегда есть лимиты, которые легко упустить при расчёте: число одновременных подключений к базе, квота на операции ввода-вывода диска, трафик. Для CRM с активной работой весь день именно эти скрытые лимиты, а не базовые характеристики тарифа, чаще всего становятся первым узким местом.
- Число одновременных подключений к базе данных — ограничивает, сколько сотрудников работает параллельно без ошибок соединения.
- Квота операций ввода-вывода диска — проявляется как замедление при одновременном сохранении отчётов несколькими людьми.
- Лимит оперативной памяти на процесс — при превышении процесс СУБД может быть принудительно остановлен системой.
- Сетевой трафик — редко критичен для внутренней CRM, но важен, если к SaaS подключаются внешние клиенты.
- Число процессов или потоков на тариф — ограничивает, сколько фоновых задач (рассылки, отчёты, синхронизация) выполняется одновременно.
Полный перечень типичных лимитов и где их смотреть в панели управления разобран в статье о лимитах и ресурсах хостинга.
Мониторинг нагрузки и момент расширения тарифа
Решение о расширении тарифа лучше принимать по графику нагрузки за недели, а не по единичной жалобе на медленную работу: разовый всплеск в конце месяца при закрытии отчётов — не повод увеличивать ресурсы навсегда, а стабильный рост среднего потребления — повод.
| Показатель | Нормальный уровень | Сигнал к расширению |
|---|---|---|
| Загрузка CPU | ниже 70% в рабочие часы | стабильно выше 85% несколько дней подряд |
| Использование ОЗУ | стабильно ниже лимита тарифа | близко к лимиту, растёт из недели в неделю |
| Очередь запросов к базе | запросы выполняются без ожидания | запросы начинают ждать очереди |
| Свободное место на диске | больше 20% от объёма | ниже 10% от объёма |
Как собрать эти показатели в одном месте и настроить уведомление заранее, а не постфактум, описано в статье про мониторинг ресурсов VDS.
Частые вопросы
Сколько памяти закладывать на одного сотрудника в CRM?
Точной универсальной цифры нет — она зависит от того, какие отчёты и выгрузки открывает сотрудник: лёгкий просмотр карточек клиента и тяжёлая выгрузка в Excel на тысячи строк потребляют совсем разный объём памяти на стороне базы данных. Ориентироваться стоит на собственные замеры после запуска, а не на чужие готовые цифры.
Нужен ли отдельный VDS под базу данных и под приложение?
На небольшой нагрузке оба компонента обычно спокойно живут на одном VDS. Разделение на два сервера имеет смысл, когда база данных и само приложение конкурируют за одну и ту же память или процессор в пиковые часы, и становится видно, что рост одного компонента мешает другому.
Как учитывать рост числа пользователей SaaS при выборе тарифа?
Разумный подход — брать тариф с запасом на предсказуемый рост на несколько месяцев вперёд, а не на весь прогнозируемый рост сразу: виртуальный сервер проще расширить по мере необходимости, чем оплачивать избыточные ресурсы заранее на неопределённый срок.