Производительность: modded против vanilla сервера

MAATRIX GAMES

Заказал тариф "как в каталоге написано" под ванильный Minecraft на 20 игроков, накатил десяток модов — и через неделю сервер уже подвисает на спавне, TPS проседает до 12-15, а игроки жалуются на рывки при открытии сундука. Знакомая история: требования к железу растут не линейно от числа модов, а часто скачками, и тариф, который с запасом тянул vanilla, начинает задыхаться уже на средней modded-сборке. Разберём, откуда берётся эта разница и как посчитать реальный запас по RAM и CPU заранее, а не методом "упало — апгрейдим".

Почему один и тот же онлайн грузит modded-сервер сильнее

Ванильный сервер (без модов и плагинов) тикает по предсказуемому циклу: обработка чанков, движение мобов, физика жидкостей, сетевые пакеты игроков. Ядро игры годами оптимизировано именно под эту нагрузку, и производитель дал вам ram в каталоге не просто так — это реальный минимум под чистую игру.

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

• Хуки суммируются линейно, а иногда и хуже. Если пять модов слушают событие "игрок сломал блок", движок вызывает пять обработчиков вместо одного, и каждый может делать собственные проверки или запросы к базе.
• Кастомные сущности часто дороже ванильных. Мод на структурные постройки (вроде S+ для ARK) или NPC-фракции держит на сервере сущности с более сложной логикой поведения, чем стандартный моб, и тикает их так же часто.
• Часть модов держит собственный поток данных. Плагины экономики или кланов на Rust/FiveM пишут в SQLite/MySQL при каждом действии игрока — это не CPU-тик, а I/O, который тоже съедает ресурс, просто другой.
• Память растёт не только под сами моды, но и под их данные. Чанки с кастомными блоками, сохранённые структуры, регионы претензий (Land Claim, GriefPrevention) — это дополнительный heap, который JVM или движок держит в оперативке постоянно, а не только в момент обращения.

В итоге разница между "10 модов" и "10 модов, но три из них тяжёлые" может быть больше, чем между "10 модов" и "30 лёгких модов". Считать нагрузку по количеству файлов в папке mods/ — плохая идея.

Minecraft: Forge/Fabric против Paper на цифрах

Возьмём Minecraft — самый показательный пример, потому что там одновременно живут три экосистемы с разной ценой производительности: ванильный сервер, Paper (оптимизированное ядро с плагинами) и Forge/Fabric (полноценные моды). Базовый тариф в каталоге games.maatrix.io под Minecraft — от 2 ГБ RAM, но это цифра под ванильный сервер на небольшой онлайн.

Цифры ориентировочные — точный расход зависит от конкретных модов, включённого предзагруза чанков (chunk pre-generation) и настроек view-distance, но порядок именно такой: чем тяжелее модпак, тем круче растёт кривая на каждого следующего игрока, а не только базовая планка. У Paper прирост от плагинов обычно мягче, чем у Forge от модов — плагины работают через оптимизированное API ядра, а моды часто патчат игровую логику напрямую и тащат за собой десятки зависимостей.

Отдельно про Fabric: сам по себе он легче Forge на голом старте (меньше служебного оверхеда загрузчика), но итоговый расход почти целиком определяется набором модов, а не загрузчиком — сравнивать "Fabric против Forge" по производительности без привязки к конкретной сборке смысла нет. Если выбираете загрузчик с нуля, почитайте Forge, Fabric или Paper — что выбрать для сервера.

Не только Minecraft: Rust, ARK, 7 Days to Die, FiveM

Та же логика работает на любой игре, где есть система плагинов или модов поверх движка.

Rust + Oxide/uMod. Голый ванильный Rust на средней карте (3000-4000 размер) официально просит от 8 ГБ. С 15-20 плагинами Oxide (экономика, кланы, RustRewards, кастомные магазины) добавляйте ещё 2-4 ГБ и заметно больше CPU-нагрузки на тик — плагины Oxide перехватывают хуки на каждое действие игрока (крафт, урон, сбор ресурса), и на онлайне 100+ это ощутимо. Подробности по установке разобраны в статье про Oxide и uMod: установка и первые плагины.

ARK: Survival Evolved/Ascended. Структурные моды вроде S+ и крупные карты-моды (Ragnarok, Valguero из Workshop) — это не просто "ещё файлы", а десятки тысяч дополнительных объектов на карте, каждый из которых тикает физику и коллизии. Кластер из нескольких карт с модами легко удваивает требования к RAM относительно одиночной ванильной карты.

7 Days to Die. Оверхолы вроде Darkness Falls перерабатывают почти всю логику зомби-орд, крафта и лута — на волнах орды (blood moon) нагрузка на CPU у modded-сборки растёт кратно сильнее, чем у ванильной, потому что каждый зомби в оверхоле считает больше параметров (агро, дистанции, кастомные AI-паттерны).

