Войти Добавить свой сервер

ГайдДля владельцев серверов

Лаги на сервере Minecraft: сначала найдите причину, потом чините

Как отличить лаги тиков от сетевых и низкого FPS, прочитать профиль spark, починить сущности, чанки и редстоун и спланировать перезапуски по нашим данным.

Редакция ServerList Опубликовано 10 мин чтения
MSPT, профайлер sparkБюджет 50 мс50 MSСкачок

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

Большинство «гайдов по оптимизации» пропускают этот шаг и выдают список настроек. Часть из них помогает, несколько ухудшают игру, и ни одна не починит проблему, которую ещё не нашли. Это руководство начинается с диагностики.

Три вида лагов (тики сервера, сеть, клиент)

ВидЧто замечают игрокиКак подтвердитьКто может исправить
Лаг тиков сервераСломанные блоки появляются снова, мобы замирают, а потом прыгают, двери открываются с опозданием, и все видят это в один момент/spark tps, /mspt на Paper или ванильная /tick queryВы, на сервере
Сетевой лагОткаты назад (rubber-banding) и запоздалые удары у части игроков, пока у других всё в порядкеПолоски соединения в списке игроков, команда /ping, если её добавляет плагин, страница статистики вашей карточкиВы (расположение, хостинг, защита) или маршрут игрока
Лаг клиентаНизкая частота кадров, подёргивания при повороте, затронут только один игрокСчётчик FPS на экране F3Игрок (дальность прорисовки, настройки графики, мод для производительности)

Небольшое занудное отступление о цифрах, потому что оно объясняет, почему TPS обманывает. Сервер стремится к 20 тикам в секунду, так что на каждый тик отпущено 50 мс. TPS никогда не поднимается выше 20, поэтому сервер, которому нужно 10 мс на тик, и сервер, которому нужно 48 мс, показывают одинаковые 20,0 TPS. Первый выдержит нагрузку, в несколько раз большую нынешней, а второму до лагов хватит одной фермы с воронками. MSPT (миллисекунды на тик) показывает этот запас, поэтому следите за MSPT, а не за TPS.

Измеряйте, прежде чем что-то менять

  1. Выберите правильный час. Лаги, которые бывают в пик, не измерить в пять утра. Четыре самых загруженных часа по всем серверам нашего списка: с до в вашем часовом поясе, а публичная страница статистики вашей карточки показывает ваши собственные самые загруженные часы.
  2. Запустите /spark tps. Команда показывает TPS за период от 5 секунд до 15 минут и длительность тиков: минимум, медиану, 95-й процентиль и максимум. Медиана заметно ниже 50 мс при 95-м процентиле выше этого значения означает всплески, а не постоянную перегрузку. Команда /mspt на Paper даёт краткую версию.
  3. Запустите /spark health. Она добавляет загрузку процессора, памяти и диска, так что сразу видно, не исчерпала ли сама машина какой-то ресурс.
  4. Прочитайте консоль. Ванильное предупреждение Can't keep up! Is the server overloaded? Running 2034ms or 40 ticks behind (консоль сервера всегда пишет по-английски) означает, что сервер отстал и перескочил вперёд, чтобы догнать. Одно такое в день ничего не значит. Одно в минуту уже проблема.
  5. Запишите исходные цифры: время, игроков онлайн, медиану и 95-й процентиль MSPT и то, где находились игроки (новая территория, большая ферма, событие). Вы будете сравнивать с ними после каждого изменения.

На сервере без spark ванильная команда /tick query (Java Edition 1.20.3 и новее, уровень прав 3) показывает среднее время тика и его процентили.

Игроки на всех серверах списка по часам сутокПоследние 28 дней
Пик

Больше всего игроков в , около 17 845, меньше всего в . Разница между самым оживлённым и самым тихим часом: в 2,6 раза.

Замер: 19 окт. 2026, 23:55 UTCКак мы измеряем

Как читать профиль spark

Когда цифры говорят, что сервер медленный, профилировщик объясняет, почему. Документация PaperMC советует:

/spark profiler start --timeout 600

Команда десять минут снимает сэмплы со всех потоков и выдаёт ссылку на отчёт. Два варианта помогают при конкретных проблемах:

  • /spark profiler start --only-ticks-over 100 записывает только тики медленнее 100 мс, что отделяет короткие всплески лагов от обычного фона.
  • /spark tickmonitor --threshold-tick 100 выводит строку каждый раз, когда тик длится дольше 100 мс, так что всплески можно сопоставить с тем, что происходило в игре.

Профиль нужно снимать, пока лаг происходит. Профиль тихого сервера в 05:00 ничего не скажет о лагах в 18:00.

