Оптимизация TPS сервера Minecraft на Paper и Purpur

Стабильный TPS получают измерениями и точечными изменениями, а не копированием чужого набора настроек. У двух серверов с одинаковым онлайном нагрузка может отличаться из-за генерации чанков, ферм, жителей, плагинов или конкретной версии ядра. Paper уже содержит безопасные оптимизации Vanilla, а Purpur наследует их и добавляет настройки геймплея.

TPS и MSPT: что именно тормозит#

Minecraft стремится выполнять 20 тиков в секунду. На один тик при таком темпе доступно 50 миллисекунд. Если основному циклу регулярно требуется больше времени, сервер не успевает поддерживать 20 TPS.

Короткая просадка во время запуска или сохранения еще не доказывает постоянную проблему. Измеряйте сервер в момент реальной нагрузки: когда игроки исследуют мир, работают фермы и выполняются обычные игровые задачи.

Сначала снимите профиль spark#

В Paper 1.21 и новее spark встроен и рекомендован разработчиками Paper вместо Timings. Запустите профилирование во время лагов:

spark profiler start --timeout 600

Через 10 минут команда вернет ссылку на отчет. В игре перед командой нужен /, в консоли панели команды обычно вводятся без него. Не публикуйте отчет вслепую, если в окружении могут присутствовать чувствительные данные.

В отчете ищите не просто самый длинный список, а операции, занимающие значительную долю времени основного потока:

• генерацию и загрузку чанков;
• тики конкретных типов сущностей;
• обработку воронок и контейнеров;
• задачи планировщика определенного плагина;
• частую запись файлов или запросы к базе данных;
• сборку мусора и признаки нехватки памяти.

Старые инструкции часто предлагают /timings on. Timings в Paper 1.21 отключен по умолчанию и считается устаревшим. Для актуальных Paper и Purpur используйте spark. На более старом ядре можно установить совместимый плагин spark вручную по инструкции «Как установить плагины».

Разделите view-distance и simulation-distance#

Оба параметра находятся в server.properties, но отвечают за разную работу:

• view-distance задает радиус чанков, данные которых сервер отправляет игроку;
• simulation-distance задает радиус активно обновляемых чанков, где работают сущности, механизмы и другие игровые процессы.

Пример консервативного тестового изменения:

view-distance=8
simulation-distance=6

Это не универсальный рецепт. Уменьшайте значения по одному шагу, перезапускайте сервер и сравнивайте spark-отчеты в сопоставимых условиях. Снижение simulation-distance часто дает больший выигрыш на выживании с мобами и фермами, но способно изменить работу механизмов вдали от игроков. Слишком маленькая view-distance ухудшает обзор и заметно подгружает горизонт при движении.

Paper допускает переопределение этих значений для миров через spigot.yml. Если изменение в server.properties как будто игнорируется, проверьте параметры view-distance и simulation-distance в секции мира. Общая работа с файлом описана в инструкции по server.properties.

Предгенерация мира через Chunky#

Создание новых чанков нагружает CPU и диск, особенно когда несколько игроков одновременно летят в разные стороны. Плагин Chunky заранее генерирует ограниченную игровую область, чтобы основная работа прошла до открытия сервера или в часы низкого онлайна.

После установки Chunky выберите мир и разумный для вашего проекта радиус в блоках:

chunky world world
chunky radius <радиус>
chunky start

Для Нижнего мира и Края задачу запускают отдельно:

chunky world world_nether
chunky start

chunky world world_the_end
chunky start

Имена зависят от level-name. О структуре измерений рассказано в статье «Как перенести мир и установить карту».

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

Сущности и фермы#

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

Рабочий порядок:

1. Найдите нагруженные чанки и тип сущности по профилю.
2. Проверьте фермы, торговые залы и механизмы в этих местах.
3. Уберите бесконтрольное накопление мобов, предметов и вагонеток.
4. Только затем меняйте диапазоны активации сущностей в spigot.yml.

Параметр entity-activation-range уменьшает область, в которой сущности выполняют полный AI. Его снижение экономит процессорное время, но слишком агрессивные значения ломают поведение мобов, рейды и фермы. Меняйте отдельно категории animals, monsters, villagers и другие, затем проверяйте игровой сценарий, ради которого сущности существуют.

Не ограничивайте сохранение сущностей на чанк без понимания последствий. Настройка Paper entity-per-chunk-save-limit находится в config/paper-world-defaults.yml; переопределение для отдельного мира хранится в <папка-мира>/paper-world.yml. Лимит может привести к исчезновению данных сверх заданного количества после выгрузки и повторной загрузки чанка. Это аварийный предохранитель, а не обычный способ оптимизации.

Воронки и сортировщики#

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

Параметры hopper.cooldown-when-full и hopper.disable-move-event находятся в секции hopper файла config/paper-world-defaults.yml; настройки конкретного мира могут быть переопределены в <папка-мира>/paper-world.yml. Первый уменьшает бесполезные проверки заполненной воронки. Второй может дать заметный выигрыш, но отключает InventoryMoveItemEvent. Из-за этого плагины защиты, логирования или управления контейнерами могут перестать видеть перемещение предметов.

В spigot.yml также есть интервалы hopper-transfer и hopper-check. Их изменение меняет скорость или частоту работы механизмов и способно сломать сортировщики и часы. Не вставляйте значения из готового конфига без профиля и теста на копии мира.

Плагины: меньше не всегда быстрее#

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

• совместимость плагина с текущей версией Paper или Purpur;
• ошибки и повторяющиеся предупреждения в консоли;
• синхронные обращения к внешней базе или сети;
• слишком частые обновления голограмм, таб-листа и карт;
• сканирование больших областей мира;
• дублирующие плагины с одинаковой функцией.

Удаляйте или обновляйте подозрительный плагин только после бэкапа. Снимите профиль до изменения и после него. Такой тест надежнее предположений по названию плагина.

Почему дополнительная RAM может не помочь#

Большая куча Java полезна, когда сервер действительно получает ошибки нехватки памяти, часто собирает мусор или запускает тяжелую сборку. Но основной цикл тиков в значительной степени зависит от производительности одного потока CPU. Если spark показывает, что тик занят AI, плагином или генерацией мира, добавление RAM не ускорит эту работу.

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

Переход на более мощный тариф BazaHost оправдан, если после удаления явных проблем сервер стабильно упирается в доступный CPU, памяти действительно недостаточно или предгенерированному миру не хватает диска. Перед сменой тарифа сохраните spark-отчет: он поможет отличить нехватку ресурсов от ошибочной настройки.

Контрольный порядок оптимизации#

1. Обновите Paper или Purpur и совместимые плагины, предварительно сделав бэкап.
2. Воспроизведите лаг и снимите профиль spark.
3. Если виноваты новые чанки, ограничьте мир и выполните предгенерацию Chunky.
4. Согласуйте view-distance и simulation-distance с типом сервера.
5. Исправьте конкретные фермы, сущности, воронки или плагины из отчета.
6. Меняйте один параметр за раз и сравнивайте результаты.
7. Рассматривайте смену тарифа только после определения реального дефицита ресурса.

Регулярный мягкий рестарт полезен для обслуживания, но не лечит постоянную нагрузку. Настроить сохранение, рестарт и бэкап можно через планировщик задач Minecraft.