Minecraft-сервер рассчитывает мир тиками, 20 раз в секунду. Если тик длится слишком долго или заканчивается оперативная память, сервер пишет предупреждения в лог или в худшем случае аварийно завершает работу. Каждый раздел ниже объясняет одно из таких сообщений: как его узнать, насколько оно серьёзно и что ты можешь сделать. Сначала идут сообщения, после которых сервер падает или останавливается, затем предупреждения, при которых он продолжает работать.

Полное сообщение ты найдёшь в Консоль или в разделе Файлы в logs/latest.log, отчёты о сбоях лежат в папке crash-reports/. Всегда читай и строки перед ним: там часто видно, что затормозило сервер. Перед изменением файлов конфигурации или мира создай резервную копию в разделе Резервные копии.

Сервер не отвечает: завершение работы по Watchdog

Как выглядит сообщение:

The server has not responded for 25 seconds! Creating thread dump
A single server tick took <Seconds> seconds

Что за этим стоит: Watchdog — это «сторож», который проверяет, что сервер всё ещё работает. Если один тик длится слишком долго, сервер считается зависшим, и Watchdog завершает его работу. До этого момента Paper пишет промежуточные сообщения вроде «has not responded for 25 seconds» вместе с дампом потоков — снимком того, чем сейчас занят сервер. Частые причины — нехватка памяти или тяжёлый плагин либо тяжёлый мод.

Как это исправить:

  1. Прочитай в logs/latest.log строки перед первым сообщением Watchdog. Если там уже есть другая ошибка или Stopping server, то именно эта ошибка является настоящей причиной, а Watchdog — лишь следствием.
  2. Посмотри в дампе потоков самые верхние строки под Server thread. Название плагина или мода там покажет, чем сервер был занят в последний момент.
  3. Проверь оперативную память. Если в логе также появляется OutOfMemoryError, её не хватает (разделы ниже).
  4. Обнови или удали найденный плагин в разделе Плагины либо мод в разделе Моды и перезапусти сервер.

Подробнее: Как правильно устранить «Can't keep up» и таймаут Watchdog

Оперативная память исчерпана: Java heap space

Как выглядит сообщение:

java.lang.OutOfMemoryError: Java heap space
Exception in thread "<Thread>" java.lang.OutOfMemoryError: Java heap space

Что за этим стоит: Java управляет оперативной памятью сервера в области, которая называется heap (куча). Она переполнилась: для текущей нагрузки памяти не хватило. Из-за этого сервер обычно падает или начинает работать нестабильно. Типичные «пожиратели» памяти — множество загруженных чанков, большие модпаки, много мобов и предметов, а также плагины с большими объёмами данных.

Как это исправить:

  1. Перезапусти сервер, чтобы он снова работал стабильно.
  2. Выясни, сколько оперативной памяти действительно нужно твоей конфигурации. Подробнее: Как рассчитать потребность Minecraft в оперативной памяти
  3. Если твоего тарифа не хватает, выбери в разделе Настройки и подписка → Тариф вариант с большим объёмом ОЗУ.
  4. А пока снизь нагрузку, например дальность прорисовки view-distance в server.properties.

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

Сервер упал: отчёт о сбое сохранён

Как выглядит сообщение:

This crash report has been saved to: crash-reports/crash-<Date>_<Time>-server.txt

Что за этим стоит: Работа сервера была завершена из-за серьёзной ошибки, и он записал отчёт о сбое. Само сообщение лишь указывает, где лежит этот отчёт. Настоящая причина, например мод, плагин, мир или нехватка оперативной памяти, указана в файле.

Как это исправить:

  1. Открой в разделе Файлы папку crash-reports/ и в ней указанный файл. В его названии содержатся дата и время сбоя.
  2. Прочитай первый раздел: после Description: стоит краткое описание, ниже — строка с ошибкой и стек вызовов (stacktrace), то есть список участков программы, которые привели к ошибке.
  3. Указанное там название мода или плагина — виновник. Обнови его в разделе Моды либо Плагины или удали.
  4. Если там указан OutOfMemoryError, оперативной памяти не хватает. Выбери больше ОЗУ в разделе Настройки и подписка → Тариф.
  5. Запусти сервер и следи за Консоль, пока он не запустится полностью.

Полезно знать: Отчёты о сбоях не удаляются сами. Удаляй прочитанные отчёты, чтобы в следующий раз сразу найти новый. Для серверов с модами: Ошибки модов на серверах Forge, NeoForge и Fabric

Ошибка в главном игровом цикле

Как выглядит сообщение:

Exception in server tick loop
Caused by: java.lang.<ErrorType>: <Details>

Что за этим стоит: Главный цикл тик за тиком рассчитывает мир. Исключение (exception), то есть программная ошибка, дошло до этого цикла и нарушило его работу. После этого сервер обычно падает и записывает отчёт о сбое. Настоящая причина почти всегда указана в следующей сразу за этим строке Caused by.

