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

MAATRIX

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

С чего начинается расчёт: профиль нагрузки

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

Соберите четыре цифры. Первая — сколько одновременных пользователей или запросов вы ждёте в пике, а не в среднем: сервер живёт по пикам. Вторая — характер работы: считает ли приложение (CPU-bound) или в основном ждёт диск и сеть (IO-bound). Третья — объём горячих данных, то есть той их части, к которой обращаются постоянно. Четвёртая — требования к отклику: 50 мс на запрос и 500 мс — это разные машины.

Без этих цифр любой подбор превращается в гадание. С ними расчёт становится арифметикой.

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

Процессор: ядра, частота и поколение

Для выделенного сервера ключевой вопрос — что важнее вашей задаче: много ядер или высокая частота одного. Многопоточные нагрузки (веб под высокой конкуренцией, контейнеры, сборки, кодирование) любят число ядер. Однопоточные и «тонкие» на распараллеливание (1С, часть SQL-запросов, старые движки) выигрывают от частоты и большого кэша.

Ориентир по ядрам: на веб-приложение прикиньте пиковый RPS, поделите на то, сколько запросов одно ядро обслуживает за секунду (для типичного PHP/Python-стека это десятки, для лёгкого API — сотни), добавьте 30–40% запаса под всплески и фоновые задачи. Для баз данных отталкивайтесь от числа активных параллельных соединений: одно ядро комфортно тянет несколько тяжёлых запросов.

По железу в 2026 году разумная база — AMD EPYC (Milan/Genoa) для многоядерных задач и Intel Xeon с высокой частотой там, где важен один поток. EPYC на 32–64 ядра закрывает большинство серверных сценариев, а Xeon с 3,5+ ГГц — те, где приложение упирается в частоту.

Не забудьте про гипертрединг и реальные потоки. Производитель считает «ядрами» логические потоки, но два потока на одном физическом ядре не равны двум ядрам: под ровной вычислительной нагрузкой прирост от SMT — 20–30%, а не 100%. Если приложение критично к латентности каждого запроса, ориентируйтесь на физические ядра, а логические считайте бонусом на фоновые задачи. И следите за кэшем L3: для баз данных и 1С большой кэш процессора часто даёт больше реального ускорения, чем лишние два ядра.

Оперативная память: сколько и почему ECC

Память — тот ресурс, где экономия бьёт больнее всего: при нехватке система уходит в swap на диск, и производительность падает в разы. Считайте RAM как сумму трёх слагаемых: память под саму ОС и служебные процессы (обычно 1–2 ГБ), память на одно рабочее соединение или воркер, умноженная на их пиковое число, и кэш горячих данных.

Для баз данных отдельное правило: в идеале вся горячая часть данных должна помещаться в RAM, иначе каждый запрос идёт на диск. Если рабочий набор — 40 ГБ, сервер с 64 ГБ будет летать, а с 16 ГБ — задыхаться независимо от процессора.

Про ECC-память: на арендованном сервере, работающем месяцами без перезагрузки, она защищает от одиночных сбоев битов, которые иначе тихо повреждают данные или роняют процессы. Для боевой базы, финансов и любой системы с ценными данными ECC — не опция, а норма. Все серверные платформы EPYC и Xeon её поддерживают.

Диски: тип, объём и RAID

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

Объём считайте от текущих данных плюс прогноз роста на 12–18 месяцев плюс место под логи, временные файлы и, если бэкапы лежат локально, под них. Заполненный больше чем на 80% SSD начинает терять в скорости — закладывайте этот зазор.

RAID выбирайте по приоритету. RAID 1 (зеркало) — минимум для любого продакшена, переживает смерть одного диска. RAID 10 — золотая середина скорости и надёжности под базы. RAID 5/6 экономят место на больших массивах, но проседают на записи и долго восстанавливаются. Аппаратный RAID-контроллер с кэшем и BBU снимает нагрузку с процессора.

Сеть: канал, трафик и запас

Сетевой канал считают по двум величинам: пиковая полоса и объём трафика в месяц. Полосу оцените по числу одновременных отдач: тысяча пользователей, тянущих по 2 Мбит/с потока, — это уже 2 Гбит/с в пике, и канал 1G здесь станет узким горлом. Для отдачи статики, стриминга и файлов сразу смотрите в сторону 10G.

Объём трафика важен там, где провайдер его лимитирует: посчитайте средний ответ, умножьте на число запросов в месяц, добавьте запас. Для большинства бизнес-задач канала 1 Гбит/с с достаточным объёмом хватает, а 10G берут под медиа, CDN-узлы и крупные API.

Отдельно смотрите на латентность до вашей аудитории — это часть сетевого расчёта, которую забывают. Самый мощный процессор не спасёт отклик, если сервер физически далеко от пользователей: до российской аудитории минимальный пинг дают узлы в РФ, до Европы — площадки в UK и на континенте, до американских сервисов — локации в США. Полоса и латентность решают разные задачи, и оба параметра стоит закрывать осознанно, а не по остаточному принципу.

Запас, отказоустойчивость и честная граница с VPS

Закладывайте запас, но осмысленно: 30–40% по CPU и RAM на рост и пики — здоровая практика, двукратный «на всякий случай» — просто переплата. Лучше выбрать платформу, где можно доставить память и диски, чем сразу купить максимум.

И честно: выделенный сервер нужен не всегда. Если у вас сайт-визитка, небольшой интернет-магазин, тестовый стенд или пет-проект, где нагрузка измеряется десятками запросов в минуту, — это территория VPS. Виртуальный сервер дешевле, поднимается за минуты и масштабируется в пару кликов. Выделенный сервер оправдан, когда вам нужны все ресурсы физической машины целиком, предсказуемая производительность без соседей, конкретное железо (быстрые NVMe, много RAM, мощный CPU) или изоляция под требования безопасности. Не уверены — начните с VPS и переезжайте на dedicated, когда упрётесь в потолок.

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