Если на вашем сервер Minecraft проседает TPS, игрокам начинает «лагать»: дергается камера, отваливаются действия и мир работает рывками. В этой статье вы найдете понятный алгоритм, как найти причину нагрузка и сделать так, чтобы тики снова держались ровно.


Сначала измерьте, а не «лечите наугад»

Главная ошибка — менять плагины и настройки без диагностики. Сначала выясните, что именно забирает время тика.

Для оценки запаса используйте такие ориентиры:
- TPS держится около 19.9–20 — сервер в норме.
- MSPT (время обработки тика) обычно должно быть ниже 20.
- Если MSPT сильно выше, то сервер реально не успевает обработать игру, и нужна оптимизация.

Дальше действуйте так:
- Команда /tps — чтобы увидеть текущее состояние.
- /timings on, затем выждите минута-две (или несколько), после чего /timings report — чтобы понять, какие задачи нагружают сервер.
- Spark: запустите профилирование, подождите несколько минута, остановите и посмотрите отчет — он показывает конкретные процессы/плагины.

Итог прост: если у вас есть цифры по tps и отчет по тикам, вы сможете точнее выбрать, что менять.


Что чаще всего убивает TPS: мир, сущности и тяжелые плагины

Когда сервер теряет производительность, причина обычно одна из трех:

Мир грузится «слишком активно»

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

Слишком много активных сущностей

Мобы, жители, предметы на земле и т.п. создают лишние расчеты. Тут важны настройки в командах ядра и ограничение активации сущностей.

Ненужные функции в плагинах

Часто лаги появляются не из-за одного «плохого» плагин, а из-за десятка мелких включенных модулей, обработчиков и событий. Даже если это не видно сразу, в /timings report будет видно, какие куски кода «съедают» время.


Ограничьте прогрузку: меньше «подвисаний» из-за чанков

Самый понятный путь — не дать серверу постоянно думать о том, что далеко от игроков.

WorldBorder: границы мира

Идея такая: ограничьте размер активной карты в каждом мире, а не только на спавне. Тогда сервер не будет «разгоняться» на большие области, которые никто не смотрит.

Например, вы заходите в нужный мир и ставите границу через команду /worldborder set .... Значения подбирайте по логике: чем больше онлайн и активности, тем меньше жесткость. Но цель одна — сократить лишние расчеты.

Chunky: заранее прогрузите чанки

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

Общий подход:
- выбрать мир: /chunky world ...
- указать центр: /chunky center x z
- задать радиус: /chunky radius ...
- запустить: /chunky start

Важно: не перезагружайте сервер до окончания процесса. Иначе прогрузка не завершится и часть ресурсов все равно будет потрачена «вживую» во время игры.


Настройте конфиги ядра: где выжимают TPS

Теперь — конкретные места, которые часто дают прибавку без потери геймплея. Смотрите настройки в трех файлах: Bukkit.yml, Spigot.yml, Paper.yml.

Ниже — логика, что именно обычно меняют под оптимизация.

Bukkit.yml: лимиты на спавн мобов и выгрузку чанков

Включайте разумные установить лимиты на количество мобов при спавне, например:
- spawn-limits — ограничить monsters/animals/water-animals/ambient
Также влияет период сборки чанков:
- chunk-gc.period-in-ticks — ставят так, чтобы неактивные чанки удалялись быстрее, когда это безопасно.

Spigot.yml: дальность активации и сохранения

Обычно регулируют:
- entity-activation-range — уменьшить радиус активации для мобов/животных, чтобы меньше сущностей считалось одновременно
- отключают лишние сохранения структур, если это не критично для вашего режима

Paper.yml: ускорение света и контроль активных тиков

Тут часто включают:
- асинхронное освещение (чтобы не тормозить тик)
- автоматическое удаление некорректных сущностей
- настройки, уменьшающие число лишних расчетов в «тихих» ситуациях


Плагины, которые реально помогают (и почему)

Набор зависит от сборки, но чаще всего упоминают такие инструменты для сервер-производительности:

Что делает Зачем для TPS Куда смотреть в диагностике
Spark профилирует нагрузку и показывает «кто виноват» в результате Spark будет видно проблемный плагин/процесс
ClearLagg разгружает работу с мусором и памятью помогает стабилизировать лаги после активности
FarmControl снижает нагрузку от автоматических ферм убирает пики при генерации ресурсов
ExploitFixer (по необходимости) снижает риск лагов из-за атак/эксплойтов актуально, если есть атаки/читеры

Важно: оптимизация — это не «ставим один плагин и все стало 20 TPS». Это цикл: замер → причина → точечное изменение.


Выберите ядро: PaperSpigot / Purpur / Airplane

Если у вас неудачно выбран тип ядра, плагины и функции могут работать тяжелее.

Чаще всего для стабильности и совместимости используют PaperSpigot. Для специфичных задач могут подойти Purpur или Airplane, но конкретный выбор всегда упирается в вашу версию сервер и список плагинов.


Как настроить CMI, чтобы он не съедал TPS

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

Что сделать:
- отключить ненужные команды через Alias
- отключить модули в Modules
- оставить только то, что реально используется в вашей сборке

Если вы видите, что какой-то функционал CMI не применяется (голограммы, порталы и т.п.), отключите соответствующие модули. Так вы уменьшите количество событий и обработчиков, которые будут постоянно работать в фоне.


Пиратские плагины: почему TPS — не единственная проблема

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

На практике это часто приводит к внезапным лагам и нестабильности.


Правильная цель: стабильный TPS, а не разовый «скачок»

Оптимизация сервера — это не разовая правка. Ставятся новые плагины, обновляются версии, меняется онлайн и стиль игры. Поэтому процесс такой:
- проверить tps командой /tps
- сделать отчет по нагрузке /timings report
- подтвердить профилем через Spark
- точечно установить нужные изменения
- снова измерить результат


Быстрый чек-лист, чтобы поднять TPS

  • Снять показания /tps, посмотреть MSPT
  • Запустить /timings on/timings report
  • Прогнать Spark и найти «виновника» по времени тика
  • Ограничить мир через WorldBorder
  • Предварительно прогрузить чанки через chunky
  • Проставить адекватные лимиты в Bukkit.yml / Spigot.yml / Paper.yml
  • Отключить лишние функции в CMI
  • Не раздувать сборку «на всякий случай»
  • Следить за качеством плагинов и не использовать подозрительные сборки

Если выполнить этот план, вы обычно начинаете получать более стабильный TPS и меньше провалов по нагрузка, даже когда на сервер заходят новые игроки.