MSPT и TPS сервера Minecraft показывают темп тиков и длительность каждого тика. Среднее значение может скрыть длинные тики, поэтому разберём, как читать тайминги Minecraft на Paper. Результат зависит от версии ядра, мира, плагинов, онлайна и метода измерения.

Чем TPS отличается от MSPT?

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

Понять бюджет главного потока Minecraft

Чтобы понять, как читать тайминги Minecraft, начните с цикла сервера. При стандартном tick rate сервер должен выполнять 20 тиков в секунду, поэтому на один тик приходится 50 мс. За это время главный поток обновляет миры, сущности и блоковые сущности, выполняет запланированные задачи плагинов, обрабатывает часть сетевых пакетов и применяет изменения мира. Большая часть этой работы идёт последовательно: следующий тик не начнётся, пока не завершится текущий.

Порог 50 мс не стоит считать универсальным. Если тик закончен раньше, сервер ждёт до следующего тика. Если позже, начинает отставать и пытается наверстать время. При изменённом tick rate меняется и бюджет. Поэтому рядом с метрикой фиксируют версию ядра и целевую скорость тиков.

Серверный тик не связан напрямую с FPS клиента и ping. Низкий FPS возникает при отрисовке на компьютере игрока, а ping отражает задержку обмена по сети. Долгий тик проявляется иначе: блоки ломаются с задержкой, мобы замирают, команды и взаимодействия выполняются позже. По времени этих симптомов выбирают участок для профилирования.

Читать темп тиков с учётом сглаживания и потолка

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

Связка 20 TPS и 50 MSPT даёт границу только для стандартного темпа. Когда средний тик стабильно занимает больше 50 мс, сервер уже не успевает поддерживать 20 TPS. Но обратный вывод другой: близкий к 20 средний TPS не исключает редкий тик на 200 или 500 мс. На длинном интервале он мало изменит среднее, хотя игрок заметит паузу.

Для устойчивой перегрузки TPS полезен: падение на минутном и пятиминутном интервале показывает, что проблема не ограничилась одним эпизодом. Для короткого лага берут временную линию MSPT и профиль того же периода. Не сравнивайте TPS из разных ядер или команд без оговорки: реализации могут использовать разные окна, округление и целевой tick rate.

Смотреть медиану и хвост времени тика

По MSPT видно распределение tick time, то есть длительности отдельных тиков. Медиана отражает обычный тик, p95 показывает границу для 95% наблюдений за выбранное окно, а максимум отмечает самый длинный эпизод. Среднее чувствительно к выбросам и не отвечает на вопрос, насколько часто они возникают. Поэтому для жалобы «раз в минуту всё зависает» важнее хвост распределения и временная линия, чем одно среднее значение.

Почему при нормальном TPS игроки всё равно видят лаги?

TPS может оставаться около целевого значения, потому что он усредняет темп за выбранное окно и имеет верхнюю границу. Игроки при этом замечают отдельные длинные тики. Похожий симптом дают паузы GC или задержки в сети. Сначала сопоставьте жалобу с MSPT, ping и профилем того же периода.

Длинный тик откладывает обработку действий всех игроков на главном потоке, поэтому дверь открывается или удар регистрируется позже. Если пики MSPT совпадают с такими паузами, дальше нужен профиль CPU. При этом старые тайминги Paper брать за основу не стоит: Paper помечает Timings устаревшими, а с 1.21 отключает их по умолчанию в пользу spark.

Снять профиль именно во время воспроизводимого лага

Диагностика лагов тика Minecraft начинается не с длинной записи «на всякий случай», а с воспроизводимого эпизода. Запишите версию Paper, Java и spark, число игроков, список миров и плагинов, view-distance и simulation-distance. Рядом опишите действие: например, перелёт в ещё не сгенерированную область, запуск фермы или массовое перемещение сущностей. Без этого профиль трудно повторить после правки.

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

/spark tickmonitor --threshold-tick 80
/spark profiler start --only-ticks-over 80 --timeout 300

Порог 80 мс здесь служит примером, а не универсальным значением. Его выбирают по разрыву между длительностью обычных и проблемных тиков. После завершения второй команды spark вернёт ссылку на профиль. Перед публикацией проверьте вкладки с конфигурацией, именами миров, адресами и комментариями: ссылка публична для каждого, кто её получил.

Найти работу, которая удерживает главный поток

