Оптимизация модов и TPS на Minecraft-сервере

MAATRIX GAMES

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

Что такое TPS и почему это не то же самое, что FPS

TPS — тики в секунду, частота, с которой сервер обсчитывает игровой мир: физику, редстоун, рост растений, поведение мобов, столкновения. Идеал — 20 TPS, это жёстко зашито в движке игры (один тик = 50 мс). Это серверная метрика, она не имеет отношения к FPS у тебя на экране — можно иметь 200 FPS в клиенте и при этом сидеть на сервере, где TPS просел до 8, потому что процессор сервера не успевает обсчитать один тик за отведённые 50 мс и берёт следующий такт с опозданием.

Просадка TPS ощущается как:

• мобы «прыгают» рывками, а не двигаются плавно;
• механизмы на редстоуне и таймеры сбиваются;
• открытие инвентаря, чанк-погрузка, посадка растений — с заметной задержкой;
• в проекте с фермами мобов или большими автоматизированными базами (частая история для модовых сборок вроде Create, Applied Energistics, промышленных паков) TPS падает в первую очередь, потому что именно такие постройки генерируют тысячи вычислений за тик.

Смотреть TPS напрямую можно командой /tps (в Paper и большинстве форков она встроена, в ванильном Forge/Fabric понадобится плагин или мод типа Spark). Команда покажет три числа — среднее за 5с, 1м и 5м. Если пятиминутное значение ниже 18-19 — это уже не разовый скачок, а системная проблема, которую стоит искать.

Диагностика: spark вместо гаданий

Первое, что нужно сделать при жалобах на лаги — не менять конфиги наугад, а поставить spark. Это профайлер производительности, который работает и на Paper/Spigot-плагинах, и как мод для Forge/Fabric, и умеет профилировать именно то, что происходит на сервере в реальном времени, а не догадки по логам.

Базовый сценарий:

/spark profiler start
# подожди 60-120 секунд в момент, когда лагает
/spark profiler stop

Spark выдаёт ссылку на веб-отчёт с деревом вызовов — видно, сколько процентного времени тика съедает конкретный мод, конкретная сущность или конкретный чанк. Это принципиально меняет подход: вместо «выключу-ка я на всякий случай половину модов» ты видишь точную цифру — условно, 40% времени тика уходит на обсчёт фермы мобов в одном чанке, а не на весь список модов сразу.

Дополнительно полезны:

• /spark tps — быстрый снимок TPS без полного профилирования;
• /spark heap — если подозреваешь утечку памяти (частая причина деградации производительности со временем, а не сразу после старта);
• /spark gc — статистика сборщика мусора, полезно, если сервер «замирает» на 1-2 секунды с равными интервалами (обычно это как раз паузы GC при нехватке heap).

Если под рукой нет консоли или неудобно ставить мод, минимальная диагностика — посмотреть лог сервера на строки вида Can't keep up! Is the server overloaded?. Это прямой сигнал, что сервер не успевает уложить тик в 50 мс, и дальше нужен именно профайлер, а не перезапуск.

Оптимизационные моды: снижаем нагрузку без потери геймплея

Отдельная категория модов и плагинов существует именно для того, чтобы пересчитать одни и те же игровые механики эффективнее — без изменения правил игры для игрока. Речь о технической оптимизации движка: ускоренная генерация освещения, более быстрый поиск пути у мобов, оптимизированные коллизии и структуры данных. Такие моды не добавляют предметы и не меняют баланс, поэтому их обычно безопасно ставить и на выживание, и на PvP-проекты.

Для Fabric-сборок такие моды ищутся на Modrinth/CurseForge по тегам "performance" и "optimization" — экосистема развивается быстро, поэтому вместо конкретных названий и версий (которые к моменту чтения статьи вполне могут устареть или конфликтовать с актуальной версией игры) — общий принцип отбора:

• ставь только моды с явной пометкой совместимости с твоей версией Minecraft и загрузчика (Forge/Fabric/NeoForge — они не взаимозаменяемы);
• проверяй дату последнего обновления мода — заброшенный мод оптимизации на старой версии API часто сам становится источником лагов или крашей;
• добавляй по одному, тестируй TPS через /spark tps до и после — так сразу видно, дал ли конкретный мод прирост или просто добавил риск конфликта;
• для сборок на Paper и его форках (Purpur и подобные) многие оптимизации уже встроены в сам сервер-джар и настраиваются через paper-world-defaults.yml, отдельный мод может не понадобиться вовсе.