В просмотрщике откройте поток сервера и идите вниз за самым большим процентом. Вы ищете ветку, куда уходит время:

  • Обработка сущностей (entity ticking), часто с ИИ мобов или поиском пути крестьян внутри, указывает на мобов (следующий раздел).
  • Блочные сущности (block entities), с воронками высоко в списке, указывают на цепочки воронок и системы хранения.
  • Работа с чанками (генерация, загрузка, сохранение) указывает на игроков, исследующих новую местность.
  • Название плагина в дереве вызовов или высоко в разбивке по плагинам указывает на этот плагин. Отметьте, чем он занимался (обработчик событий, плановая задача, запрос к базе данных), прежде чем винить его, потому что тот же плагин может работать нормально с другой настройкой.

Spark записывает и сборку мусора. Частые паузы в сотни миллисекунд указывают на нехватку памяти, и /spark gc показывает её во времени. Снимите профиль один раз и тогда, когда сервер в порядке, чтобы знать, как выглядит норма на вашей конфигурации.

Обычные подозреваемые (сущности, генерация чанков, редстоун, плагины, сборка мусора)

Сущности

Тикают фермы мобов, торговые залы с крестьянами, груды выброшенных предметов, системы вагонеток и украшения из стоек для брони. На Paper /paper entity list показывает тикающие сущности по типам, а фильтр вроде /paper entity list minecraft:villager сужает вывод, чтобы найти, где они скапливаются. /paper mobcaps показывает, насколько заполнены лимиты мобов, а /paper chunkinfo сколько чанков загружено и тикает. Исправляют это лимитами, а не запретами: потолок сущностей на чанк, правила для ферм, с которыми согласны ваши игроки, и разговор с тем, кто построил зал на 400 крестьян.

Генерация чанков

Генерация нового чанка относится к самым дорогим задачам сервера, а игроки с элитрами могут требовать их десятками в минуту. Сгенерируйте мир заранее один раз плагином вроде Chunky (/chunky radius 5000, затем /chunky start) в тихие часы и поставьте соответствующую границу мира командой /worldborder set 10000. Граница принимает диаметр, а радиус в Chunky составляет его половину, так что эти два числа описывают один и тот же квадрат. После этого исследование лишь подгружает чанки с диска, что намного дешевле.

Редстоун и воронки

Быстрые редстоун-часы и длинные цепочки воронок накапливают нагрузку. У Paper есть два рычага в config/paper-world-defaults.yml. misc.redstone-implementation: ALTERNATE_CURRENT заменяет реализацию редстоун-пыли на более быструю. hopper.disable-move-event: true удешевляет воронки, но ломает плагины, которые полагаются на это событие, например некоторые плагины защиты и фильтров воронок, поэтому сначала проверьте. hopper.cooldown-when-full уже включён по умолчанию.

Плагины

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

Сборка мусора

Если spark показывает долгие или частые паузы сборки, сначала проверьте память: не мал ли -Xmx для мира и плагинов и стоит ли -Xms на то же значение? Флаги, которые рекомендует PaperMC, служат надёжной основой по умолчанию. Больше памяти помогает, только когда проблема в сборке мусора, а на общем хостинге выделение всей памяти оставляет без неё операционную систему.

Исправления, которые работают

Когда причина известна, вот изменения, которые обычно окупаются, примерно в том порядке, в каком мы бы их пробовали:

ИсправлениеПомогает приЦена для игроков
Снизьте simulation-distance в server.properties (по умолчанию 10) до 6 или 8, а view-distance оставьте вышеОбработка сущностей и блоков вокруг каждого игрокаФермы и посевы перестают работать раньше, когда игроки отходят
Сгенерируйте мир заранее и поставьте границуВсплески при генерации чанковГраница мира
Ограничьте сущности на чанк или введите правила для фермОбработка сущностейФермы меньше
Редстоун ALTERNATE_CURRENTПостройки с большим количеством редстоунаРедкие отличия в тайминге редстоуна
Снизьте entity-activation-range в spigot.ymlМобы вдали от игроковДалёкие мобы действуют медленнее
Исправьте, перенастройте или замените плагин, который назвал sparkНагрузка от плагинаЗависит от плагина
Обновитесь до последней сборки серверного ПОИсправленные ошибки и новые оптимизацииПерезапуск

Изменение simulation-distance значит больше, чем кажется. Вокруг каждого игрока сервер обрабатывает примерно квадрат чанков, поэтому переход с 10 на 6 сжимает его с примерно 21 на 21 чанк до 13 на 13, то есть с около 441 чанка до около 169, при этом игроки по-прежнему видят так далеко, как позволяет view-distance.

Часть популярных советов не помогает. Плагины, которые каждые несколько минут стирают все выброшенные предметы, лечат симптом и раздражают игроков. «Оптимизирующие» плагины, обещающие более высокий TPS и не говорящие, что именно они меняют, стоит проверить профилем до и после. А перезапуск каждые два часа прячет проблемы вместо того, чтобы их находить.

