Как выбрать конфигурацию сервера под задачу

Вопрос "какой сервер взять" почти всегда задают неправильно. В прайсе видно ядра, гигабайты и рубли, но из этого не следует, хватит ли конфигурации под конкретный проект.

Правильная последовательность обратная: сначала понять, какой ресурс станет узким местом именно у вашей задачи, и уже потом смотреть тарифы. Разберём, за что отвечает каждый параметр, как посчитать потребность и как измерить её на работающем проекте.

Четыре параметра, из которых состоит сервер

Коротко по каждому:

Процессор (vCPU). Отвечает за скорость вычислений: обработку запросов, компиляцию, генерацию страниц, работу интерпретатора PHP или Python. Нехватка выглядит как равномерное замедление всего сразу под нагрузкой.

Оперативная память (RAM). Определяет, сколько данных и процессов помещается одновременно. Нехватка памяти опаснее нехватки процессора: система начинает выгружать данные на диск, а в критической ситуации принудительно завершает процессы. Сервис при этом просто падает.

Диск. Тут важны два разных параметра. Объём - сколько влезет. Скорость - как быстро читается и пишется. Для баз данных решает именно скорость, поэтому NVMe и обычный SATA SSD дают разный результат на одной и той же задаче.

Сеть. Ширина канала и его гарантированность. Для типового сайта редко бывает узким местом, но для файловой раздачи, видео или бэкапов это первое, во что упираются.

Сколько ресурсов нужно типовым задачам

Таблица ниже - рабочие ориентиры для старта, а не теоретический минимум, при котором оно запускается.

Две оговорки. Для 1С и игровых серверов важна не столько многоядерность, сколько частота ядра: эти задачи плохо распараллеливаются. Для баз данных наоборот полезнее память, потому что горячие данные должны помещаться в неё целиком.

Как посчитать память под базу данных

Самый частый источник тормозов - база, которая не помещается в память. Проверяется просто.

Посмотрите размер базы:

SELECT pg_size_pretty(pg_database_size('имя_базы'));

Правило: активная часть базы должна помещаться в оперативную память. Активная - это те данные, к которым реально идут запросы, обычно от 20 до 40 процентов объёма.

Если база в память не влезает, каждый запрос идёт на диск. На NVMe это терпимо, на SATA SSD заметно, на HDD проект становится неработоспособным.

Как измерить реальную нагрузку

Если проект уже работает, гадать не нужно - есть цифры.

Процессор и общая картина. Смотрим load average:

uptime

Три числа в конце - средняя загрузка за 1, 5 и 15 минут. Сравнивать надо с количеством ядер:

nproc

Если load average устойчиво выше числа ядер, процессор в дефиците. Значение 4.0 на 4 ядрах означает полную загрузку, 8.0 на 4 ядрах - что задачи стоят в очереди вдвое дольше, чем выполняются.

Память. Ключевая строка - available, а не free:

free -h

Колонка free показывает совершенно неиспользуемую память, и её всегда мало: Linux отдаёт свободное под кеш, и это правильно. Смотреть надо на available - сколько система может выдать приложению прямо сейчас. Если available стабильно ниже 10 процентов от общего объёма, памяти не хватает.

Отдельно проверьте, не ушла ли система в swap:

vmstat 1 5

Ненулевые значения в колонках si и so означают активный обмен с диском. Это прямой сигнал добавить память.

Диск: объём и скорость.

df -h

iostat -x 1 3

В выводе iostat смотрите на %util. Устойчивые значения около 100 процентов означают, что диск - узкое место. Колонка await показывает время ожидания операции в миллисекундах: для NVMe нормой считаются единицы миллисекунд, десятки означают проблему.

Утилита iostat входит в пакет sysstat, его может не быть в системе:

sudo apt install sysstat -y

Кто именно потребляет ресурсы.

htop

Сортировка по F6, дальше по колонке CPU или MEM. Часто выясняется, что дело не в нехватке ресурсов, а в одном процессе, который ведёт себя неправильно.

Собираем всё вместе

Порядок действий, который работает:

• Определите тип задачи и возьмите строку из таблицы выше как отправную точку.
• Проверьте, помещается ли база данных в память. Если нет, увеличьте RAM.
• Оцените рост на горизонте полугода. Двукратный запас по диску разумен, по памяти и ядрам - нет.
• Возьмите NVMe, если в проекте есть база данных.
• Запуститесь, снимите метрики под реальной нагрузкой через неделю и скорректируйте.

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

Вертикальное и горизонтальное масштабирование

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

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

Практическое правило: пока хватает вертикального, занимайтесь им. Горизонтальное масштабирование оправдано, когда упёрлись в потолок железа или когда простой недопустим и нужен резерв.

Частые ошибки

Берут с запасом в три раза. Логика "пусть будет" стоит денег каждый месяц. Ресурсы виртуального сервера меняются за минуты, поэтому запас нужен небольшой.

Экономят на диске. Память и ядра меняются легко, а увеличение диска иногда требует остановки сервера. Диск - единственный параметр, где запас реально оправдан.

Считают только объём диска, забывая про скорость. Для базы данных 40 ГБ на NVMe лучше, чем 200 ГБ на SATA SSD.

Путают free и available. Видят маленький free, докупают память, ничего не меняется. Смотреть надо на available.

Не проверяют гарантированность ресурсов. Четыре ядра в тарифе с оверселлингом и четыре гарантированных ядра ведут себя под нагрузкой по-разному.

Масштабируют вслепую. Добавляют память там, где узкое место в диске. Сначала метрики, потом покупка.

Частые вопросы

Что важнее: больше ядер или выше частота? Зависит от задачи. Веб-серверы, Docker и базы данных обрабатывают запросы параллельно и выигрывают от количества ядер. 1С, игровые серверы и однопоточные расчёты упираются в частоту.

Можно ли увеличить ресурсы без простоя? Память и процессор на KVM обычно добавляются с короткой перезагрузкой, иногда без неё. Расширение диска чаще требует остановки. Уменьшение диска, как правило, невозможно.

Сколько места занимает сама система? Чистая Ubuntu или Debian - около 2-3 ГБ. Плюс логи, кеш пакетов и временные файлы. При расчёте закладывайте 5 ГБ на систему.

Нужен ли swap? Полезен как страховка от аварийного завершения процессов при пике. Но постоянная работа в swap означает, что памяти не хватает, и лечится это добавлением RAM, а не увеличением swap.

Как понять, что пора на выделенный сервер? Три признака: упёрлись в максимальный тариф виртуальных серверов, нужна предсказуемость без соседей вообще, или требуется специфическое железо. До этого момента виртуальный сервер выгоднее.

Что делать, если нагрузка скачет? Считайте по пикам, а не по средним значениям. Средняя загрузка 20 процентов при ежедневных пиках до 100 означает, что ресурсов не хватает именно тогда, когда они нужны.

Не уверены в конфигурации? Подберём сервер под задачу и рассчитаем конфигурацию бесплатно. Виртуальные и выделенные серверы на NVMe в дата-центрах Tier III, ресурсы гарантированы и меняются за минуты. Первые 7 дней - тестовый период с возвратом средств.