Spark для Minecraft: как найти причину лагов сервера за пять минут

Сервер лагает, а причину не видно. Можно поднять тариф, перезапустить сервер и поменять настройки наугад, но пока вы не знаете, что занимает время тика, каждое действие — лотерея. Профилировщик spark отвечает на один вопрос: какой код, плагин или мод тратит больше всего времени на каждый тик. В Paper он встроен начиная с 1.21 и считается основным профилировщиком вместо устаревшего Timings. В консоли при старте видна строка [spark] Starting background profiler....

Коротко

Для Paper 1.21.x выполните в консоли /spark tps, чтобы увидеть MSPT и загрузку CPU. Если MSPT выше 50 мс, запустите профилирование командой /spark profiler start --timeout 300, дайте нагрузке пройти пять минут и откройте отчёт после /spark profiler stop. Так найдётся код, который тратит больше всего времени тика.

Что нужно знать про spark

Spark считает не «сколько процессора использует Java», а где именно в коде сервера уходит время. Профилировщик периодически снимает стеки вызовов всех потоков и складывает их в дерево. Чем шире ветка, тем больше времени в ней провели потоки. Поэтому отчёт показывает, например, что 40% тика уходит на один плагин, а не просто «сервер грузит CPU на 90%».

В отчёте важны три вещи:

• MSPT — сколько миллисекунд тратит сервер на один тик. Норма: не больше 50 мс.
• Дерево вызовов — кто что вызывает. Ищите самый толстый путь от корня.
• Метод или класс — конкретное место: часто это имя плагина или мода в пакете.

Право на команды spark должно быть у вашего аккаунта на сервере. Для профилирования нужно право spark.profiler. Подойдёт и общее право spark. Если команда пишет «нет прав», это не баг сервера, а настройка доступа.

Шаги: профиль за пять минут

Все команды выполняются в разделе «Консоль» на сервере, который лагает.

1. Посмотрите MSPT

Выполните:

/spark tps

В ответе будут TPS, MSPT и загрузка CPU. Если MSPT ниже 50 и лаги вас не беспокоят, профилировать не нужно. Если MSPT стабильно выше 50, переходите к следующему шагу.

Для более подробного взгляда есть живой отчёт:

/spark health

Это живая панель в браузере, она обновляется каждые 10 секунд. Разовый отчёт прямо в консоль — /spark health show, с флагом --memory добавятся данные о памяти JVM.

2. Запустите профилировщик

Самый удобный вариант — с автоматической остановкой:

/spark profiler start --timeout 300

Цифра — длительность в секундах. Пять минут хватает, чтобы захватить несколько пиков нагрузки. Если лаги появляются только при сборе фермы или при большом скоплении игроков, запустите профилировщик именно в этот момент.

Можно ограничить набор потоков. Например, --thread * включает все потоки, а --thread <имя> — только указанный. Для обычного разбора достаточно всех потоков.

3. Дайте нагрузке идти

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

4. Остановите и откройте отчёт

Если таймер не задан, остановите вручную:

/spark profiler stop

Команда выведет ссылку на онлайн-просмотрщик. Откройте её в браузере. Если нужно открыть отчёт, не останавливая профилировщик, используйте /spark profiler open. Чтобы сохранить профиль в файл вместо загрузки, добавьте --save-to-file (файл ляжет в папку настроек spark, обычно plugins/spark):

/spark profiler stop --save-to-file

Ссылка или файл — два варианта. Ссылку можно открыть сразу, а файл удобно сохранить, чтобы сравнить с отчётом через неделю. Скачать файл можно из «Файлов»; путь к нему команда выводит в консоли.

5. Прочитайте дерево

Откройте ссылку и отсортируйте дерево по времени.

Ищите:

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

Если самая широкая ветка — ваш плагин, зайдите в его настройки или отключите его на тестовой копии сервера и повторите профиль.

Пример: что видно в отчёте

Пример условный, цифры для иллюстрации. Допустим, MSPT колеблется около 60 мс, а при фермах становится 90 мс. Профиль показывает, что 35% времени тика уходит на плагин подсчёта предметов, который ищет сущности по всему миру при каждом тике. Решение — не менять JVM, а отключить плагин или ограничить его частоту. После отключения MSPT возвращается к 35–40 мс.

Другой пример: в отчёте доминирует сборка мусора и Chunk-операции. Это уже признак нехватки памяти или тяжёлого мира. Тогда помогают настройки дальности из статьи view-distance и simulation-distance и предгенерация из статьи Chunky.

Симптом → причина → решение

Разбор отчёта по шагам

