Какой сервер нужен: считаем vCPU, RAM и диск

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

Три ресурса и что каждый ограничивает

vCPU — сколько вычислений сервер делает одновременно. Упирается в ядра обработка запросов без кэша, шифрование TLS на большом трафике, сжатие картинок, сборка проектов, отчёты в 1С. Сайт-визитка на статике не использует даже одного ядра полностью.

RAM — сколько данных держится в памяти. Здесь живут процессы PHP-FPM или Node, база данных с её кэшем, кэш страниц. Нехватка памяти видна сразу: сервер начинает уходить в swap, и сайт замедляется в разы, даже если процессор свободен.

Диск — не только объём, но и скорость. База данных постоянно читает и пишет мелкие блоки; на SATA SSD это на порядок медленнее, чем на NVMe. Если выбирать между «больше ядер» и «NVMe вместо SATA», для нагрузки с базой почти всегда выигрывает NVMe.

Методика расчёта за полчаса

1. Посчитайте пик запросов. Не среднее за сутки, а пик: у рабочего сайта это 10:00–12:00, у магазина — акции, у медиа — публикация материала.
2. Замерьте время обработки одного запроса. Для WordPress с кэшем это 20–80 мс, без кэша — 300–900 мс. Для API на Go или Node — 5–40 мс.
3. Перемножьте. Пик 50 запросов в секунду × 0,3 с = 15 одновременно занятых обработчиков. Именно столько процессов PHP-FPM (или потоков приложения) нужно держать в памяти.
4. Посчитайте память под обработчики. PHP-FPM в среднем 40–80 МБ на процесс, Node — 60–150 МБ, Java — от 300 МБ. Умножьте на число процессов и добавьте базу.
5. Добавьте систему и диск. ОС занимает 2–4 ГБ; данные, логи и бэкапы — по факту. Оставьте 30% свободного места: переполненный диск останавливает базу.

Типовые ошибки при выборе

1. Взять много ядер, но оставить SATA

Классика: 4 vCPU и SATA-диск под базу. Процессор простаивает, запросы ждут диск. Для базы NVMe даёт больше, чем удвоение ядер.

2. Экономить на памяти под PHP-FPM

Пять процессов PHP-FPM по 70 МБ — уже 350 МБ только на обработчики, плюс MySQL с кэшем запросов. На сервере с 1 ГБ памяти сайт будет работать, но при первом же пике уйдёт в swap.

3. Планировать бэкапы на том же диске

Копия базы рядом с базой не спасает: при потере диска теряется и то, и другое. Бэкапы — в объектное хранилище или на другой сервер.

4. Забыть про TTL при переезде

Если TTL DNS — сутки, переключение на новый сервер растянется на сутки. Перед миграцией снизьте TTL до 5–10 минут за день и верните обратно после.

Чек-лист перед покупкой

• Известен пик запросов в секунду и время обработки одного запроса.
• Понятно, где кэш: страницы, объекты, база — что из этого есть.
• Посчитана память под обработчики и базу, а не «на глазок».
• Есть запас 30% по диску и 30–50% по памяти.
• Проверено, что тариф можно расширить без переустановки.
• Есть root-доступ и консоль — на случай, если SSH перестанет отвечать.