Падение TPS ниже 20 - прямой сигнал: сервер Minecraft не справляется с нагрузкой. Игроки замечают задержки при разрушении блоков, мобы двигаются рывками, а редстоун-механизмы срабатывают с опозданием. Причина всегда одна - время обработки одного игрового тика (MSPT) превысило допустимый лимит в 50 миллисекунд. Чтобы вернуть стабильность, нужно найти источник задержки: проблемный плагин, скопление сущностей или перегруженные чанки. Инструмент Spark даёт полную картину происходящего внутри сервера и позволяет локализовать проблему за 10-15 минут профилирования.
Эта инструкция построена на практических сценариях. Вы запустите профилировщик, прочитаете отчёт и устраните корневую причину лагов. Никакой теории ради теории - только команды, параметры конфигурации и пошаговые алгоритмы действий. Если вам нужен более широкий обзор инструментов мониторинга, включая интеграцию с Prometheus и Zabbix, обратитесь к руководству по мониторингу серверов Minecraft.
Диагностика производительности: с чего начать
Первичная диагностика не требует установки дополнительных инструментов. Откройте консоль сервера и выполните /tps. Вы увидите три значения TPS для разных временных промежутков: последняя минута, 5 минут и 15 минут. Норма - 20.0 для каждого интервала. Падение до 18-19 уже ощущается игроками как микрозадержки. Значения ниже 15 делают игру некомфортной, а ниже 10 - практически неиграбельной.
Визуальные признаки низкого TPS: блоки после разрушения появляются снова через секунду, мобы замирают на месте, выстрелы из лука не регистрируются сервером. Если вы наблюдаете такие симптомы - пора переходить к профилированию.
Что такое TPS и MSPT и почему они падают
TPS (ticks per second) - количество игровых тиков, которые сервер обрабатывает за одну секунду. Игровой мир Minecraft обновляется 20 раз в секунду: каждый тик просчитывает движение мобов, рост растений, передачу редстоун-сигналов, обработку команд плагинов. Когда сервер не успевает завершить все вычисления за отведённое время, он пропускает тик - TPS падает.
MSPT (milliseconds per tick) - время в миллисекундах, затраченное на обработку одного тика. При 20 TPS каждый тик должен уложиться в 50 миллисекунд (1000 мс / 20 тиков = 50 мс). Если MSPT превышает 50 мс, сервер физически не может обработать 20 тиков в секунду - TPS снижается. Зависимость прямая: MSPT 60 мс даёт примерно 16-17 TPS, MSPT 100 мс - около 10 TPS.
Типичные причины высокого MSPT: плагины с неэффективным кодом, избыточное количество сущностей (мобы, животные, вагонетки, выброшенные предметы), активная генерация новых чанков при исследовании мира, массивные редстоун-фермы с сотнями воронок и поршней. Каждую из этих причин Spark показывает в отчёте с точностью до конкретного метода или события.
Обзор инструментов: Spark vs встроенный Timings
Встроенный в Paper/Spigot профилировщик /timings даёт базовый срез по плагинам и событиям. Он подходит для быстрой проверки: запустили, подождали минуту, получили отчёт. Но у Timings есть ограничения: он не показывает полное дерево вызовов методов, сильнее нагружает сервер во время профилирования и не поддерживает фоновый мониторинг.
Spark решает эти задачи на другом уровне. Дерево вызовов (call tree) позволяет провалиться от общего времени тика до конкретного метода внутри конкретного плагина. Профилировщик использует сэмплирование, а не инструментирование кода - нагрузка на сервер во время сбора данных минимальна. Фоновый мониторинг работает постоянно и не требует ручного запуска. Для глубокого анализа причин лагов Spark - основной инструмент, Timings - вспомогательный для быстрых проверок.
Установка и первый запуск Spark
Установка занимает меньше минуты. Скачайте актуальную версию Spark с официального сайта (раздел Downloads, выберите платформу вашего сервера). Для Paper, Spigot и производных ядер поместите JAR-файл в папку plugins. Для Fabric и Forge - в папку mods. Перезапустите сервер или выполните /reload confirm (перезагрузка предпочтительнее, так как гарантирует корректную инициализацию).
Проверьте, что плагин загрузился: /spark выведет список доступных команд. Для первого профилирования выполните /spark profiler start. Профилировщик начнёт сбор данных. Рекомендуемая длительность - 10 минут в часы пиковой нагрузки, когда проблема проявляется наиболее ярко. Остановите профилирование командой /spark profiler stop. Spark выведет в чат ссылку на интерактивный отчёт - откройте её в браузере.
Анализ отчета Spark: находим корень лагов
Ссылка после остановки профилировщика ведёт на страницу с интерактивным отчётом. В верхней части - общая статистика: длительность профилирования, средний TPS и MSPT за период. Ниже - основная рабочая область с переключением между представлениями. Ваша задача - найти компонент, который потребляет непропорционально много процессорного времени.
Правило поиска: ищите проценты, а не абсолютные значения. Если плагин занимает 40% времени тика при общем MSPT 80 мс - он тратит 32 мс, что само по себе превышает половину допустимого лимита. Устранение этой проблемы даст максимальный прирост производительности.
Структура отчета: дерево вызовов и плоский список
Дерево вызовов (Call Tree) показывает иерархию методов - от корневого tick до конечных операций. Раскрывая узлы, вы видите, как общее время распределяется по подсистемам: tick → entity tick → tick mob → конкретный тип моба. Это представление отвечает на вопрос «в каком контексте тратится время».
Плоский список (Flat List) агрегирует время выполнения каждого метода независимо от того, кто его вызвал. Сортировка по столбцу «Self Time %» сразу показывает главных потребителей. Если плагин SuperProtect занимает 35% в плоском списке - проблема в нём, независимо от того, из какого события он был вызван. Для первичного анализа начинайте с плоского списка, для детального расследования переключайтесь на дерево вызовов.
Выявление проблемных плагинов по таймингам
Сценарий: вы запустили профилировщик в час пик при онлайне 20 игроков. Остановили через 10 минут, открыли отчёт. В плоском списке отсортировали по «Self Time %». Видите: Plugin:OldCombat - 28%, Plugin:DynMap - 12%, остальные - менее 5% каждый.
Порог внимания - 10-15% времени тика. Всё, что выше, требует действий. Раскройте OldCombat в дереве вызовов: 22% из 28% приходятся на PlayerMoveEvent. Плагин обрабатывает каждое движение каждого игрока и выполняет тяжёлые вычисления. Решения: обновить плагин до последней версии (разработчик мог исправить проблему), проверить конфиг на предмет избыточных проверок, заменить на более производительный аналог. Если плагин критичен для проекта - свяжитесь с автором и предоставьте ссылку на отчёт Spark.
Детальный разбор оптимизации конфигурации сервера и JVM-аргументов, влияющих на производительность плагинов, приведён в гайде по настройке сервера Minecraft.
Поиск ресурсоемких сущностей и чанков
Высокий процент в секции Entity tick указывает на избыточное количество сущностей. Быстрый способ подтвердить гипотезу - команда /spark healthreport. Она выводит сводку: общее количество сущностей, распределение по типам, количество загруженных чанков. Если на сервере с 10 игроками обнаружено 5000 мобов в одном чанке - причина лагов найдена.
Для устранения: определите координаты проблемного чанка через /spark tps (показывает TPS по отдельным мирам и регионам). Телепортируйтесь на место и выполните /kill @e[type=minecraft:zombie,distance=..50] - это удалит зомби в радиусе 50 блоков. Перед массовым удалением сущностей сделайте резервную копию мира. Для предотвращения повторения настройте лимиты в paper.yml: параметр spawn-limits ограничивает количество мобов каждого типа, despawn-ranges управляет дистанцией исчезновения сущностей.
Секция Chunk tick с высоким процентом сигнализирует о проблемах с чанками: слишком много загруженных чанков на игрока, активная генерация или массивные редстоун-схемы. Параметр view-distance в server.properties определяет радиус прогрузки чанков вокруг игрока. Уменьшение с 10 до 7 снижает нагрузку на 30-40% без заметного ухудшения игрового опыта. Для версий 1.21+ используйте no-tick-view-distance - чанки за пределами этого радиуса загружены, но не обрабатывают сущности и редстоун.
Пошаговые сценарии решения типовых проблем
Три кейса ниже покрывают 80% обращений администраторов по проблемам производительности. Каждый сценарий включает симптомы, метод диагностики и конкретные шаги с командами и параметрами конфигурации.
Кейс 1: TPS падает при онлайне больше 10 игроков
Симптомы. При 5-8 игроках TPS стабильно 20. При подключении 12-15 человек TPS падает до 14-16. После отключения части игроков восстанавливается до 20 в течение минуты.
Диагностика. Запустите профилировщик при высокой нагрузке: /spark profiler start --timeout 600 (автоостановка через 10 минут). В отчёте проверьте секцию Player tick и плоский список плагинов. Высокий процент у плагинов, работающих с игроками (античиты, плагины на права, визуальные эффекты) - индикатор проблемы.
Решение. Первое - настройте view-distance в server.properties. Значение 6-7 достаточно для комфортной игры и радикально снижает количество загруженных чанков на игрока. Второе - проверьте конфигурацию плагинов: отключите избыточные проверки (например, сканирование инвентаря каждую секунду), увеличьте интервалы автосохранения. Третье - используйте ядро Paper с включёнными оптимизациями: use-faster-eigencraft-redstone и per-player-mob-spawns в paper.yml распределяют нагрузку равномернее.
Кейс 2: Лаги из-за автоматических ферм и механизмов
Симптомы. TPS проседает, когда игроки находятся рядом с определёнными базами или фермами. При телепортации в другие регионы TPS восстанавливается. В чате игроки жалуются на лаги именно в «промышленных» зонах.
Диагностика. Выполните /spark tps - команда покажет TPS по мирам и регионам. Найдите мир/регион с аномально низким TPS. Запустите профилировщик и проверьте секции Tile entity tick (воронки, печки, раздатчики) и Chunk tick. Высокий процент в этих секциях подтверждает гипотезу.
Решение. В paper.yml измените redstone-implementation на ALTERNATE - это снижает нагрузку от редстоун-схем на 30-50% ценой незначительного изменения порядка активации компонентов. Установите hopper.disable-move-event в true - отключает вызов события при перемещении предметов в воронках. Для критичных ферм оптимизируйте конструкцию: замените цепочки воронок на водяные потоки с одной воронкой-приёмником, используйте компостеры вместо выбрасывания предметов на землю. Плагин Chunky поможет предварительно сгенерировать мир, чтобы генерация новых чанков не накладывалась на нагрузку от механизмов.
Кейс 3: Просадки при исследовании новых территорий
Симптомы. TPS резко падает, когда один или несколько игроков быстро перемещаются по неисследованным территориям (полёт на элитрах, бег с большой скоростью). После остановки TPS восстанавливается за 10-30 секунд.
Диагностика. В отчёте Spark высокая доля Chunk generation или Chunk provider tick. Дополнительный признак - сообщения в консоли сервера о том, что поток генерации чанков отстаёт.
Решение. Предварительно сгенерируйте мир. Плагин Chunky выполняет эту задачу: /chunky radius 5000 сгенерирует чанки в радиусе 5000 блоков от спавна. Запускайте генерацию в непиковые часы - процесс ресурсоёмкий. В paper.yml включите use-async-chunks (асинхронная загрузка чанков снижает влияние на основной поток) и настройте max-auto-save-chunks-per-tick (увеличьте с 6 до 12-24 для ускорения сохранения). Выделите серверу достаточно оперативной памяти - для мира с радиусом 5000 блоков рекомендуется 4-6 ГБ сверх базовых потребностей. Подробнее о выборе хостинга и настройке ресурсов - в разделе «Выбор хостинга» руководства по профилированию и устранению лагов.
Настройка постоянного мониторинга и алертов
Реактивное профилирование решает проблему постфактум. Проактивный мониторинг предупреждает о падении TPS до того, как игроки начнут жаловаться. Spark поддерживает оба режима, и настройка фонового наблюдения с алертами занимает 5 минут.
Фоновый мониторинг с Spark
Запустите фоновый мониторинг: /spark monitor start --period 30. Параметр --period задаёт интервал снятия показаний в секундах. Значение 30 оптимально: достаточно часто для обнаружения проблем, но не создаёт измеримой нагрузки. Мониторинг продолжает работать после перезагрузки сервера - Spark автоматически возобновляет сбор данных.
Просмотр текущих показателей: /spark monitor show. Команда выводит график TPS и MSPT за последние несколько минут прямо в чате. Для экспорта данных используйте /spark monitor export - Spark сформирует ссылку на детальный отчёт за весь период мониторинга. Эти данные полезны для анализа трендов: вы увидите, в какие часы нагрузка максимальна, и сможете планировать профилактические работы.
Настройка алертов в Discord при падении TPS
Создайте вебхук в Discord: Настройки сервера → Интеграции → Вебхуки → Новый вебхук. Скопируйте URL вебхука. Привяжите его к Spark: /spark monitor discord webhook https://discord.com/api/webhooks/....
Настройте условие отправки алерта: /spark monitor discord alert tps below 18 --period 60. Эта команда отправляет сообщение в Discord, если средний TPS за последние 60 секунд опускается ниже 18. Сообщение содержит: текущий TPS, MSPT, топ-3 плагинов по потреблению времени тика и ссылку на детальный отчёт. Дополнительные условия: --threshold-mspt 60 для алерта по MSPT, --cooldown 300 для ограничения частоты сообщений (не чаще раза в 5 минут).
Тонкая настройка сервера на основе данных профилирования
Данные Spark - не только инструмент для разовых расследований. Они указывают, какие параметры конфигурации нужно изменить для долгосрочной стабильности. Слепое копирование конфигов из интернета без привязки к реальным метрикам вашего сервера часто ухудшает ситуацию. Настройка должна опираться на конкретные цифры из отчётов.
Оптимизация сущностей и спавна мобов
Если в отчётах Spark стабильно высокий процент Entity tick (более 20-25%), пересмотрите параметры спавна и деспавна мобов. В spigot.yml параметр mob-spawn-range определяет радиус вокруг игрока, в котором спавнятся мобы. Значение по умолчанию - 8 чанков. Уменьшение до 4-5 снижает количество активных мобов без заметного влияния на игровой процесс.
В paper.yml включите per-player-mob-spawns: true. По умолчанию мобы спавнятся глобально для всего сервера, что создаёт неравномерную нагрузку. Этот параметр распределяет спавн между игроками: каждый игрок получает свою квоту мобов, общее количество остаётся под контролем. Параметр despawn-ranges в том же файле управляет дистанцией, на которой мобы исчезают: уменьшение soft с 32 до 24 блоков ускоряет очистку неиспользуемых сущностей.
Настройка чанков и ввода-вывода
Высокий Chunk tick или Chunk loading в отчётах Spark требует корректировки работы с чанками. В server.properties параметр view-distance управляет радиусом прогрузки чанков вокруг игрока. Каждый дополнительный чанк в радиусе добавляет десятки обрабатываемых сущностей и блоков. Для серверов с онлайном 20+ игроков значение 6-7 - разумный компромисс между производительностью и дальностью обзора.
В paper.yml параметр max-auto-save-chunks-per-tick ограничивает количество чанков, сохраняемых на диск за один тик. Значение по умолчанию - 6. Если в отчёте Spark видны периодические всплески MSPT, совпадающие с автосохранением, увеличьте параметр до 12-24. Сохранение завершится быстрее, хотя и создаст кратковременную нагрузку на диск. Включите use-async-chunks: true - асинхронная загрузка чанков снижает влияние на основной поток обработки тиков. Для серверов на SSD это безопасно, для HDD - тестируйте осторожно, возможна фрагментация данных.
Системный подход к диагностике и оптимизации превращает профилирование из разовой акции в постоянный процесс улучшения. Запускайте Spark раз в неделю в часы пик, сравнивайте отчёты, отслеживайте тренды. Сервер, который работает стабильно сегодня, может начать лагать завтра после установки нового плагина или строительства масштабной фермы. Мониторинг и профилирование - ваши инструменты для упреждающего реагирования.