- Поддерживаемые версии
- 1.8
- 1.9
- 1.10
- 1.11
- 1.12
- 1.13
- 1.15
- 1.16
- 1.17
- 1.18
- 1.19
Примечание автора адаптации:
Этот гайд является почти дословным переводом статьи из оф.документации спарка.
В данном гайде не будет упомянуто обо всех функциях плагина. Лишь информация из раздела "spark guides".
Целью выкладывания сюда данной статьи является научить пользователей, не знакомых со спарком и не особо знающих английский, пользоваться им и что более важно, понимать, как правильно его использовать!
Раздел 1 - Вводная часть. TPS MSPT и их значение (если вы уже в курсе, что да как, то переходите сразу ко 2 разделу)
Почти все видеоигры (включая Minecraft) управляются одним большим программным циклом. Выполнение функций сервера (и игры) разбито на "тики".
Каждый раз, когда происходит "тик", игровой сервер будет выполнять ряд действий, таких как:
• Обработка входящих пакетов от игроков (например, перемещение, размещение / разрушение блоков, атака на другие объекты)
• Обновление позиции игроков и других субъектов
• Отправка исходящих пакетов всем игрокам о событиях, происходящих на сервере (изменения блоков, перемещение объектов и действия).
• Создание новых мобов, обработка ИИ мобов, поиск путей и т.д.
• Обработка обновлений редстоуна
И еще много чего!
Сервер Minecraft нацелен на запуск ровно 20 таких игровых "тиков" каждую секунду, или, другими словами, по одному тику каждые 50 миллисекунд.
Конечно, объем работы, необходимый для каждого тика, варьируется в зависимости от того, что происходит в игре, поэтому тики на практике никогда не будут такими регулярными!
Когда сервер работает нормально, время, необходимое для выполнения полного тика, должно быть меньше (или равно) 50 миллисекунд. Если время, затраченное на тик, составляет менее 50 миллисекунд, сервер будет "спать" в течение оставшегося времени, пока не будет готов выполнить следующий тик.
К примеру
• Сервер тратит 15 миллисекунд на выполнение тика
• Контроллер тикового цикла "спит" (ничего не делает) в течение 35 миллисекунд, прежде чем начать выполнение следующего тика.
Как вы можете видеть, все тики в этом примере заняли менее 50 миллисекунд, но они были распределены, чтобы гарантировать, что ровно 20 были обработаны за секунду. Если бы сервер не оставлял места между тиками (спящий режим между ними), то игра действительно "чувствовалась бы" быстрее - все происходило бы быстрее! (мобы двигались бы на большей скорости и т.д.)
Если тик занимает больше 50 миллисекунд, выполнение следующего тика должно быть отложено, так как тики не могут выполняться параллельно. Когда это происходит, игровой процесс начинает ухудшаться, так как все становится менее отзывчивым и "лагучим".
Как вы можете видеть, когда отдельные тики начинают занимать больше времени, все "смещается вправо", и за тот же промежуток времени происходит меньше игровых тиков. Вот почему, когда сервер отстает, все происходит медленнее.
Вы также можете увидеть, откуда берутся показатели TPS (тики в секунду) и MSPT (миллисекунды на тик).
В примере, показанном выше:
spark сообщит о TPS как 17, потому что только 17 тиков смогли быть обработаны во втором spark сообщит о минимальном MSPT ~ 20 мс (хорошо!), Но максимальном MSPT ~ 80 мс (более 50 мс, это плохо!)
Тики в профилях spark
Вы можете четко идентифицировать тиковую петлю в профилях spark, обычно она видна прямо вверху!
В приведенном выше примере мы видим, что на waitForNextTick() приходится 81% активности процессора в "серверном потоке".
Это здорово! Это означает, что в среднем сервер мог потратить около 80% из 50 миллисекунд, выделенных на каждый тик, абсолютно ничего не делая. Это хорошо, потому что указывает на наличие свободных мощностей на сервере.
Если на сервере наблюдается всплеск активности (например, присоединяется больше игроков, обновляется больше объектов / блоков), сервер должен быть в состоянии справиться с этим.
Обычно:
• Более высокий процент сна - это хорошо
• Если у вас спящий режим менее 20% (и, следовательно, более 80% тиков), ваш сервер работает довольно интенсивно и может отставать на некоторых тиках (помните, что эти значения являются средними!)
• Если у вас спящий режим менее 5% (и, следовательно, более 95%), ваш сервер, вероятно, отстает и не имеет свободных мощностей.
Последнее замечание, которое следует запомнить: эти значения являются средними! Гипотетически, ваш сервер может тратить всего 20 миллисекунд на обработку большинства тиков (исправно), но затем иногда тратить 300 миллисекунд на обработку некоторых тиков. (не хорошо!) Это то, что, вероятно, происходит, если вы испытываете "всплески лагов" в отличие от общей плохой производительности. Если это так, то проценты для "сна" и "тика" обманчивы, поскольку экстремальные значения усредняются.
Раздел 2 - Ищем причины лагов
Всплески лагов возникают, когда выполнение небольшого количества тиков (или иногда только одного тика) занимает много времени. Это может происходить либо довольно часто, например, 1 раз в каждые 20 тиков, либо редко, например, раз в минуту. Обычно они связаны с поведением игроков.
Найти причину скачков задержки, просто просматривая обычные данные профилирования, может быть непросто, поскольку данные усредняются. Все остальные замеры "нейтрализуют" всплеск и маскируют его влияние.
К счастью, у spark есть два полезных инструмента для решения этой проблемы.
Шаг 1: Используйте /spark tickmonitor для обнаружения всплеска задержки
Чтобы определить причину всплеска лагов в отчете профайлера, нам нужно иметь возможность отделить "проседающие" тики от всех остальных.
Для этого мы можем использовать команду /spark tickmonitor.
Эта команда работает, сначала устанавливая среднюю частоту тиков сервера, а затем:
• Отслеживает время, затраченное на каждый последующий тик
• Вычисляет разницу (в процентах) между временем, затраченным на выполнение последнего тика, и средним
• Отправляет сообщение в чат, если разница превышает определенный порог
Чтобы включить мониторинг, просто запустите /spark tickmonitor По умолчанию пороговое значение равно 100% (увеличение на 100% означает, что тик занял в два раза больше времени, чем в среднем). Вы также можете указать пороговое значение в качестве абсолютной длительности тика, например /spark tickmonitor --threshold-tick 50, чтобы сообщать о любом тике, превышающем 50 миллисекунд (это точка, в которой сервер должен начать догонять или отставать).
Тогда вам просто нужно подождать. Если пролагивания, которые вы испытываете, заметны в игровом процессе, попробуйте сопоставить эффекты лагов в игре с результатами мониторинга. Если выходные данные недостаточно чувствительны, попробуйте установить более низкий порог, например /spark tickmonitor --threshold-tick 70.
Ради объяснения здесь я собираюсь "создать" всплеск лагов с помощью WorldEdit.
Как вы можете видеть, время тиков при выполнении действия WorldEdit увеличилось более чем на 1000%!
Шаг 2: Используйте /spark profiler start с --only-ticks-over, чтобы найти причину лагов
Опция --only-ticks-over означает, что spark будет профилировать только те игровые тики, которые длятся дольше заданного порога.
Это отфильтровывает все "нормальные" игровые вещи и оставляет только запаздывающие тики, о которых нужно беспокоиться. Вы можете использовать шаг 1, чтобы определить хорошее пороговое значение, я рекомендую использовать значение от 50 до 100, но оно всегда должно быть меньше, чем продолжительность "запаздывающих" тиков.
Например, запаздывающие действия, определенные в моем примере на шаге 1, составляли более 300 миллисекунд, но просто чтобы быть уверенным, что они будут включены, я буду использовать более низкий порог в 150 миллисекунд.
Затем запустите, например, /spark profiler start --only-ticks-over 150.
Это запустит новый профилировщик, но будет включать только образцы из тиков, выполнение которых заняло более 150 мс. После завершения откройте средство просмотра и проверьте профиль в обычном режиме. Надеюсь, запаздывающие области будут особенно четкими.
Например...
Обобщая описанное выше (снова пишу я):
1 - Сначала делаем /spark tickmonitor --threshold-tick 55 --without-gc чтобы понять, какая у нас длинна тика при лагах. (если сильно спамит - увеличиваем значение)
2 - После того как поняли, какая длинна тиков минимальная при лагах (если у вас показывает, что длинна тиков от 120 до 250 к примеру, это значение равно 120-150) то ставим профайлер при помощи команды /spark profiler start --only-ticks-over 125 --timeout 300 (5 минут). По истечении 5 минут смотрим на результаты.
Чаще всего причина лагов - неоптимизированные конфиги ядра. По этому смотрите статью по оптимизации и жизнь ваша станет проще. Если с конфигами всё хорошо - загляните в раздел с плагинами, который можно открыть дважды клацнув на кнопку all (раздел с плагинами отмечен как sources)
->
Там будут показаны самые лагучие плагины. Что с ними делать - решите думаю сами.
Этот гайд является почти дословным переводом статьи из оф.документации спарка.
В данном гайде не будет упомянуто обо всех функциях плагина. Лишь информация из раздела "spark guides".
Целью выкладывания сюда данной статьи является научить пользователей, не знакомых со спарком и не особо знающих английский, пользоваться им и что более важно, понимать, как правильно его использовать!
Раздел 1 - Вводная часть. TPS MSPT и их значение (если вы уже в курсе, что да как, то переходите сразу ко 2 разделу)
Почти все видеоигры (включая Minecraft) управляются одним большим программным циклом. Выполнение функций сервера (и игры) разбито на "тики".
Каждый раз, когда происходит "тик", игровой сервер будет выполнять ряд действий, таких как:
• Обработка входящих пакетов от игроков (например, перемещение, размещение / разрушение блоков, атака на другие объекты)
• Обновление позиции игроков и других субъектов
• Отправка исходящих пакетов всем игрокам о событиях, происходящих на сервере (изменения блоков, перемещение объектов и действия).
• Создание новых мобов, обработка ИИ мобов, поиск путей и т.д.
• Обработка обновлений редстоуна
И еще много чего!
Сервер Minecraft нацелен на запуск ровно 20 таких игровых "тиков" каждую секунду, или, другими словами, по одному тику каждые 50 миллисекунд.
Конечно, объем работы, необходимый для каждого тика, варьируется в зависимости от того, что происходит в игре, поэтому тики на практике никогда не будут такими регулярными!
Когда сервер работает нормально, время, необходимое для выполнения полного тика, должно быть меньше (или равно) 50 миллисекунд. Если время, затраченное на тик, составляет менее 50 миллисекунд, сервер будет "спать" в течение оставшегося времени, пока не будет готов выполнить следующий тик.
К примеру
• Сервер тратит 15 миллисекунд на выполнение тика
• Контроллер тикового цикла "спит" (ничего не делает) в течение 35 миллисекунд, прежде чем начать выполнение следующего тика.
Как вы можете видеть, все тики в этом примере заняли менее 50 миллисекунд, но они были распределены, чтобы гарантировать, что ровно 20 были обработаны за секунду. Если бы сервер не оставлял места между тиками (спящий режим между ними), то игра действительно "чувствовалась бы" быстрее - все происходило бы быстрее! (мобы двигались бы на большей скорости и т.д.)
Если тик занимает больше 50 миллисекунд, выполнение следующего тика должно быть отложено, так как тики не могут выполняться параллельно. Когда это происходит, игровой процесс начинает ухудшаться, так как все становится менее отзывчивым и "лагучим".
Как вы можете видеть, когда отдельные тики начинают занимать больше времени, все "смещается вправо", и за тот же промежуток времени происходит меньше игровых тиков. Вот почему, когда сервер отстает, все происходит медленнее.
Вы также можете увидеть, откуда берутся показатели TPS (тики в секунду) и MSPT (миллисекунды на тик).
В примере, показанном выше:
spark сообщит о TPS как 17, потому что только 17 тиков смогли быть обработаны во втором spark сообщит о минимальном MSPT ~ 20 мс (хорошо!), Но максимальном MSPT ~ 80 мс (более 50 мс, это плохо!)
Тики в профилях spark
Вы можете четко идентифицировать тиковую петлю в профилях spark, обычно она видна прямо вверху!
В приведенном выше примере мы видим, что на waitForNextTick() приходится 81% активности процессора в "серверном потоке".
Это здорово! Это означает, что в среднем сервер мог потратить около 80% из 50 миллисекунд, выделенных на каждый тик, абсолютно ничего не делая. Это хорошо, потому что указывает на наличие свободных мощностей на сервере.
Если на сервере наблюдается всплеск активности (например, присоединяется больше игроков, обновляется больше объектов / блоков), сервер должен быть в состоянии справиться с этим.
Обычно:
• Более высокий процент сна - это хорошо
• Если у вас спящий режим менее 20% (и, следовательно, более 80% тиков), ваш сервер работает довольно интенсивно и может отставать на некоторых тиках (помните, что эти значения являются средними!)
• Если у вас спящий режим менее 5% (и, следовательно, более 95%), ваш сервер, вероятно, отстает и не имеет свободных мощностей.
Последнее замечание, которое следует запомнить: эти значения являются средними! Гипотетически, ваш сервер может тратить всего 20 миллисекунд на обработку большинства тиков (исправно), но затем иногда тратить 300 миллисекунд на обработку некоторых тиков. (не хорошо!) Это то, что, вероятно, происходит, если вы испытываете "всплески лагов" в отличие от общей плохой производительности. Если это так, то проценты для "сна" и "тика" обманчивы, поскольку экстремальные значения усредняются.
Раздел 2 - Ищем причины лагов
Всплески лагов возникают, когда выполнение небольшого количества тиков (или иногда только одного тика) занимает много времени. Это может происходить либо довольно часто, например, 1 раз в каждые 20 тиков, либо редко, например, раз в минуту. Обычно они связаны с поведением игроков.
Найти причину скачков задержки, просто просматривая обычные данные профилирования, может быть непросто, поскольку данные усредняются. Все остальные замеры "нейтрализуют" всплеск и маскируют его влияние.
К счастью, у spark есть два полезных инструмента для решения этой проблемы.
Шаг 1: Используйте /spark tickmonitor для обнаружения всплеска задержки
Чтобы определить причину всплеска лагов в отчете профайлера, нам нужно иметь возможность отделить "проседающие" тики от всех остальных.
Для этого мы можем использовать команду /spark tickmonitor.
Эта команда работает, сначала устанавливая среднюю частоту тиков сервера, а затем:
• Отслеживает время, затраченное на каждый последующий тик
• Вычисляет разницу (в процентах) между временем, затраченным на выполнение последнего тика, и средним
• Отправляет сообщение в чат, если разница превышает определенный порог
Чтобы включить мониторинг, просто запустите /spark tickmonitor По умолчанию пороговое значение равно 100% (увеличение на 100% означает, что тик занял в два раза больше времени, чем в среднем). Вы также можете указать пороговое значение в качестве абсолютной длительности тика, например /spark tickmonitor --threshold-tick 50, чтобы сообщать о любом тике, превышающем 50 миллисекунд (это точка, в которой сервер должен начать догонять или отставать).
Тогда вам просто нужно подождать. Если пролагивания, которые вы испытываете, заметны в игровом процессе, попробуйте сопоставить эффекты лагов в игре с результатами мониторинга. Если выходные данные недостаточно чувствительны, попробуйте установить более низкий порог, например /spark tickmonitor --threshold-tick 70.
Ради объяснения здесь я собираюсь "создать" всплеск лагов с помощью WorldEdit.
Как вы можете видеть, время тиков при выполнении действия WorldEdit увеличилось более чем на 1000%!
Шаг 2: Используйте /spark profiler start с --only-ticks-over, чтобы найти причину лагов
Опция --only-ticks-over означает, что spark будет профилировать только те игровые тики, которые длятся дольше заданного порога.
Это отфильтровывает все "нормальные" игровые вещи и оставляет только запаздывающие тики, о которых нужно беспокоиться. Вы можете использовать шаг 1, чтобы определить хорошее пороговое значение, я рекомендую использовать значение от 50 до 100, но оно всегда должно быть меньше, чем продолжительность "запаздывающих" тиков.
Например, запаздывающие действия, определенные в моем примере на шаге 1, составляли более 300 миллисекунд, но просто чтобы быть уверенным, что они будут включены, я буду использовать более низкий порог в 150 миллисекунд.
Затем запустите, например, /spark profiler start --only-ticks-over 150.
Это запустит новый профилировщик, но будет включать только образцы из тиков, выполнение которых заняло более 150 мс. После завершения откройте средство просмотра и проверьте профиль в обычном режиме. Надеюсь, запаздывающие области будут особенно четкими.
Например...
Обобщая описанное выше (снова пишу я):
1 - Сначала делаем /spark tickmonitor --threshold-tick 55 --without-gc чтобы понять, какая у нас длинна тика при лагах. (если сильно спамит - увеличиваем значение)
2 - После того как поняли, какая длинна тиков минимальная при лагах (если у вас показывает, что длинна тиков от 120 до 250 к примеру, это значение равно 120-150) то ставим профайлер при помощи команды /spark profiler start --only-ticks-over 125 --timeout 300 (5 минут). По истечении 5 минут смотрим на результаты.
Чаще всего причина лагов - неоптимизированные конфиги ядра. По этому смотрите статью по оптимизации и жизнь ваша станет проще. Если с конфигами всё хорошо - загляните в раздел с плагинами, который можно открыть дважды клацнув на кнопку all (раздел с плагинами отмечен как sources)
Там будут показаны самые лагучие плагины. Что с ними делать - решите думаю сами.
