Краткий ответ.
Измерьте отдельно CPU, RAM и операции ввода-вывода под репрезентативной нагрузкой, затем добавьте запас на пики и плановые задачи. После этого сравните эти потребности с доступными конфигурациями, не делая вывод об универсальной вместимости лишь по числу vCPU.
- vCPU — это виртуальный вычислительный ресурс, а не обещание пропускной способности приложения.
- Доступная RAM и признаки давления на память важнее отдельного процента.
- Объём NVMe, скорость диска и задержка операций ввода-вывода — это разные критерии.
01Сначала опишите репрезентативную нагрузку
Зафиксируйте реально используемые операции: отображение страниц, вызовы API, запросы к базе данных, преобразование файлов или плановые задачи. Определите пиковые периоды и задачи, которые пересекаются. Среднее за день может скрывать тяжёлый импорт или резервное копирование, выполняемые в неподходящее время.
Чтобы сравнить две конфигурации, используйте одни и те же данные, версии и настройки. Фиксируйте время отклика и ошибки, затем потребление ресурсов во время этого теста. Показатель производительности имеет смысл, только если известны сценарий и условия, в которых он получен.
02Когда нужно больше vCPU?
KVM предоставляет гостевой системе виртуальные процессоры. Их число описывает конфигурацию, но само по себе не определяет поведение вашего приложения. Программа, выполняющая в основном одну задачу за раз, не обязательно распределит эту работу по всем доступным vCPU.
Наблюдайте за процессами, которые потребляют CPU, за очередями задач и за моментами, когда ответы замедляются. Если процессор ждёт хранилище или удалённый сервис, добавление вычислений может не устранить причину. Начните с определения ресурса, который блокирует обработку.
03Интерпретируйте память по её симптомам
Система может использовать часть RAM для полезных кэшей. Поэтому память, отображаемая как используемая, сама по себе не доказывает нехватку. Изучите доступную память, процессы, обмен со swap и события нехватки памяти.
В Linux такие инструменты, как top, vmstat или панели мониторинга вашей системы, помогают наблюдать эти изменения. Их наличие зависит от вашей установки. Сравните обычный период и пик, затем проверьте, совпадает ли замедление с реальным давлением на память.
04Планируйте объём и активность хранилища
Учтите систему, приложение, данные и временные файлы. Добавьте место, необходимое для обновлений, экспорта и ожидаемого роста. Хранение рабочей копии на том же диске также может увеличить требуемое место, не обеспечивая независимой защиты.
Заявленный объём в ГБ не измеряет скорость ваших обращений. Наблюдайте объём и длительность чтения и записи с помощью подходящих инструментов, в частности iostat, если он установлен. Термин NVMe не даёт гарантированного результата для вашей базы данных или приложения.
05Чтение пяти конфигураций WispHost
Линейка позволяет сравнивать вместе вычисления, память и хранилище. Таблица ниже описывает ресурсы каталога; она не превращает каждую конфигурацию в гарантированное число сайтов, подключений или запросов в секунду.
| Конфигурация | vCPU | RAM | Хранилище NVMe |
|---|---|---|---|
| Wisp Spark | 2 | 4 ГБ | 60 ГБ |
| Wisp Core | 3 | 8 ГБ | 120 ГБ |
| Wisp Flow | 4 | 16 ГБ | 240 ГБ |
| Wisp Scale | 6 | 32 ГБ | 480 ГБ |
| Wisp Prime | 8 | 64 ГБ | 800 ГБ |
06Задайте отправную точку и критерии пересмотра
Выберите конфигурацию, которая покрывает ваш измеренный сценарий с разумным запасом, затем зафиксируйте пороги для пересмотра: недостаточно доступной памяти, хранилище скоро заполнится или время ответа превышает вашу цель при известной нагрузке. Универсального процента запаса для всех проектов не существует.
Перед изменением повторите тот же тест и уточните у команды возможности смены линейки. Хорошо организованные приложение, база и стратегия резервного копирования упрощают это решение. Сервер должен соответствовать измеренной потребности, а не компенсировать неизменную оценку.
Источники и ссылки
Чтобы глубже разобраться в технических моментах и найти первоисточники информации.