Сетевой лаг, каким он виден снаружи

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

Зато мы видим сеть. Публичная страница статистики вашей карточки (/server/your-server/stats) показывает три вещи, которые стоит прочитать:

  • Время ответа, то есть сколько сервер отвечал нашему мониторингу, с медианой, обычным диапазоном и графиком. Уровень задаётся в основном расстоянием до нашего пингера в Западной Европе, поэтому сервер в США не покажет там 10 мс, если только с ближнего узла (edge) не отвечает защитная сеть. Смотрите на форму во времени, а не на значение.
  • Всплески выше обычного диапазона. Если ответы заметно выходят за обычный диапазон только в ваши загруженные часы, в это время машина или её сетевой канал перегружены. Если диапазон широкий в любое время суток, подозревайте маршрут или сеть хостинга.
  • Журнал сбоев. Короткие провалы означают перезапуски или падения. При длинных провалах стоит заглянуть на страницу статуса хостинга и в отчёты о крашах.

Со стороны игроков попросите пострадавших прислать трассировку до вашего адреса (tracert в Windows, traceroute в macOS и Linux) и указать регион. Если лагают все в одной стране, а больше никто, виноват маршрут, и перенос сервера или защитная сеть с ближним узлом помогут сильнее любой настройки. У игроков, которые вообще не могут подключиться, другие проблемы, их разбирает наше руководство по ошибкам подключения.

Когда перезапускать, а когда нет

Перезапуски не бесплатны. Всех, кто онлайн, выкидывает с сервера, а игрок, которого выкинуло посреди боя воскресным вечером, это запомнит. Наши данные о сбоях показывают, как владельцы на самом деле их планируют.

За 30 дней по 16 октября 2026 года 90 карточек нашего списка были доступны для игры не меньше 90% времени. У 58 из них был хотя бы один сбой (мы считаем сбоем три пинга подряд и больше без ответа, говорящего о доступности для игры), а всего их было 515. Если считать от первого пропущенного пинга до последнего, половина сбоев закончилась меньше чем за пять минут, а самая длинная десятая часть тянулась больше двух часов. 375 из 515 (73%) длились 15 минут или меньше, то есть столько, сколько занимает перезапуск или падение с перезагрузкой.

Когда начинались эти короткие сбои? Один час выделяется: 04:00 UTC, на него приходится 39 из 375, типичная картина плановых ночных перезапусков. Вне этого часа они распределены по суткам довольно равномерно. 64 из 375 (17%) начались между 14:00 и 18:00 UTC, в четыре самых загруженных часа нашего списка, и это примерно та доля, которую можно ожидать, если время перезапусков выбирать наугад.

Измерено
19 %Короткие сбои, начавшиеся в четыре самых загруженных часа списка, последние 30 дней

Замер: 19 окт. 2026, 22:52 UTCКак мы измеряем

Сейчас, за последние 30 дней: карточек с доступностью 90% и выше 83, сбоев на них 473, медианная длительность сбоя в минутах 5 мин, а 70 % сбоев длились 15 минут или меньше. Чаще всего короткие сбои начинаются в по вашему часовому поясу, а самый тихий час списка: .

Что из этого следует:

  1. Перезапускайте в свой собственный тихий час, а не в круглое время. Его показывает тепловая карта на вашей странице статистики, а отчёт о том, когда на серверах больше всего игроков, показывает, как он различается по регионам. Если ваши игроки живут в разных часовых поясах, выберите самую низкую точку вашей кривой, а не полночь.
  2. Объявляйте о нём отсчётом в чате и делайте его коротким.
  3. Перезапускайте по причине. Обновления, утечка памяти, которую вы отслеживаете, изменение конфигурации, которое этого требует. Ежедневный перезапуск, который ничего не исправляет, всё равно каждый день кого-то выкидывает.
  4. Найдите утечку, а не прячьте её. Если память растёт до перезапуска, /spark heapsummary покажет, что её заполняет.

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

Когда обновлять железо

Обновляйте, когда так говорит профиль. Признаки:

  • MSPT в пик держится выше примерно 40 мс после того, как вы разобрались с подозреваемыми выше.
  • Профиль показывает, что время размазано по обычной ванильной работе (сущности, чанки, обновления блоков), и единственного виновника не осталось.
  • На VPS top показывает рост CPU steal (значение st) в загруженные часы, а это значит, что соседи используют ядра, за которые платите вы.

Тогда покупайте в первую очередь скорость одного ядра, потому что цикл тиков работает на одном ядре. Больше оперативной памяти исправляет только проблемы с памятью. Дальше ответ в том, чтобы разделить нагрузку: несколько серверов за прокси Velocity или Folia для очень большого мира, оба варианта разобраны в нашем руководстве по серверному ПО. Вопросы, которые стоит задать до оплаты новой машины, есть в статье о выборе хостинга.