Почему падает TPS в Minecraft и как это чинить по порядку

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

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

TPS, MSPT и за каким из них следить#

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

Получаются два числа, и они не одинаково полезны:

• TPS - тиков в секунду, максимум 20. Команда Paper tps печатает средние за одну, пять и пятнадцать минут. Это запаздывающий показатель: к моменту, когда он сдвинулся, проблема уже какое-то время существует.
• MSPT - миллисекунд на тик, настоящее измерение. Команда Paper mspt печатает среднее, минимум и максимум за последние пять секунд, десять секунд и минуту.

Сервер с 20.0 TPS и 47 MSPT в одной ферме мобов от беды. Сервер с 20.0 TPS и 12 MSPT ещё имеет запас. TPS не различает эти два случая, MSPT различает. Следите за MSPT и считайте предупреждением всё, что стабильно выше примерно 35, хотя ничего заметного ещё не происходит.

Когда MSPT переходит за 50, всё, что привязано к игровому времени, замедляется разом: медленнее растут посевы, медленнее плавятся печи, мобы двигаются шагами. Игроки описывают это как рывки или как блоки, которые возвращаются после того, как их сломали: это клиент предсказывает мир, до которого сервер ещё не дошёл. Почему в разных играх с этим обращаются по-разному, объясняет статья что на самом деле значит tick rate.

Лаг, который вообще не про TPS#

Прежде чем тратить вечер на лимиты сущностей, убедитесь, что проблема в TPS. Четыре частые жалобы - не о нём:

• Частота кадров на клиенте. Если тормозит один человек, а все остальные в порядке, это проблема графики, обычно дальность прорисовки или шейдеры. Команда tps в консоли решает вопрос одной строкой.
• Пинг и потеря пакетов. Высокая задержка выглядит как пауза между действием и его результатом, но мир при этом движется плавно. Если MSPT в порядке, а жалуются все игроки одного региона, это сеть; какая из трёх проблем у вас, объясняет статья задержка, джиттер и потеря пакетов.
• Загрузка чанков на клиенте. Медленно появляющаяся местность при полёте игрока часто связана с пропускной способностью и клиентом, а не с тиками сервера.
• Исчерпанная доля процессора. Контейнер, прижатый к выделенной ему доле, медленный, а не сломанный. На RE:NODE лимит CPU - это жёсткое ограничение до купленной доли, один контейнер на сервер, и сервер, сидящий на 100%, никогда не повод для блокировки, но быстрее он от этого не пойдёт. Более широкий взгляд - в статье общий CPU и шумные соседи.

Что тратит пятьдесят миллисекунд#

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

Два пункта заслуживают чисел. Сущности - обычный ответ: ферма мобов, в которой две тысячи враждебных мобов, обходится в AI, поиск пути и проверки столкновений на каждом тике, а выпавшие предметы обходятся дороже за штуку, чем большинство ожидает, потому что они сливаются, исчезают и проверяют воронки под собой. А генерация чанков - самая дорогая одиночная операция сервера: один игрок на элитрах требует примерно сорок новых чанков в секунду, и поэтому границы мира и предварительная генерация стоят в списке исправлений ниже, а не в отдельной вселенной советов.

Измеряйте, а не гадайте#

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

Инструмент - spark. Свежие сборки Paper поставляются с ним; иначе это jar в plugins/. Выполните spark в консоли, чтобы увидеть, что у вас. Пять команд покрывают почти всё:

spark tpsspark healthreportspark profiler start --timeout 300spark profiler start --timeout 300 --only-ticks-over 100spark heapsummary

Каждая отвечает на свой вопрос, и запускать их стоит примерно в этом порядке.

• spark tps выдаёт TPS и перцентили MSPT вместе с загрузкой процессора процессом, что отличает «занят сервер» от «занята машина».
• spark healthreport - обзор одним запросом: TPS, MSPT, память, диск и по каждому миру число сущностей, чанков и блок-сущностей. Начните с него.
• spark profiler start --timeout 300 снимает выборку пять минут, а затем присылает ссылку на просмотрщик. Пусть он работает, пока сервер действительно капризничает: профиль тихого сервера ничего не скажет.
• --only-ticks-over 100 - версия для охоты на всплески: он записывает только тики, занявшие больше 100 мс, так что отчёт не тонет в обычной работе.
• spark heapsummary перечисляет по классам, что занимает память, и так находят утечку.

В просмотрщике отсортируйте по self time и читайте сверху вниз, пока не увидите что-то, что не является собственным кодом сервера. Имя пакета плагина в начале списка с большим self time - это и есть ваш ответ. Если в начале сплошь обработка сущностей или работа с чанками, ответ не в плагине, и применимы исправления ниже. Настоящий отчёт разобран построчно в статье как читать отчёт spark.

Две команды Paper стоит знать рядом с ним. paper entity list печатает число сущностей по чанкам, так что можно найти точные координаты проблемной фермы, а paper mobcaps показывает, насколько каждая категория появления близка к своему лимиту.

Исправления, от самых дешёвых#

