Планирование Dedicated: CPU, RAM, диски и резерв

Два предложения с одинаковым числом core, объемом RAM и диска могут означать совсем разный выбор. Разница редко помещается в строку спецификации: какие запросы используют CPU, какие процессы делят память и что произойдет после отказа диска или приложения? Полезная заявка на Dedicated начинается с этих вопросов.

Начните заявку с работы, которую должен выполнять сервер

Перечислите приложения, движок базы, фоновые задания и внешние соединения. Укажите обычную и пиковую активность, длительность batch и рост данных. Невысокий средний CPU днем не исключает сильную нагрузку на диски и память во время ночного отчета.

Различайте CPU-bound вычисления, memory-bound работу с недостатком места для рабочих данных и I/O-bound процессы, ожидающие операции хранения. Несколько ограничений могут действовать одновременно.

Выберите важный рабочий цикл и условие приемки. Например, ночная задача должна завершаться до начала рабочего дня, а действие оператора - получать ответ за согласованное время. Примеры показывают форму требования. Реальный срок и допустимая ошибка зависят от вашего бизнеса; название сервера само по себе их не обещает.

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

CPU: за пределами среднего значения

Учитывайте поколение процессора, производительность ядра, параллелизм приложения и лицензирование. Большое число ядер не ускоряет последовательную задачу автоматически. Не каждому запросу нужно постоянно отдельное ядро, поэтому посещаемость нельзя напрямую переводить в core count.

Используйте измерения своего workload. Доступные Linux pressure metrics помогают оценить ожидание CPU, памяти и I/O, но зависят от kernel и конфигурации. Один показатель не является полным диагнозом причины.

Низкий средний CPU не означает, что все процессы работают свободно. Важный поток может быть перегружен при простаивающих остальных core. Медленный запрос также может ждать диск или внешний API. Свяжите операцию, CPU и признаки ожидания; увеличение ресурсов по одному графику является дорогим предположением.

RAM - общий бюджет

Учтите OS, процессы приложения, базу данных, кеш и управляющие инструменты. Отдельно оцените пиковую память процесса и число одновременно активных процессов. Один параметр СУБД не обязательно отражает всю ее память.

Условной системе требуется 6 GiB рабочей памяти. Чтобы оставить свободными 25% общей емкости, расчет будет 6 / (1 - 0.25) = 8 GiB. Простое добавление 25% к шести дает другой резерв. Реальный пик нужно измерять отдельно: формула не является benchmark.

Не считайте одну память дважды. Лимит container может включать cache базы или только приложение. Для нескольких сервисов сопоставьте пики с реальными временными интервалами. Сумма несвязанных максимумов завысит требование, а игнорирование пиков занизит его.

Свяжите запас с причиной: сезонным спросом, batch-задачей или дополнительными процессами при релизе. Универсальный процент «на всякий случай» не объясняет, когда исчерпается ресурс. Запишите сигнал для пересмотра и время, необходимое для следующего шага.

Объем хранилища связан с восстановлением

Сумма номиналов дисков не равна месту для приложений. Например, зеркало из двух дисков по 960 GB дает номинально 960 GB для данных до расходов файловой системы, OS и прочего. Фактический полезный объем уточняйте для предлагаемой схемы.

RAID не заменяет backup. Случайное удаление и повреждение данных может затронуть зеркальную копию. Расположение резервной копии, retention и восстановление являются отдельными требованиями. Snapshot сам по себе также не доказывает наличие независимого backup.

Учитывайте профиль I/O: последовательная передача больших файлов, случайные небольшие операции и latency описывают разные задачи. Обозначение NVMe не гарантирует время ответа конкретного приложения.

Пишите пример хранилища с единицами. Два условных диска по 960 GB в mirror содержат две копии данных, а не 1920 GB usable пространства. Файловая система, единицы и резерв требуют уточнения. Объединение RAID и backup одной строкой мешает сравнению.

Для восстановления определите допустимую потерю данных и срок возврата конкретного сервиса. Затем уточните, какой тест действительно выполнен: восстановление файла, базы или целого приложения. Наличие копии и работающий восстановленный сервис - разные результаты. Расположение, изоляция и retention подтверждаются отдельно.

Сравнивайте предложения на одном языке

Сравните два условных случая: отчетность с небольшим числом пользователей и тяжелыми вычислениями, а также магазин с параллельными запросами и частыми обновлениями. Равная емкость дисков не означает одинаковые требования к CPU, RAM и I/O.

Добавьте стоимость эксплуатации

Проверьте setup, срок контракта, лицензии OS/панели, администрирование, backup, IP и сеть. Ориентируйтесь на текущую страницу SERVER1 и конкретное предложение. Не предполагайте постоянство цен или наличие любой конфигурации.

Опишите управление действиями. Кто обновляет OS, следит за alerts, меняет конфигурацию приложения и ведет инцидент? Managed остается заголовком, пока не подтвержден scope конкретной услуги. Уточните включенные лицензии, сторонние сервисы и разовые работы.

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

Brief для содержательного технического разговора

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

Назначение: [приложение и важная операция]
Период наблюдения: [даты и пик]
CPU/RAM/I/O: [измерено или предстоит измерить]
Данные: [объем, рост, usable capacity]
Восстановление: [допустимая потеря и срок]
Управление: [ответственные и уточняемый scope]
Приемка: [сценарий и условие решения]

С этим brief сравните актуальные Dedicated-серверы. Если нужна помощь в эксплуатации, перечислите работы в запросе Managed Dedicated. Совместное уточнение ресурсов и границ услуги снижает долю предположений в покупке.

Для первых наблюдений: Monitoring Linux VPS: как правильно читать CPU, RAM, Disk и Load.

Технические источники по resource pressure и настройке памяти: Linux kernel - Pressure Stall Information; PostgreSQL - Resource consumption.