Когда отчёт открыт, удобно пройти его по одной схеме. Так вы не утонете в тысячах методов.

1. Проверьте, что профиль снят в нагрузке. В шапке отчёта есть длительность и число выборок. Если выборок мало, а онлайн был высокий, профиль короткий: повторите.
2. Найдите верхний уровень. В корне дерева обычно видно тик сервера и отдельные потоки. Работайте с тем, что занимает основную долю тика.
3. Спуститесь по самой толстой ветке. Каждый шаг вниз — конкретнее: от «тик» к «сущности» и далее к классу плагина.
4. Отметьте имя пакета. Пакеты вида com.example.plugin или пути с названием мода сразу указывают на источник.
5. Сверьте с установленным. Откройте «Моды и плагины» и проверьте, есть ли такой плагин и какой версии. Иногда старая версия тикает впустую после обновления ядра.
6. Проверьте гипотезу. Отключите подозреваемый плагин на тестовой копии или ограничьте его настройками и снимите новый профиль.

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

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

Таблица для быстрой сверки:

Как не ошибиться в выводах

Первая ошибка — профилировать во время рестарта или сразу после старта. Сервер прогревает кэши, и профиль искажён. Подождите хотя бы пять минут после запуска.

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

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

Практические правила

• Профилируйте в час пик, на 5–10 минут. Короткие профили дают шум.
• Сохраняйте ссылки на отчёты с датой. Через неделю вы сравните, стало ли лучше.
• Меняйте одно за раз и снова профилируйте. Иначе не поймёте, что помогло.
• Не публикуйте ссылку на отчёт с личными данными игроков в открытых каналах. В отчёте могут быть имена классов и пути к файлам сервера.

Что делать, если отчёт непонятен

Бывает, что дерево выглядит запутанным, а широкой ветки нет. Тогда помогает другой подход.

• Сравните два профиля. Снимите один в спокойное время и один в пик. Ветка, которая появляется только в пик, и есть причина.
• Сузьте интервал. Короткий профиль в момент лага (1–2 минуты) лучше длинного, который усредняет всё.
• Ищите по имени пакета. Если в дереве видно имя плагина или мода, раскройте эту ветку и смотрите, сколько процентов тика она занимает.
• Отключайте по одному. Если подозреваете плагин, отключите его на тестовой копии, снимите профиль и сравните.

Не пытайтесь понять каждый метод. Нужна только самая широкая ветка и её владелец: плагин, мод или ядро.

Как передать отчёт в поддержку

Если сами не справились, отправьте в поддержку:

• ссылку на отчёт spark или файл из --save-to-file;
• MSPT в час пик из /spark tps;
• список последних изменений: что ставили, что меняли.

Так поддержка сможет быстрее посмотреть, что тормозит, и подсказать решение. Перед отправкой проверьте, что в отчёте нет чужих личных данных.

Частые ошибки

Запускать профилирование без таймера и забыть остановить. Профилировщик работает и сам по себе создаёт нагрузку. Всегда используйте --timeout.

Смотреть только TPS. TPS — это следствие. Смотрите MSPT: он показывает время одного тика.

Править конфиг по совету из чата, не посмотрев отчёт. Настройка, которая помогла у соседа, может не помочь вам, если узкое место в другом плагине.

Сравнивать отчёты разной длины. Пять минут и двадцать минут дают разный объём данных. Сравнивайте одинаковые интервалы.

Итог

Spark — самый быстрый способ понять, где сервер теряет время. Порядок такой: /spark tps покажет, есть ли проблема, /spark profiler start --timeout 300 снимет профиль в нагрузке, /spark profiler stop выдаст ссылку на дерево вызовов. Ищите широкие ветки, сверяйте их с установленными модами и плагинами, и только потом меняйте настройки. Так лаги перестают быть загадкой.

Вопросы и ответы

Как запустить spark на Paper 1.21.x?

Выполните в консоли /spark profiler start --timeout 300. Через пять минут профилировщик остановится сам и выдаст ссылку на отчёт.

Какой MSPT считается нормальным?

Не больше 50 мс. Тогда TPS держится на 20. Выше 50 мс сервер начинает отставать от реального времени.

Нужна ли отдельная установка spark?

На Paper 1.21 и новее spark уже встроен. На других ядрах и загрузчиках он ставится отдельно как плагин или мод.

Можно ли скинуть отчёт в поддержку?

Да, ссылка на отчёт или файл из --save-to-file подойдёт. Перед отправкой проверьте, что в отчёте нет чужих данных.

Сервер под Minecraft за пару минут — egnetwork.ru