32 слота или 64 слота — как выбрать вместимость сервера

MAATRIX GAMES

Купишь 32 слота — а через месяц полсервера видит очередь на вход в пиковые часы и тихо расходится по другим проектам. Купишь 64 «на вырост» — и полгода платишь за тариф, где реально заняты 8-12 слотов из шестидесяти четырёх, а остальное просто греет воздух в панели хостера. Оба сценария — не про удачу, а про то, что вместимость сервера почти никогда не считают, а угадывают. Разберём, как перевести реальную (или ожидаемую) базу игроков в конкретное число слотов, и что физически меняется на сервере, когда вы переходите с 32 на 64.

Слоты — это лимит, а не прогноз онлайна

Слот — это просто верхняя граница одновременных подключений, которую вы задаёте в конфиге: max-players в server.properties у Minecraft, maxplayers в стартовых параметрах Rust, лимит в gameinfo у CS2-сервера. Сам по себе пустой слот ничего не ест — если из 64 разрешённых мест занято 10, сервер не тратит ресурсы на 54 «призрака». Но вот тарифный план хостинга, который даёт вам возможность выставить 64 слота, почти всегда даёт вместе с этим больше vCPU и RAM — и вы платите за эту вместимость independent от того, заполняется она или нет.

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

Правило 10-20%: сколько игроков реально онлайн одновременно

Если у вас есть база из N зарегистрированных или активных игроков (подписчики Discord-сервера, база из вайтлиста, постоянные участники прошлого сезона), то одновременно онлайн в пиковый час обычно оказывается заметно меньше N. По опыту администрирования игровых сообществ пиковый онлайн чаще всего укладывается в диапазон 10-20% от базы активных игроков — это ориентир из практики, а не измеренная статистика по вашему конкретному проекту, и он сильно зависит от:

• таймзоны аудитории — если комьюнити раскидано по трём часовым поясам, пик размазывается и доля одновременного онлайна ниже;
• типа геймплея — вайп-день на Rust даёt кратковременный всплеск в разы выше обычного пика, персистентный Minecraft SMP держит онлайн ровнее;
• ивентов — открытие нового сезона, стрим, конкурс с призом собирают почти всю базу разом, и это надо закладывать отдельно, а не в базовый расчёт;
• входного порога — публичный сервер без вайтлиста конвертирует случайных заходящих в куда меньшую долю «постоянных», чем закрытое комьюнити друзей.

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

Формула: от базы игроков к числу слотов

Практическая методика в три шага:

1. Пиковый онлайн ≈ База активных игроков × 0.10–0.20
2. Слоты = Пиковый онлайн × коэффициент запаса (1.3–1.5)
3. Округлить вверх до ближайшего тарифного шага хостера

Коэффициент запаса нужен не «на всякий случай», а под конкретную причину: игроки заходят пачками (гильдия из 5 человек подключается одновременно), часть слотов держится под модераторов/админов, а очередь на вход даже на 2-3 человека уже читается новыми игроками как «сервер мёртвый, тут никого нет» — и это сильнее бьёт по репутации, чем переплата за пару лишних слотов.

Пример расчёта. База — 150 активных игроков в Discord-комьюнити под Minecraft SMP:

Пиковый онлайн = 150 × 0.15 ≈ 22 игрока
Слоты = 22 × 1.4 ≈ 31 слот
→ округляем вверх → 32 слота

Если та же база планирует вырасти вдвое за сезон (набор новых игроков, реклама в Директе или на форумах), закладывайте расчёт сразу под целевую базу в 300, и тогда 64 слота — обоснованный выбор с самого старта, а не запас «просто так». Подробная методика расчёта именно RAM под эти же слоты разобрана в статье сколько RAM нужно под игровой сервер.

Что растёт вместе со слотами: CPU и RAM по типам игр

Вместимость сервера не масштабирует нагрузку линейно — в разных играх узкое место разное:

Ключевой нюанс: у Minecraft и ARK рост слотов давит в основном на RAM (больше загруженного мира, больше сущностей), а у CS2 — на CPU и стабильность тикрейта при полном составе. У Rust оба фактора смешаны, и часто карта размером 4000+ уже требует ресурсов как под 64 слота, даже если реально играет 15 человек — про это подробнее в статье лаги на большой карте Rust. Поэтому нельзя просто взять цифру «32 или 64» из воздуха — она должна биться и с ожидаемым онлайном, и с тем, что конкретно ваша сборка (моды, плагины, размер карты) реально требует.

32 или 64 — сравнение сценариев

Из таблицы видно частую ошибку: для дисциплинированных форматов вроде CS2-матчей 5x5 бессмысленно покупать 32-64 слота — там играет фиксированное число участников, и переплата идёт исключительно за неиспользуемую вместимость. А для публичных RP или модовых серверов, наоборот, 32 слота часто становятся потолком роста уже в первый месяц.

Типичные ошибки: переплата за пустые слоты и дефицит в пиках

Переплата. Тариф хостинга на 64 слота почти всегда стоит дороже 32-слотового не из-за самих слотов, а из-за более высокого выделенного CPU/RAM — и вы платите за эту вместимость каждый месяц, даже если сервер набирает 10 человек по вечерам. Если у вас нет чёткого плана роста базы игроков в ближайшие 1-2 месяца, разумнее взять план поменьше и мониторить реальный онлайн через панель хостера или простую RCON-команду:

list

(для Minecraft — покажет текущий онлайн и список ников; для Rust — аналог через RCON-консоль status).

Дефицит в пиках. Обратная ошибка — взять впритык под средний онлайн и получить очередь в вечер пятницы или в день вайпа. Игрок, который видит «сервер полон, попробуйте позже», в большинстве случаев не возвращается через 20 минут — он просто уходит к конкуренту. Именно для этого в формуле выше заложен коэффициент запаса 1.3-1.5: он покрывает разницу между «средним» и «пиковым» онлайном, а не добавляется произвольно.

Если сервер уже упирается в вместимость, а плагины/моды и так не резиновые, есть путь без пересборки с нуля — сеть из нескольких серверов через прокси BungeeCord или Velocity: игроки заходят на общий адрес, а прокси раскидывает их по фактическим инстансам. Это отдельная архитектура, разобранная в статье BungeeCord и Velocity — сети Minecraft-серверов, и она часто выгоднее, чем просто взять план с двойным числом слотов на одном инстансе. А если вопрос не в слотах, а в том, дедик или VPS вообще нужен под вашу нагрузку — это разбирали в статье выделенный сервер или VPS под игру.

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