Если собираешь солянку модов через модпак — свежий обзор актуальных сборок и что в них входит есть в статье про лучшие модпаки для Minecraft-сервера, а если ещё не определился между ядрами — сравнение подходов в материале Forge, Fabric или Paper — что выбрать.

view-distance и simulation-distance: самый быстрый рычаг

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

Два параметра, которые часто путают:

• view-distance — сколько чанков видит клиент вокруг себя (визуальная прогрузка, влияет на то, что рендерится);
• simulation-distance — сколько чанков сервер реально *тикает*: считает физику, спавнит мобов, обсчитывает механизмы. Именно этот параметр напрямую бьёт по TPS.

view-distance=8
simulation-distance=6

Дефолт в ванильном сервере — 10, и на слабой конфигурации или при большом онлайне это часто избыточно. Снижение simulation-distance с 10 до 6 может дать заметный прирост TPS почти без потери ощущений от игры — большинство игроков физически не замечают разницу между 8 и 10 чанками симуляции, зато сервер обсчитывает на треть меньше активных чанков.

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

Лимиты сущностей: мобы, дропнутые предметы, фермы

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

В spigot.yml (для Paper/Spigot и форков) есть прямые лимиты:

world-settings:
  default:
    entity-activation-range:
      animals: 32
      monsters: 32
      misc: 16
    entity-tracking-range:
      players: 48
      animals: 48
      monsters: 48
    ticks-per:
      animal-spawns: 400
      monster-spawns: 1

entity-activation-range — на каком расстоянии от игрока сущность вообще «просыпается» и начинает полноценно обсчитываться (спящий моб вне этого радиуса требует значительно меньше ресурсов). Уменьшение этих значений — второй по эффективности рычаг после simulation-distance.

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

Отдельно стоит следить за дропнутыми предметами: если на сервере активно фармят и не убирают лут, счётчик entity легко доходит до нескольких тысяч штук на карте. Решение — плагин или мод для периодической очистки дропа (/kill @e[type=item] руками или автоматизированная очистка через таймер), плюс здравый смысл при настройке автоферм — не крутить их бесконечно без сборщика.

Чанки, память и настройки JVM

TPS зависит не только от того, что происходит в мире, но и от того, как сервер вообще получает ресурсы. Два момента, которые часто упускают:

Preload и unload чанков. Держать в памяти лишние прогруженные чанки (например, из-за забытых чанк-лоадеров в модах) — это постоянная фоновая нагрузка. Полезно периодически проверять, сколько чанков реально загружено — команда /forge chunks для Forge покажет список чанк-лоадеров по модам и владельцам, что часто вскрывает забытую ферму или AFK-машину на другом конце карты.

Флаги запуска JVM. Голый java -jar server.jar с флагом -Xmx без остальных настроек сборщика мусора — не лучший вариант для сервера с модами, где память фрагментируется активнее. Сообщество Minecraft-хостинга давно сошлось на связке флагов Aikar's Flags как разумном дефолте для G1GC:

java -Xms4G -Xmx4G -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

Важно: -Xms и -Xmx должны совпадать (фиксированный heap избавляет JVM от постоянного расширения/сжатия памяти) и не превышать физически доступную серверу RAM с запасом под ОС — если на тарифе 6 ГБ, не стоит отдавать все 6 под -Xmx, оставь хотя бы 1 ГБ системе.

Когда оптимизация уже не поможет

Здесь стоит быть честным: оптимизация — это не бесконечный ресурс. Она устраняет лишние накладные расходы и убирает узкие места, но не может взять и создать процессорное время из ниоткуда. Если на сервере 40+ игроков одновременно, тяжёлый модпак с десятками автоматизированных ферм и активным редстоуном, а TPS всё равно проседает после того как:

• профайлер spark не показывает явного «виновника», а нагрузка размазана по всей активности сервера;
• simulation-distance и view-distance уже снижены до разумного минимума;
• лимиты сущностей выставлены жёстко;
• JVM-флаги настроены корректно;

— это значит, что сервер уперся в потолок доступного CPU и single-core производительности тарифа. Minecraft-сервер (особенно с модами) почти полностью упирается в один поток — обсчёт мира не распараллеливается между ядрами так, как это происходит, скажем, в базах данных. Поэтому «добавить ещё 4 ГБ ОЗУ» тут часто не поможет вообще, если процессор уже утилизирован под завязку — здесь нужен тариф с более быстрым процессором (выше частота ядра), а не просто больше памяти. Честная диагностика через /spark tps и /spark profiler как раз и нужна для того, чтобы понять — это ещё зона твоего конфига, или уже зона апгрейда железа.

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