1. Очистите скопившиеся сущности и ограничьте то, что их создало. Найдите их через paper entity list, затем разберитесь с источником. kill @e[type=item] убирает выпавшие предметы; никогда не используйте просто kill @e, который заберёт рамки, картины, стойки для брони и всё остальное неподвижное.
2. Уменьшите дальность прорисовки и дальность симуляции на один-два. Почти никто не заметит, а сервер заметит сразу. Это самое ценное единичное изменение на большинстве серверов.
3. Ужесточите дальности активации сущностей и лимиты мобов. Мобы за пределами дальности активации перестают выполнять AI, не исчезая, - это большая экономия за небольшое изменение поведения.
4. Займитесь воронками и редстоуном. У обоих есть настройки Paper, снижающие их стоимость и не меняющие то, что игроки могут строить.
5. Уберите или замените плагин, который назвал профайлер. Если функция вам нужна, сначала проверьте, нет ли новой сборки: ошибки производительности исправляют.
6. Задайте границу мира и заранее сгенерируйте внутри неё, чтобы исследование не генерировало местность в часы пик.
7. Правильно подберите размер кучи. Больше памяти не значит быстрее: слишком большая куча делает паузы сборки мусора длиннее. Оставьте контейнеру около 1 ГБ вне кучи для самой JVM и операционной системы. Флаги описаны в статье флаги JVM и версии Java, а размеры - в сколько RAM нужно серверу Minecraft.
8. И только потом думайте о более быстрой машине. Цикл тиков Minecraft в основном однопоточный, поэтому помогает более быстрое ядро, а не больше ядер: полный довод есть в статье CPU или RAM для игровых серверов, а как понять, что программные исправления закончились, - в когда переходить на другой тариф.

Настройки, которые важны, и их значения по умолчанию#

Про две настройки расстояния стоит сказать точно, потому что люди меняют не ту. view-distance - это сколько чанков отправляется каждому клиенту: она стоит трафика и памяти, и её снижение ускоряет вход. simulation-distance - сколько чанков вокруг каждого игрока действительно тикают, и именно она стоит процессорного времени. Если опустить дальность симуляции слишком низко, фермы перестанут работать, пока их владелец стоит у пульта, так что 5 или 6 - это нижняя граница для большинства survival-серверов, а не цель.

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

Разбор примера#

Сервер survival на 6 ГБ, восемнадцать постоянных игроков, четыре месяца. Жалобы на блоки, которые не ломаются. tps показывал 13.4 за минуту; mspt - среднее 74 с максимумом свыше 300.

spark healthreport показал около 11 000 сущностей в верхнем мире, что для восемнадцати игроков в четыре-пять раз больше нормы. paper entity list поместил 2 100 из них в два чанка: ферма зомби с переполненной зоной сбора плюс все предметы, которые она когда-либо выронила, потому что воронку сломали несколько недель назад, а никто не заметил.

Починка фермы заняла десять минут и снизила MSPT до 41 - лучше, но всё ещё нехорошо. Пятиминутный профиль с --only-ticks-over 100 затем показал, что остальные всплески - это загрузка чанков, а не сущности: двое игроков картографировали внешний мир и постоянно генерировали местность. view-distance снизили с 10 до 8, simulation-distance - с 10 до 6, поставили границу на 6 000 и запустили ночной Chunky внутри неё.

На следующий вечер те же восемнадцать игроков сидели на 19.9 TPS и 28 MSPT. Ничего не купили, ничего не убрали, а единственным изменением плагинов было отсутствие изменений - это обычный исход, когда профайлер получает слово раньше кошелька.

Наблюдение, чтобы замечать раньше игроков#

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

Несколько привычек стоят больше любого дашборда:

• Раз в неделю выполняйте spark healthreport и сохраняйте цифры. Число сущностей, дрейфующее вверх в течение месяца, - самое раннее предупреждение.
• Перезапускайте по расписанию. Утечку это не лечит, но ограничивает вред от неё и держит состояние чанков в порядке; время выбирайте по статье расписания перезапусков, которые помогают.
• Профилируйте, пока сервер плох, а не после того, как он оправился. Сохранённый пятиминутный профиль с худшего вечера месяца стоит больше десяти, снятых во вторник в тишине.
• Если сервер не замедляется, а останавливается, это другая проблема: память. На лимите памяти контейнер останавливается и запускается заново начисто, а не оставляется работать со swap, а повторные перезапуски поднимают предупреждение и автоматический тикет. Об этом статья почему ваш игровой сервер постоянно перезапускается.

FAQ#

Какой MSPT считается хорошим?

Меньше 30 - комфортно, от 30 до 45 - сервер, у которого не осталось запаса, а всё выше 50 видно игрокам, потому что тики теперь длятся дольше, чем тику позволено. Среднее значение важно меньше максимума: регулярные всплески до 200 мс ощущаются хуже, чем стабильные 40.

Исправит ли низкий TPS больше RAM?

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

Поможет ли меньше плагинов?

Только если профайлер назвал какой-то из них. Двадцать хорошо написанных плагинов могут стоить меньше, чем один, который планирует задачу на каждый тик. Удаляйте то, на что указывает отчёт, а не то, что кажется длинным списком.

Почему TPS равен 20, а сервер всё равно лагает?

Потому что TPS ограничен 20 и скрывает всё, что ниже линии в пятьдесят миллисекунд. Смотрите на MSPT или на максимум, а не на среднее: сервер с 20 TPS и редкими тиками по 300 мс ощущается ровно так плохо, как говорят игроки.

Помогает ли перезапуск при низком TPS?

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

Может ли один игрок вызвать низкий TPS?

Легко. Один человек, влетевший в несгенерированную местность или стоящий внутри построенной им фермы, может придавить весь сервер. Это одно из самых полезных, что покажут paper entity list и профиль, снятый в тот момент.