Если сервер лагает, первым делом нужно не гадать, а измерить: посмотреть TPS и MSPT, а затем снять профиль через spark, чтобы увидеть, что именно ест время тика. Timings, который советуют старые гайды, в актуальных ядрах больше не поддерживается — современный стандарт диагностики это spark.
TPS и MSPT: в чём разница и почему MSPT честнее
TPS (тики в секунду) — сколько раз в секунду сервер успевает обновить игровой мир, идеал — 20. MSPT (миллисекунды на тик) — сколько времени физически занимает один тик. Проблема TPS в том, что он показывает округлённое значение и долго держится на 20 даже когда сервер уже начинает буксовать — просадка становится видна только когда всё действительно плохо. MSPT показывает нагрузку раньше и точнее: если тик стабильно занимает 40-50 мс вместо целевых 50 мс на весь тик (то есть уже на грани), проблему видно заранее, до того как TPS вообще начнёт проседать.
Почему timings больше не годится
Timings был встроенным профилировщиком Spigot, но актуальные ядра либо не поддерживают его в полной мере, либо он даёт неполную и устаревшую картину по сравнению с современными инструментами. Полагаться на гайд с командой /timings в 2026 году — гарантированно смотреть не туда или получать неполные данные.
spark: как поставить и снять профиль
- Установи spark как плагин (для Paper/Spigot) или мод (для Fabric/Forge) — актуальную версию под своё ядро и версию игры
- Запусти профилирование командой /spark profiler start в консоли или игровом чате с правами администратора
- Дай серверу поработать под обычной нагрузкой несколько минут, желательно захватить момент, когда обычно случаются лаги
- Останови профиль командой /spark profiler stop — spark сгенерирует ссылку на подробный отчёт
- Открой отчёт в браузере и посмотри, какие методы и плагины съедают больше всего времени тика
Как читать отчёт spark
Отчёт spark показывает дерево вызовов с процентом времени, которое занял каждый участок кода за время профилирования. Смотреть нужно на верхние по нагрузке ветки: если львиная доля времени уходит в конкретный плагин или мод — вот твой подозреваемый. Если основная нагрузка размазана по генерации чанков или обработке сущностей — проблема не в конкретном плагине, а в настройках мира или в том, что происходит на карте прямо сейчас.
Типовые причины просадок TPS
- Слишком большая дальность прорисовки или симуляции — сервер тикает и рендерит больше чанков, чем нужно
- Мобофермы и скопления сущностей — десятки и сотни мобов или предметов в одной точке карты серьёзно нагружают тик
- Хопперы — при большом количестве одновременно работающих хопперов сервер тратит на них заметную часть тика
- Редстоун-машины, особенно с быстрыми тактовыми генераторами — держат сервер в постоянной работе даже без игроков рядом
- Тяжёлые или плохо оптимизированные плагины — находятся именно через spark, а не на глаз
- Генерация новых чанков при исследовании — заход в новую, ранее не сгенерированную область карты создаёт кратковременный, но заметный всплеск нагрузки
Что крутить в server.properties и paper.yml
После того как spark показал источник проблемы, есть конкретные рычаги. Уменьшение view-distance и simulation-distance в server.properties снижает нагрузку почти всегда, но урезает игрокам обзор и дальность, на которой мир продолжает жить без них рядом. В paper.yml (или spigot.yml на Spigot) можно снизить дальность активации и отслеживания сущностей — это уменьшает нагрузку от мобов и предметов, но может сделать их поведение чуть менее отзывчивым на расстоянии. Ограничение скорости обработки хопперов снижает нагрузку от автоматических ферм ценой чуть более медленной сортировки предметов. За каждую оптимизацию платишь чем-то в игровом опыте — задача не выжать максимум TPS любой ценой, а найти баланс, комфортный именно твоим игрокам.
Что почитать дальше: Средняя нагрузка: что означают три числа · Процессор загружен на 100 процентов.
Частые вопросы
TPS 19 — это плохо? Не обязательно критично, но это сигнал заглянуть в MSPT и снять профиль spark, прежде чем состояние ухудшится дальше.
Нужно ли ставить spark постоянно или только при проблемах? Плагин лёгкий и не мешает работать в фоне, так что держать его установленным для диагностики по требованию — разумная практика.
