Выделенный сервер или VPS для крупного модпака Minecraft

MAATRIX GAMES

Ставишь All the Mods 10 или какую-нибудь RAD2 (RLCraft And Dungeons, если вдруг), а сервер через полчаса игры в мире с десятком чанк-лоадеров начинает тикать раз в секунду вместо двадцати. Первая мысль — "мало RAM, докину ещё" — но часто дело не в объёме памяти, а в том, что VPS в моменте пиковой нагрузки просто не даёт тебе выделенное ядро CPU, потому что оно занято соседом по хосту. Разберём, чем крупный модпак отличается от обычного сервера с точки зрения ресурсов и когда действительно пора переезжать на dedicated.

Чем модпак нагружает сервер иначе, чем ванилла

Ванильный Minecraft-сервер или лёгкая сборка на 10-15 плагинов почти всегда упирается в одно и то же: TPS падает от количества сущностей и редстоун-контраптов, а память растёт линейно с числом загруженных чанков. Один процесс, предсказуемая нагрузка, VPS с честными 2-4 виртуальными ядрами справляется без вопросов.

Крупный модпак (FTB, All the Mods, StoneBlock, GregTech-сборки) — другая история:

• Память съедается не чанками, а тик-логикой модов. Машины Applied Energistics, Mekanism-трубы, Create-контраптоны каждый тик что-то считают, даже если игрок не в зоне видимости — если чанк держится force-loaded чанк-лоадером.
• Нагрузка на CPU скачкообразная, а не ровная. Пока никто не крафтит и не двигает механизмы — сервер спокоен. Как только пять игроков одновременно гриндят фабрику — тикрейт может провалиться за секунды, а не деградировать плавно.
• Старт мира — отдельный пик. Загрузка датапаков, генерация структур модов, прогрев кэшей Forge/NeoForge при первом запуске после обновления модпака может занять минуты и требует свободного CPU здесь и сейчас, а не "в среднем по хостингу".
• GC-паузы у JVM бьют больнее. При хипе 10-16 ГБ сборщик мусора Java делает более крупные и заметные паузы, если ему не хватает процессорного времени вовремя их обработать — на VPS с "shared" CPU это ощущается как рывки раз в минуту-две.

Именно вторая и третья особенность — главная причина, почему модпак ведёт себя на VPS хуже, чем "просто прикинули RAM и хватит".

Проблема шумных соседей на VPS

VPS — это виртуальная машина на общем физическом сервере, где ещё десятки таких же VPS делят между собой процессор, диск и сеть. Технология виртуализации (обычно KVM) честно нарезает ядра и гарантирует объём RAM — но "гарантирует RAM" не значит "гарантирует одинаковую скорость CPU в любой момент".

Если у тебя vCPU без явного резервирования (провайдер продаёт oversell — больше виртуальных ядер, чем физических, ставка на то, что не все клиенты нагружают процессор одновременно), то в момент, когда сосед по хосту разворачивает у себя рендер-ферму или майнит что-то на CPU, твой модпак-сервер может получить свою долю такта с задержкой. Для веб-сайта это незаметно. Для сервера, где JVM ждёт CPU-time каждый тик (50 мс на тик при 20 TPS), даже небольшая задержка выливается в подвисания.

Признаки, что тебя зажимает "шумный сосед", а не твой модпак:

• TPS проседает не пропорционально числу онлайн-игроков — падает даже когда на сервере 1-2 человека в спокойной локации;
• /forge tps или /spark tick (для Paper/Fabric со Spark-профилировщиком) показывает, что тики сервера сами по себе быстрые, но общее ощущение лагов не совпадает с логами;
• нагрузка "рваная" в разное время суток без видимой связи с активностью игроков.

Если у хостинга есть панель мониторинга CPU steal time (vmstat, поле st) — это прямой индикатор: ненулевой steal time означает, что гипервизор реально забирает у тебя такты в пользу соседей.

Сколько RAM и CPU реально нужно крупному модпаку

Ориентировочные цифры (не бенчмарк, а практическая методика прикидки — точные значения зависят от конкретной сборки и версии модов):

Общую методику расчёта RAM под сервер (не только под модпаки) разбирали отдельно — см. сколько RAM нужно под игровой сервер, если считаешь ресурсы с нуля.

Важный нюанс: выделяй JVM-хипу не всю доступную RAM машины, а оставляй 1.5-2 ГБ системе и файловому кэшу ОС. Пример запуска для сборки на 12 ГБ на машине с 16 ГБ:

java -Xms10G -Xmx10G -XX:+UseG1GC -XX:+ParallelRefProcEnabled \
  -XX:MaxGCPauseMillis=200 -XX:+UnlockExperimentalVMOptions \
  -XX:+DisableExplicitGC -XX:G1NewSizePercent=30 \
  -XX:G1MaxNewSizePercent=40 -XX:G1HeapRegionSize=8M \
  -XX:G1ReservePercent=20 -XX:G1HeapWastePercent=5 \
  -XX:G1MixedGCCountTarget=4 -XX:InitiatingHeapOccupancyPercent=15 \
  -XX:G1MixedGCLiveThresholdPercent=90 -XX:G1RSetUpdatingPauseTimePercent=5 \
  -XX:SurvivorRatio=32 -XX:+PerfDisableSharedMem -XX:MaxTenuringThreshold=1 \
  -jar server.jar nogui

Это набор флагов Aikar's Flags (широко известная пресета для G1GC под Minecraft) — не бенчмаркал именно на этой сборке, но принцип верный для крупных хипов: даёт GC меньше пауз ценой чуть большего расхода памяти на резервы.

Когда VPS ещё справляется

Не всякий модпак требует dedicated. VPS остаётся разумным выбором, если:

• Сборка средняя по весу и играете вдвоём-впятером. RAD2, FTB Skies, небольшие квестовые паки на 60-100 модов обычно живут на VPS с 6-8 ГБ RAM и 4 vCPU вполне комфортно.
• Хостинг даёт честные выделенные vCPU, а не oversell-модель — тогда проблема "шумных соседей" не возникает в принципе, и разница между VPS и dedicated по факту сводится только к абсолютному объёму ресурсов.
• Бюджет ограничен, а лаги 1-2 раза в день на 2-3 секунды некритичны для вашей компании — многие приватные сервера с этим живут годами.
• Планируется тест сборки перед тем как звать друзей на постоянной основе — разворачивать сразу dedicated под неопределённость нет смысла.

Когда точно нужен dedicated

• 10+ игроков одновременно на тяжёлой техно-сборке (GregTech, Mekanism, Applied Energistics в связке) — пиковая нагрузка от нескольких игроков, одновременно взаимодействующих с автоматизацией, требует стабильного CPU-времени без деления с соседями.
• Публичный сервер с непредсказуемым онлайном. На приватных серверах нагрузка предсказуема — на публичных пик может случиться в любой момент, и просадка на VPS ударит по репутации сервера сразу для всех.
• Модпак с рейд-боссами, крупными структурами или множеством измерений, которые генерируют чанки массово при исследовании — генерация чанков очень CPU-интенсивна, и её лучше не делить с соседями.
• Уже пробовали VPS и упёрлись в потолок — если после апгрейда RAM на VPS тикрейт не вырос, а st в vmstat показывает ненулевое значение — это диагностический сигнал переезжать на dedicated, а не докупать ещё памяти.
• Сервер — часть заработка или сообщества с донатами — стабильность тут не роскошь, а часть продукта, за который платят игроки.

На dedicated сервере ты получаешь физические ядра CPU без деления с чужими виртуалками, и тикрейт держится ровно даже в пиковые моменты — это единственная реальная гарантия против "шумных соседей", которую не даёт ни одна VPS-конфигурация, кроме честного dedicated vCPU (что по сути тот же принцип, но внутри виртуализации).

Практический план миграции с VPS на dedicated без потери мира

1. Сделай полный бэкап папки мира и конфигов модов до любых манипуляций — стандартный совет, но при переносе с крупным модпаком, где легко забыть отдельную папку config/ мода, это спасает от переустановки всего с нуля. Подробный разбор процесса — в статье про миграцию сервера к другому хостеру без потери мира.
2. Разверни ту же версию модпака (важно — точную сборку и версию Forge/NeoForge/Fabric, а не "последнюю доступную") на новой машине заранее, не удаляя старую.
3. Скопируй world/, config/, mods/, defaultconfigs/ и serverconfig/ (для сборок с датапаками) на новый сервер.
4. Прогони сервер 10-15 минут в одиночку на новой машине, проверь логи на ошибки загрузки модов — крупные сборки чувствительны к порядку загрузки и версиям зависимостей.
5. Переключи DNS/IP или дай игрокам новый адрес только после того, как убедился, что мир загружается без ошибок и TPS стабилен.
6. Старую VPS не выключай 1-2 дня — на случай, если что-то всплывёт уже под реальной нагрузкой.

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