Как это исправить:

  1. Найди сообщение в logs/latest.log или в самом свежем отчёте в crash-reports/.
  2. Прочитай строку Caused by сразу под ним. Если их несколько, самая нижняя обычно ведёт к корню проблемы.
  3. Строки с at … ниже содержат названия пакетов и файлов. По ним ты определишь, какой плагин или мод замешан.
  4. Обнови или удали его в разделе Плагины либо Моды и перезапусти сервер.

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

Подробнее: Как правильно устранить «Can't keep up» и таймаут Watchdog

Оперативная память на пределе: GC overhead limit exceeded

Как выглядит сообщение:

java.lang.OutOfMemoryError: GC overhead limit exceeded

Что за этим стоит: Java автоматически освобождает память, которая больше не нужна. Это называется сборкой мусора (Garbage Collection, сокращённо GC). Это сообщение означает: Java тратит почти всё время на уборку, а освободить удаётся совсем немного памяти. Heap, то есть оперативная память Java, практически заполнена. Сервер почти не отвечает или падает.

Как это исправить:

  1. Перезапусти сервер.
  2. Выясни, сколько оперативной памяти нужно твоей конфигурации. Подробнее: Как рассчитать потребность Minecraft в оперативной памяти
  3. Если твоего тарифа не хватает, выбери больше ОЗУ в разделе Настройки и подписка → Тариф.
  4. Уменьши нагрузку от чанков и сущностей: снизь дальность прорисовки view-distance в server.properties, сократи большие фермы животных и убери валяющиеся предметы.

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

Нельзя создать новый поток: unable to create native thread

Как выглядит сообщение:

java.lang.OutOfMemoryError: unable to create native thread

Что за этим стоит: Поток — это параллельная линия выполнения. Java хотела запустить ещё один и не смогла. Несмотря на OutOfMemoryError в названии, это не доказательство того, что heap Java переполнен. Чаще всего одновременно запущено слишком много потоков, достигнут предел процессов или не хватает памяти вне heap. Тогда сервер не может запускать новые задачи и становится нестабильным. Какой плагин или мод создаёт потоки, эта строка не показывает.

Как это исправить:

  1. Не стоит сразу покупать больше ОЗУ. Больше оперативной памяти для Java не решает эту проблему автоматически.
  2. Прочитай в logs/latest.log строки перед сообщением: что происходило в момент ошибки, какие плагины давали о себе знать чаще всего?
  3. Подтверди виновника во время работы. С помощью spark profiler start --thread * в Консоль ты увидишь все работающие потоки. Их названия часто указывают на плагин или мод.
  4. Только когда виновник подтверждён, обнови его в разделе Плагины либо Моды, проверь его настройки или удали.

Если не получается разобраться, открой тикет и укажи время сообщения. О spark: spark: как найти и понять причину лагов

Сервер не успевает: «Can't keep up»

Так выглядит сообщение:

Can't keep up! Is the server overloaded? Running 2014ms or 40 ticks behind

Что за этим стоит: Minecraft обрабатывает 20 тиков в секунду, то есть один тик должен занимать 50 миллисекунд. Если тики длятся дольше, накапливается отставание, которое сообщение указывает в миллисекундах и тиках. Сервер продолжает работать, но заметно медленнее: сломанные блоки появляются снова, мобы дёргаются. Причина обычно в нехватке памяти или нагрузке на процессор. Единичные сообщения при запуске или при генерации новых территорий — это нормально.

Как это исправить:

  1. Измерь нагрузку командой spark tps в Консоль. Решающее значение — MSPT, миллисекунды на тик: до 50 мс всё в порядке.
  2. Найди виновника командой spark profiler start --timeout 120 и открой ссылку, которую сервер выдаст после этого.
  3. Снизь нагрузку: уменьши дальность прорисовки view-distance и дальность симуляции simulation-distance в server.properties, заранее сгенерируй мир, упрости большие фермы.
  4. Проверь, хватает ли оперативной памяти (раздел «Память исчерпана: Java heap space»).

Полезно знать: spark уже входит в актуальные серверы Paper, на других серверах ты устанавливаешь его как плагин или мод.

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

Диагностика Paper Watchdog: сервер ненадолго завис

Так выглядит сообщение:

--- DO NOT REPORT THIS TO PAPER - THIS IS NOT A BUG OR A CRASH ---
Server thread dump (Look for plugins here before reporting to Paper!):

Что за этим стоит: Если поток сервера зависает на несколько секунд, Paper записывает диагностику с дампом потоков, то есть моментальным снимком того, чем сейчас занят сервер. Как сказано в первой строке: это не ошибка Paper и не сбой, но явный признак лагов. Если сервер приходит в себя, всё ограничивается зависанием. Если оно длится до предельного значения, следует прерывание Watchdog из первого раздела.

