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