Профайлер spark MSPT показывает отдельно от TPS, но причину лага не называет. В viewer откройте Server thread и идите по ветке с наибольшим временем до конкретного метода, сущности или плагина. Верхние узлы вроде MinecraftServer.tickChildren() лишь объединяют работу ниже. Их доли включают дочерние вызовы, поэтому соседние уровни нельзя складывать как независимые расходы.

Публичный профиль Paper 1.21.11 от 4 августа 2026 года показывает, как читать дерево. За 30-секундное окно при одном игроке средний темп составил 0,91 TPS; медиана равнялась 1110 мс, p95 1227 мс, максимум 1282 мс. В мире было 32 695 сущностей. В ветке Server thread профилировщик отнёс 28,6 из 30 секунд к Slime.tick() и 24,9 секунды к вложенному pushEntities(). Профиль указывает не на абстрактную нехватку CPU, а на обработку столкновений огромной группы слаймов.

Вывод относится только к профилю: Paper 1.21.11, один игрок, 30 секунд, запись запущена из консоли. В другом отчёте узел с именем плагина может лишь вызывать код ядра. Гипотезу подтверждают только после спуска к дочернему узлу и проверки тем же сценарием.

Сопоставить длинные тики с событиями мира и JVM

Какой раздел таймингов обычно показывает узкое место?

1. В spark сначала откройте Server thread: именно он выполняет последовательную работу игрового тика.

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

3. Сверьте дорогой узел с временной линией и повторяемым действием. Верхний контейнер сам по себе не доказывает причину.

Снимок дерева показывает, на каких вызовах профилировщик собрал образцы CPU, но не всегда объясняет редкий всплеск. Поэтому spark profiler читают вместе с временной линией. Отметьте момент генерации чанков, autosave, массового спавна, телепортации и сборки мусора. Если тот же пик появляется после одинакового действия, гипотеза становится проверяемой.

Совпадение по времени ещё ничего не доказывает. Пауза GC может начаться рядом с сохранением мира, а рост MSPT при перелёте может идти от генерации чанков, плагина защиты территории или синхронного чтения данных. На нужном интервале раскройте дорогой путь и посмотрите, какая работа находится внизу. Невысокая общая загрузка CPU не исключает эту причину: главный поток способен упереться в одно ядро, пока остальные простаивают.

Изменить один фактор и повторить тот же сценарий

Проверка начинается с копии мира и одного изменения. Если профиль указывает на плагин из каталога plugins, временно отключите его функцию, обновите или откатите версию, не меняя одновременно дистанции и лимиты сущностей. Если дорогая ветка связана с генерацией чанков, заранее сгенерируйте тот же участок на тестовой копии. Для группы сущностей остановите источник спавна и повторите действие в той же области.

До и после правки сохраняют версию ядра, seed и состояние мира, маршрут игрока, онлайн, длительность профиля и настройки JVM. На живом сервере трудно повторить нагрузку полностью, но условия должны быть близкими, чтобы изменение не потерялось в шуме. Одного удачного прогона не хватит: повторите серию и сравните медиану, p95, максимум, TPS за одинаковое окно и симптом, который наблюдали игроки.

Если дорогой узел исчез, но длинные тики остались, первая гипотеза объясняла лишь часть задержки. Зафиксируйте этот результат отдельно, затем исследуйте следующий путь. Такой порядок не даёт приписать эффект сразу пяти твикам и помогает откатить правку, которая ухудшила механику мира.

Превратить профиль в приоритет исправлений

Исправления сортируют по подтверждённому времени главного потока, а не по популярности совета. Если в viewer доминируют entities and chunks, проверяют источник массового спавна, размер активной области, генерацию мира и тяжёлые операции. Настройку выбирают по найденной ветке: снижение view-distance не исправит плагин, который синхронно обходит всех игроков каждый тик.

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

Более быстрый процессор имеет смысл, если после правок главный поток остаётся занят вычислениями. Тогда сравнивают производительность одного ядра на той же сборке сервера, а не число vCPU в тарифе. Сначала убирают лишнюю работу, затем добавляют ресурсы для оставшейся нагрузки.

Рабочий цикл короткий: воспроизведите задержку, снимите профиль на том же участке, раскройте дорогую ветку и измените один фактор. Повторный замер должен улучшить не только среднее, но и хвост MSPT и симптом, который наблюдали игроки. Если симптом не изменился, гипотезу нужно пересмотреть.

Цель диагностики не удержать TPS на отметке 20, а убрать подтверждённую работу, которая растягивает тик. Для каждого вывода сохраняют версию, условия, временное окно и профиль. В таком отчёте MSPT и TPS сервера Minecraft помогают проверить причину лага и результат исправления, не ограничиваясь двумя цифрами.