Minecraft-сервер лагает: как правильно исправить «Can't keep up» и тайм-аут Watchdog

Три самые частые лаг-сообщения в логе Minecraft означают не одно и то же: Can't keep up! Is the server overloaded? значит, что твой сервер продолжает работать, но не успевает. A single server tick took 60.00 seconds значит, что встроенный аварийный стоп жёстко завершил его. Exception in server tick loop значит, что конкретная программная ошибка сломала игровой цикл. Если относиться ко всем трём одинаково, обычно чинишь не то.

Как различать эти три сообщения

Minecraft рассчитывает игровой мир 20 раз в секунду. Один такой проход называется тиком и должен длиться максимум 50 миллисекунд. Любой лаг, который ты ощущаешь, — это отклонение от этого одного числа.

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

Самое важное действие: при сообщениях Watchdog читать выше

Watchdog-kill — это симптом, а не причина. Он говорит только одно: что-то заблокировало серверный поток дольше разрешённого. Что именно его заблокировало, написано в другом месте.

Есть два случая, и они ведут к совершенно разным действиям:

Случай 1 — Watchdog сработал первым. Перед строкой Watchdog видна обычная работа сервера. Тогда время тика действительно и есть сообщение: что-то заморозило сервер во время работы.

Случай 2 — Watchdog сработал после. Перед строкой Watchdog уже есть Stopping server или Preparing crash report. Тогда сервер уже был мёртв или находился в процессе выключения, а Watchdog лишь убрал зависшее завершение.

Второй случай — не редкость. В одном обращении в поддержку от 22 августа 2026 года серверный поток упал в 13:20:15, начал чистое Stopping server — и только 60 секунд спустя сработал Watchdog. Если назвать причиной длительность тика, владелец пойдёт мимо настоящего сообщения об ошибке, которое стояло на минуту выше. Именно поэтому наш анализ консоли сознательно оценивает срабатывание Watchdog последним: если в том же участке лога есть более конкретная сигнатура, ты увидишь её объяснение, а не «один тик был медленным».

Шаг за шагом к причине

1. Проверь историю TPS в панели

Открой свой сервер в панели. В разделе «Производительность (последние 24 ч)» ты увидишь график TPS; измерение выполняется примерно каждые пять минут, пока сервер работает. Форма кривой уже многое говорит:

• Резкое падение в конкретное время → событие. Сверь время с логом: генерация мира, backup, игрок в неизведанной местности, задача плагина.
• Постоянно низкие значения → структурная перегрузка. Здесь помогает не перезапуск, а разгрузка.
• Пилообразный график → типично для давления на память: сервер работает, garbage collection прерывает, и это повторяется.

Если значения остаются низкими в течение достаточно долгого окна, панель сама покажет предупреждение «TPS постоянно низкий».

2. Измерь MSPT — одного TPS недостаточно

Введи в консоли /spark tps. Команда выдаёт два числа, и второе важнее:

• TPS — тики в секунду, максимум 20.
• MSPT — миллисекунды на тик. Всё до 50 мс считается здоровым.

Почему MSPT? Bukkit, Spigot и Paper замедляют серверные процессы, чтобы избежать падения. Поэтому индикатор может показывать ровные 20 TPS, хотя сервер в реальности уже работает на пределе. Значение MSPT 45 мс значит: тебе достаточно одной моб-фермы до заметных лагов, даже если TPS всё ещё выглядит идеально.

В Paper начиная с 1.21 spark уже встроен, ничего устанавливать не нужно.

3. Найди виновника через профилировщик

Не угадывай, какой плагин виноват — измерь:

/spark profiler start --timeout 120

Воспроизведи за эти две минуты ситуацию, в которой лагает. После этого открой ссылку на результат, которую выдаст сервер. Отчёт показывает, куда уходит время тика, отсортированное по доле времени: конкретная Mod, задача плагина, загрузка chunk, обработка entity или garbage collection.

Именно здесь этот гайд расходится с советом «купи больше RAM». Профилировщик отвечает на вопрос, на который таблица рекомендаций ответить не может: что именно тратит время на твоём сервере?

4. Разгрузи точечно

То, что показывает профилировщик, определяет действие:

Последний пункт важен: RAM исправляет только проблему с памятью. Если redstone-часы съедают время тика, более дорогой тариф не сделает сервер быстрее. Сколько памяти подходит под твоё число игроков и размер modpack, посчитает наш калькулятор RAM для Minecraft.

5. max-tick-time — исключение, а не решение

Значение находится в server.properties и задаёт, с какой длительности тика вмешивается Watchdog. Стандарт — 60000 миллисекунд, то есть 60 секунд. Если значение превышено, сервер завершает сам себя.

Многие инструкции в интернете на этом месте советуют отключить Watchdog через -1. Не делай это стандартным решением. Watchdog — единственный встроенный механизм, который вообще замечает настоящий deadlock. С -1 мёртвый сервер часами висит на порту: игроки не могут зайти, в логе ничего не объясняет почему, и никто не получает предупреждение. Ты убрал индикатор, а не проблему.

