Снимайте профиль во время проблемы
Профиль показывает работу сервера за выбранный промежуток. Если задержка возникает при исследовании мира, запись пустого спавна её не объяснит. Сначала опишите воспроизводимое действие и подготовьте участников: вход в нужную область, запуск режима или обычную нагрузку конкретной базы.
Начиная с Paper 1.21, spark включён в ядро. На других выпусках и платформах проверьте способ установки и совместимость отдельно. Команды требуют предусмотренных прав; обычному игроку они могут быть недоступны. В консоли сервера команды вводятся без начального слеша.
Перед записью запишите версию Paper, Java, основные плагины, число игроков и название сценария. Эти сведения помогают сравнивать отчёты. Проценты из двух профилей с разной нагрузкой нельзя считать прямым доказательством улучшения после одного изменения.
Первый полезный отчёт
В игре с административными правами выполните /spark profiler start --timeout 60; в серверной консоли — spark profiler start --timeout 60. Пока идёт запись, повторяйте проблему. Через минуту spark остановится и выдаст URL отчёта. Если запись нужно завершить раньше, используйте /spark profiler stop. Все варианты — в справочнике команд.
Для редких зависаний начните /spark profiler start --only-ticks-over 100 --timeout 300: профиль соберёт только тики дольше100мс за пять минут. Такой отчёт не сравнивают напрямую с обычным профилем всех тиков. Если нужно отказаться от записи без публикации, выполните /spark profiler cancel.
- Перед записью выполните
/spark tpsи запишите число игроков и конкретное действие, например первый вход в новую область. - Запустите минутный профиль и повторите действие несколько раз.
- Не запускайте второй профиль до завершения первого; статус смотрите через
/spark profiler info. - Дождитесь ссылки, откройте её и сопоставьте период с моментом задержки.
- Если событие не попало в запись, повторите с300секундами вместо60; не делайте вывод о его причине по пустому спавну.
/spark profiler start --timeout 60Как читать дерево вызовов
Откройте отчёт, выберите Server thread и нажимайте на крупные узлы дерева, чтобы раскрыть дочерние. Начните с ветки обработки тика, не с Thread.sleep/park: ожидание при свободном бюджете нормально. Наведите курсор на узел — интерфейс показывает оценённые миллисекунды. Руководство viewer иллюстрирует эти действия.
Пример: узел родителя занимает60%, его дочерний40%. Это вложенная работа, их нельзя сложить в100% отдельной нагрузки. Раскройте дочерний до конкретного метода плагина или операции мира, затем свяжите его с игровым действием. Большой процент на коротком лёгком профиле также не равен тяжёлой работе в абсолютных миллисекундах.
Частые группы причин
Генерация и загрузка местности
Сравните движение по готовым чанкам и новой территории. Если различие заметно, исследуйте работу мира и диска, а также скорость перемещения игроков. Подготовленная ограниченная карта уменьшает необходимость новой генерации, но не отменяет загрузку, сохранение и активность существующей области.
Сущности и механизмы
Проверьте, совпадает ли проблемный интервал с большим числом существ, предметов или работающих устройств. Не удаляйте всё подряд только по общему названию ветки. Сначала остановите один конкретный источник нагрузки в тестовой среде и повторите сценарий.
Плагин и внешние операции
Посмотрите, не выполняет ли плагин частые обходы большого списка или ожидание внешнего сервиса в неподходящем месте. Для разработчика полезна точная цепочка вызовов и сценарий. Общая просьба «сделать плагин асинхронным» не описывает, какие действия можно безопасно переносить между потоками.
Ограничения фоновой работы разобраны в статье задачи и потоки Paper.
Память и сборка мусора
Для состояния памяти используйте /spark health show --memory в новом spark; в старом выпуске смотрите доступный healthreport через help. Отдельный профиль выделений запускается /spark profiler start --alloc --timeout 60, если этот режим поддерживает среда. Команды памяти автора показывают ограничения. CPU-дерево не заменяет журнал OOM или проверку лимита контейнера.
Если разбираете повторные лаги каждые несколько секунд, сравните время пауз и игровые действия; затем проверяйте частые выделения или планировщик. Если сервер окончательно завершился, сохраните logs/latest.log и журнал процесса: факт завершения мог вообще не попасть в загруженный отчёт.
Проверить ограничения кучи и контейнера поможет материал бюджет памяти Java.
Сравнение до и после
Измените один параметр: настройку мира, интервал конкретной задачи или проблемный код. Затем повторите запись с похожим числом игроков и тем же действием. Сравните не только проценты, но и реальные симптомы, длительности тиков и общую стоимость сценария.
Если после изменения сервер выполняет другую работу, отчёты уже не описывают одинаковую задачу. Например, уменьшение числа участников мини-игры может снизить нагрузку без улучшения её реализации. Поэтому результат должен содержать условия проверки, а не только красивый скриншот уменьшившейся ветки.
Что отправить разработчику
Отправьте разработчику ссылку и короткий шаблон: «Paper1.21.1, Java21, 12игроков; 60сек записи; при телепорте в новый чанк блоки задерживаются; узел X занимает Yмс; после view-distance8 задержка изменилась так-то». Подставьте реальный узел и измерения, не копируйте учебные значения как результат.
Проверьте содержимое профиля перед публичной публикацией: там могут быть названия плагинов, конфигурационные сведения и команды. Отправляйте отчёт тем, кто разбирает проблему, вместе с шагами воспроизведения. После исправления снимите такой же профиль и приложите оба — это позволяет оценить изменение.