FiveM (GTA V). Здесь нагрузка почти целиком в скриптах ресурсов (ESX, QBCore) и Lua/JS-обработчиках событий. Framework сам по себе уже тяжелее голого FiveM, а каждый дополнительный скрипт (гараж, работы, инвентарь) добавляет свои таймеры и события — сервер на 64 слота с полным набором job-скриптов реально просит 4-6 ГБ вместо базовых официальных 4 ГБ под чистый FiveM.

Как посчитать нужный запас, а не гадать

Формула, которой реально можно пользоваться при выборе тарифа:

Нужный RAM ≈ база_игры + (RAM_на_игрока × онлайн) + запас_под_моды

база_игры       — минимум из каталога (например, 2 ГБ для Minecraft)
RAM_на_игрока   — обычно 150-300 МБ для ванильных серверов,
                  300-600 МБ для modded (зависит от тяжести сборки)
запас_под_моды  — 20-40% от базы на каждые ~10-15 установленных
                  модов/плагинов среднего веса, больше — для
                  тяжёлых (экономика с БД, структурные моды, античит)

Пример для Paper-сервера на 20 игроков с 15 плагинами (права, экономика, античит, кастомные ивенты):

2 ГБ (база) + 20 × 0.2 ГБ (по игроку) + 30% запас под плагины
= 2 + 4 = 6 ГБ базовой потребности
6 × 1.3 ≈ 7.8 ГБ → берём тариф на 8 ГБ

Считать нужно не в момент запуска с пустым сервером, а под пиковый онлайн — вечер пятницы, ивент, открытие сезона. Реальный расход RAM смотрите штатными средствами: на Minecraft — команда /tps (Paper) и htop/top на стороне процесса, на Rust — F1-консоль → serverinfo, на большинстве Linux-нод — просто free -h и htop в SSH. Если админка тарифа показывает график потребления — ориентируйтесь на пиковые точки за неделю, а не на среднее.

Как читать TPS и где искать источник просадки — отдельно разобрано в статье мониторинг TPS и лагов на игровом сервере.

Почему TPS/тикрейт у modded просаживается раньше при том же онлайне

Тикрейт (TPS в Minecraft, tickrate в Rust/CS2) — это то, сколько раз в секунду сервер успевает обработать полный игровой цикл. У ванильного Minecraft целевой TPS — 20, у Rust тикрейт обычно 10-30 в зависимости от настройки хоста.

Ключевая разница modded-сборки: тикрейт падает не постепенно, а лестницей. Пока CPU и RAM хватает с запасом — просадок нет вообще, TPS держится на максимуме. Но стоит упереться в лимит (не хватает свободных тактов CPU на обработку всех хуков за 50 мс тика в Minecraft, например) — тикрейт обваливается резко, и игроки чувствуют это как рывки и телепортацию мобов, а не плавное замедление. Ванильный сервер на слабом железе просто "плывёт" мягче, потому что логика проще и предсказуемее по времени выполнения.

Практический вывод: modded-серверу нужен не просто больше RAM, а запас CPU выше пикового расчёта — минимум 20-30% сверху, чтобы редкие тяжёлые тики (массовый ивент, орда зомби, взрыв базы с сотнями объектов на Rust) не роняли тикрейт в ноль на самый неудачный момент, когда на сервере максимум онлайна.

Как снизить требования, не срезая контент сборки

Прежде чем брать тариф на ступень выше, стоит проверить, не съедает ли ресурс что-то, что можно оптимизировать без урезания модпака:

• Оптимизационные моды-компаньоны. На Forge/Fabric есть моды, которые не добавляют контент, а чинят производительность самого движка: Lithium и FerriteCore (Fabric), Clumps и ModernFix (совместимы с Forge/NeoForge). Они не заменяют тяжёлые контентные моды, но снижают базовый оверхед тика и памяти на 15-30% почти бесплатно.
• Предзагрузка чанков (chunk pre-generation). Плагин Chunky на Paper генерирует карту заранее, вне пиковых часов — тогда на онлайне сервер не тратит CPU на генерацию новых чанков параллельно с игрой.
• View-distance и simulation-distance ниже дефолта. На модпаках с тяжёлыми структурами снижение view-distance с 10 до 6-8 в server.properties (Minecraft) часто даёт больше прироста TPS, чем апгрейд тарифа. Подробнее — в статье про view-distance и другие настройки анти-лага.
• Аудит установленных плагинов/модов раз в сезон. На Rust и FiveM легко накапливается "мёртвый груз" — плагины, которые никто не использует, но они продолжают тикать. Отключение неиспользуемых модулей — самый дешёвый способ вернуть производительность.
• Разнести тяжёлые задачи по времени. Автосохранение мира, бэкапы, ресеты претензий на claim-плагинах — планируйте на минимальный онлайн (ночь по вашему часовому поясу), а не на пиковые часы.

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

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