Как это исправить:

  1. Прочитай самые верхние строки в дампе под Server thread dump. Если там указано название плагина или мода, это сильный признак виновника.
  2. Обнови этот плагин в разделе Плагины или ради проверки удали его.
  3. Если дампы повторяются, проверь оперативную память, свои плагины и дальность прорисовки view-distance в server.properties.
  4. За единичными дампами, например при запуске или при сохранении большого мира, можно просто понаблюдать, не вмешиваясь сразу.

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

Сервер зависает при загрузке чанка

Так выглядит сообщение:

[ChunkTaskScheduler] Chunk wait task info below:
[ChunkTaskScheduler] Chunk holder: NewChunkHolder{world=<Мир>, chunkX=<x>, chunkZ=<z>, …, currentGenStatus=minecraft:initialize_light, requestedGenStatus=minecraft:full, …}

Что за этим стоит: Paper ждал загрузки или генерации чанка, то есть участка мира размером 16 × 16 блоков, дольше ожидаемого и записал диагностику. В этот момент сервер подвисает. currentGenStatus показывает, как далеко продвинулся чанк, requestedGenStatus — цель. Чаще всего причина в перегрузке: генерация мира, много игроков далеко друг от друга или медленные плагины. Реже повреждён регион.

Как это исправить:

  1. Уменьши дальность прорисовки view-distance в server.properties.
  2. Сгенерируй мир заранее, чтобы чанки не создавались прямо во время игры: Chunky: заранее сгенерировать мир Minecraft
  3. Проверь плагины командой spark profiler start --timeout 120 в Консоль.
  4. Если диагностика постоянно называет один и тот же мир и одни и те же координаты чанка, регион повреждён. Останови сервер и восстанови копию в разделе Резервные копии.

Полезно знать: Если там указаны необычайно большие координаты, кто-то забрался очень далеко. Границу мира можно задать командой worldborder set <Диаметр>.

Блок сообщений Paper Watchdog: сервер не отвечал

Так выглядит сообщение:

The server has stopped responding! This is (probably) not a Paper bug.
If you see a plugin in the Server thread dump below, then please report it to that author
If this is the case, consider increasing timeout-time in spigot.yml but note that this will replace the crash with LARGE lag spikes

Что за этим стоит: Эти строки — фиксированный текст-подсказка, который Paper записывает перед дампом потоков. Главный поток сервера не отвечал дольше предельного значения Watchdog. Типичные причины назван�� в самом тексте: перегруженный плагин, очень крупные операции с миром за один раз или обращения по HTTP и к базам данных, блокирующие поток сервера.

Как это исправить:

  1. Прочитай дамп потоков под этим блоком. Если там встречается плагин, обнови, настрой или удали его в разделе Плагины.
  2. Если там видно сохранение или редактирование мира, разбей крупные действия, например в WorldEdit, на более мелкие шаги.
  3. Если там видны обращения по HTTP или к MySQL, скорее всего, плагин ждёт внешний сервис или базу данных. Проверь его данные подключения.
  4. Увеличивай timeout-time в spigot.yml только осознанно. Как сказано в подсказке, ты меняешь сбой на долгие зависания.
  5. При повторяющихся зависаниях снизь нагрузку от плагинов и проверь оперативную память.

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

Задача чанка в Paper завершается ошибкой BootstrapMethodError

Так выглядит сообщение:

[ca.spottedleaf.concurrentutil.executor.thread.BalancedPrioritisedThreadPool] Exception thrown from thread <Поток>
java.lang.BootstrapMethodError: bootstrap method initialization exception

Что за этим стоит: Paper загружает и генерирует чанки в собственных потоках, то есть параллельных рабочих цепочках рядом с основной игрой. В одном из них Java не смогла подготовить точку вызова в программе. Возможные причины: ошибка в Paper, несовместимое расширение или неподдерживаемая версия Java. Одно лишь сообщение не указывает ни на одну из этих причин.

Как это исправить:

  1. Обнови Paper в разделе Версия до актуальной стабильной сборки твоей версии Minecraft.
  2. Используй версию Java, которую поддерживает эта сборка: Какая версия Java нужна твоему серверу Minecraft?
  3. Прочитай полный стек вызовов в logs/latest.log. Если строка Caused by называет плагин, обнови его в разделе Плагины.
  4. Не заменяй библиотеки сервера вручную. Это скорее приведёт к новым ошибкам.
  5. Если ошибка повторяется после обновления, сообщи полный стек вызовов проекту Paper.

Твоего сообщения здесь нет?

Прочитай сообщение целиком в logs/latest.log, и прежде всего строки перед ним: у перегрузки почти всегда есть причина, которая находится перед первым предупреждением. В стектрейсе или thread dump названия пакетов, то есть имена папок, разделённые точками, например com.<Разработчик>.<Плагин>, и имена файлов вроде <Плагин>.jar показывают, какой плагин или мод участвует. Перед изменением файлов конфигурации создай резервную копию в разделе Резервные копии. Если не получается разобраться, открой тикет и укажи время появления сообщения.