Есть ровно одно хорошее основание для увеличения: известная операция законно длится долго. Классический случай — первый запуск большого modpack, когда генерация мира и инициализация Mod вместе проводят в одном тике больше минуты. Тогда значение, например 180000 (три минуты), допустимо — временно и с намерением вернуть его после первого успешного запуска.

Если в логе есть Exception in server tick loop

Это самое простое из трёх сообщений, потому что оно приносит причину с собой. Прямо под ним или несколькими строками ниже есть строка Caused by: — там указана настоящая ошибка, чаще всего с названием ответственной Mod или плагина.

Порядок действий:

1. Найти Caused by: и записать имя класса.
2. Если в нём есть название Mod или плагина, виновник назван.
3. Если ошибка появилась после изменения (новая Mod, update, новый мир), сначала откатить это изменение.
4. Если ошибка остаётся неясной, отправить в поддержку весь участок целиком — со временем.

Анализ консоли твоего сервера распознаёт эти строки автоматически и объясняет каждое найденное сообщение простым текстом, включая частоту. Если у тебя только кусок лога откуда-то ещё, можешь вставить его в наш Crash-Report-Analyzer — даже без сервера у нас.

Что мы автоматически берём на себя

• Измерение производительности без действий с твоей стороны. TPS собирается примерно каждые пять минут и показывается в панели за 24 часа — для этого тебе не нужно устанавливать плагин.
• Предупреждение при длительной слабой производительности. Если производительность остаётся низкой в надёжном временном окне, ты получишь подсказку, а не будешь обязан заметить это сам.
• Объяснённые строки лога. Найденные сообщения получают причину и решение простым текстом, на твоём языке — а там, где есть подходящий гайд, ещё и ссылку на него.
• Правило «симптом перед причиной». Если в том же участке лога есть более выразительное сообщение об ошибке, чем Watchdog-kill, мы показываем его.

Troubleshooting: симптом, проверка, решение

FAQ

С какого значения TPS игроки что-то замечают?

Примерно до 18 TPS в игре ничего не бросается в глаза. Ниже 15 становится заметно туго. Но не полагайся только на это: дополнительно проверяй MSPT, потому что TPS-limiter может показывать здоровое число, пока сервер уже работает на пределе.

Помогает ли больше RAM против лагов?

Только если память действительно является узким местом. Если профилировщик показывает garbage collection как главный пункт, да. Если он показывает redstone-часы или моб-ферму, больше RAM ничего не изменит. Сначала измерь, потом покупай.

Стоит ли отключать Watchdog?

Нет, не навсегда. -1 забирает у тебя единственное автоматическое распознавание настоящего зависания. Временное увеличение max-tick-time для известной медленной операции вроде первого запуска modpack допустимо — потом вернуть обратно.

Почему сообщение Watchdog стоит после «Stopping server»?

Потому что сервер уже выключался и завис в процессе. Watchdog тогда убрал зависшее завершение, а не убил работающий сервер. Причина стоит перед Stopping server.

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

Против текущего отставания — да, против причины — нет. Если лаг возвращается вскоре после каждого перезапуска, он структурный — тогда дальше поможет только измерение.

В чём разница между view-distance и simulation-distance?

view-distance определяет, как далеко игроки видят; simulation-distance определяет, как далеко мир реально рассчитывается. По умолчанию оба значения равны 10 chunks. Поскольку вычислительное время тратят только симулируемые chunks, снижение simulation-distance даёт больше разгрузки при меньшей видимой потере.

Если лаги продолжаются

Перед обращением в поддержку собери три вещи: точное время последнего инцидента, ссылку на отчёт spark-profiler и информацию, какие Mods или плагины были добавлены последними. Так можно точечно проверить нужный участок лога, а не проводить общую оптимизацию вслепую.

Общие настройки для всех игр — планы перезапуска, выбор тарифа, сеть — ты найдёшь в гайде улучшить производительность Gameserver. Как чисто устанавливать и удалять Mods и плагины, описано в установить Minecraft-Mods и плагины.

Хочешь сервер, где измерение TPS, объяснение логов и предупреждения уже включены без лишней работы? На странице арендовать Minecraft-сервер ты найдёшь подходящие тарифы.

Источники и стенд проверки

• max-tick-time, tickrate и дистанции: PaperMC — server.properties. Документирует стандартное значение 60000 миллисекунд, принудительное завершение при превышении, отключение через -1, а также стандартные значения 10 для view-distance и simulation-distance.
• spark встроен в Paper: PaperMC — Profiling. Начиная с Paper 1.21 отдельная загрузка не нужна.
• MSPT перед TPS: spark — TPS and MSPT. Объясняет, почему TPS-limiter может показывать ровные 20, пока сервер в реальности работает медленнее.
• Команды профилировщика: spark — Command Usage. Источник для /spark profiler start --timeout <sekunden> и /spark profiler stop.

Стенд проверки: 24 августа 2026 года. Стандартные значения и команды могут меняться с новыми версиями сервера; при сомнениях проверь документацию производителя по ссылкам.