Как найти причину вылета сервера

1. Проверка статуса контейнера в панели proxify.cloud

  1. Войдите в панель управления proxify.cloud.
  2. Выберите нужный узел (Node) и найдите ваш CT (Container) или VM с Minecraft.
  3. Посмотрите столбец Status:
    • Running — контейнер работает, проблема внутри Java-процесса.
    • Stopped — контейнер упал целиком (OOM Killer, kernel panic, лимиты ресурсов).
  4. Если статус Stopped — нажмите Console и прокрутите вывод вниз. Ищите строки:
    • Out of memory: Kill process — не хватает RAM.
    • CPU limit reached — превышен лимит vCPU.
    • Filesystem full — кончилось дисковое пространство.

2. Анализ логов Minecraft (latest.log)

Самый информативный источник — файл latest.log внутри папки сервера.

  1. Подключитесь по SSH к контейнеру:
    ssh root@<IP-контейнера>
# или через proxify.cloud: Console -> логин root
  2. Перейдите в директорию сервера (стандартные пути):
    cd /opt/minecraft/server        # типичный путь на proxify.cloud шаблонах
# или
cd /home/minecraft/server
# или
cd /var/lib/minecraft
  3. Посмотрите последние 200 строк:
    tail -n 200 logs/latest.log
  4. Ищите ключевые маркеры:
    • [FATAL] / [ERROR] — критические ошибки.
    • java.lang.OutOfMemoryError: Java heap space — не хватает кучи (Xmx).
    • java.lang.OutOfMemoryError: Metaspace — не хватает метаспейса.
    • Watchdog / A single server tick took 60.00 seconds — лаг/зависание основного потока.
    • Exception in thread "Netty Server IO #..." — сетевые ошибки/плагины.
    • Could not reserve enough space for code cache — не хватает нативной памяти (RAM контейнера < Xmx + overhead).

3. Анализ Crash-репортов (crash-reports/)

Если сервер создал дамп при краше:

  1. Перейдите в папку отчетов:
    ls -la crash-reports/
  2. Откройте самый свежий:
    cat crash-reports/crash-$(date +%Y-%m-%d_%-H.%-M.%-S)-server.txt
# или просто
cat crash-reports/latest-crash-report.txt  # если есть симлинк
  3. Смотрите секцию -- Head -- (причина) и -- Affected Level -- (мир/сущности).
  4. Частые причины в заголовке:
    • java.lang.StackOverflowError — рекурсия в плагине/моде (нужно увеличить -Xss или фиксить код).
    • java.lang.NoClassDefFoundError — отсутствует зависимость (библиотека/плагин).
    • Corrupted chunk / Chunk file corrupted — битый чанк (нужен region-fixer или восстановление из бэкапа).

4. Проверка системных логов Ubuntu ( journald / dmesg )

Если Java-процесс убит системой, в latest.log не будет записи о смерти.

  1. Проверьте OOM Killer:

    journalctl -u ct-<CTID> --since "1 hour ago" | grep -i -e oom -e kill -e memory
# или глобально на хосте (если есть доступ к ноде Proxmox):
dmesg -T | grep -i -e oom -e "kill process"

    Примечание: В панели proxify.cloud доступ к хосту (Proxmox node) обычно ограничен. Если вы видите Stopped в панели, а в контейнере логов нет — это 99% OOM на уровне хоста. Пишите в поддержку proxify.cloud с временем вылета и CTID.

  2. Проверьте лимиты контейнера (cgroups):

    cat /sys/fs/cgroup/memory.max          # Лимит RAM в байтах (max)
cat /sys/fs/cgroup/memory.current      # Текущее потребление
cat /sys/fs/cgroup/cpu.max             # Лимит CPU (period quota)

    Сравните memory.max с вашим -Xmx. Overhead (Metaspace, CodeCache, DirectMemory, Thread Stacks, GC structures) обычно 1.5–2 Гб сверху. Если Xmx=6G, контейнеру нужно минимум 8–9 Гб.

5. Мониторинг ресурсов в реальном времени (в момент вылета)

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

  1. Установите утилиты (если нет):
    apt update && apt install -y htop iotop sysstat
  2. Запустите запись sar (каждую минуту):
    sar -o /tmp/sar.log 60 60 > /dev/null 2>&1 &
# через час прочитайте:
sar -f /tmp/sar.log -r -u -d
  3. Параллельно в screen/tmux запустите htop и смотрите на:
    • Mem[||||||||||] — заполнение RAM.
    • Swap[||||| ] — если свап растет — ядро свопит Java, сервер замирает.
    • CPU% — если 100% на одном ядре — основной поток завис (watchdog).

6. Анализ Java Heap Dump (если есть .hprof)

При OutOfMemoryError можно настроить автодамп.

  1. Добавьте в запуск (start.sh / systemd unit):
    -XX:+HeapDumpOnOutOfMemoryError \
-XX:HeapDumpPath=/opt/minecraft/server/dumps/ \
-XX:OnOutOfMemoryError="kill -9 %p"
  2. После краша появится файл java_pid<hpid>.hprof.
  3. Анализ через Eclipse MAT (Memory Analyzer Tool) локально на ПК:
    • Скачайте файл через SFTP (FileZilla / WinSCP).
    • Откройте в MAT -> Leak Suspects Report.
    • Смотрите dominator_tree -> biggest objects. Часто виноваты: карты чанков (ChunkCache), большие ItemStack массивы, кэш плагинов (dynmap, CoreProtect).

7. Проверка плагинов/модов методом «бинарного поиска»

Если лог указывает на Unknown error или тихий краш без стека:

  1. Остановите сервер.
  2. Переименуйте папку plugins -> plugins_test.
  3. Создайте пустую plugins.
  4. Запустите сервер. Если не падает — проблема в плагинах.
  5. Переносите половину плагинов обратно, запускайте. Сузьте до 1 виновного за 5–6 итераций.
  6. Для модов (Forge/Fabric) — аналогично с папкой mods.
  7. Проверьте совместимость версий: Paper 1.20.4 != Spigot 1.20.4 API. Плагин, скомпилированный под Spigot API, может крашить Paper из-за отсутствующих методов.

8. Проверка целостности миров и датапаков

  1. Ошибки Corrupted chunk или Failed to load chunk:
    cd /opt/minecraft/server/world
# Проверка region-файлов (нужен region-fixer)
docker run -it --rm -v $(pwd):/data ghcr.io/minecraft-region-fixer/region-fixer:latest /data --delete-corrupted
  2. Битые датапаки (functions/loot_tables):
    find world/datapacks -name "*.json" -exec jq empty {} \; 2>&1 | grep -v "^$"
    Удалите или исправьте файлы с ошибками JSON.

9. Проверка конфигурации запуска (флаги JVM)

Неправильные флаги — частая причина нестабильности.

  1. Посмотрите текущую команду запуска:
    cat start.sh
# или
systemctl cat minecraft.service
  2. Обязательные флаги для продакшена (Paper/Purpur):
    -Xms6G -Xmx6G \
-XX:+UseG1GC \
-XX:+ParallelRefProcEnabled \
-XX:MaxGCPauseMillis=200 \
-XX:+UnlockExperimentalVMOptions \
-XX:+DisableExplicitGC \
-XX:+AlwaysPreTouch \
-XX:G1NewSizePercent=30 \
-XX:G1MaxNewSizePercent=40 \
-XX:G1HeapRegionSize=8M \
-XX:G1ReservePercent=20 \
-XX:G1HeapWastePercent=5 \
-XX:G1MixedGCCountTarget=4 \
-XX:InitiatingHeapOccupancyPercent=15 \
-XX:G1MixedGCLiveThresholdPercent=90 \
-XX:G1RSetUpdatingPauseTimePercent=5 \
-XX:SurvivorRatio=32 \
-Dusing.aikars.flags=https://mcflags.emc.gs \
-Daikars.new.flags=true
    Замените 6G на ваш Xmx. -Xms должен равняться -Xmx.
  3. Уберите устаревшие флаги: -XX:+UseConcMarkSweepGC, -XX:+CMSIncrementalMode, -Xmn, -XX:PermSize (для Java 17+).
  4. Если используете Java 21+ (рекомендую для 1.20.4+), добавьте:
    -XX:+ZGenerational  # Экспериментально, часто стабильнее G1 на больших кучах
# ИЛИ оставайтесь на G1 (выше), он предсказуемее.

10. Проверка дискового I/O и файловой системы

Медленный диск = таймауты тиков = Watchdog краш.

  1. Проверьте IOPS (в консоли proxify.cloud часто указан тип диска: NVMe / SSD / HDD):
    fio --name=randread --ioengine=libaio --iodepth=16 --rw=randread --bs=4k --direct=1 --size=1G --numjobs=1 --runtime=30 --group_reporting
    Ожидаем > 50k IOPS для NVMe, > 10k для SSD. Если меньше — диск бутылочное горлышко.
  2. Проверьте inodes (много мелких файлов миров/плагинов):
    df -i /opt/minecraft
    Если IUse% = 100% — сервер не сможет создавать файлы (логи, чанки, сессии).
  3. Проверьте ошибки ФС:
    dmesg -T | grep -i -e error -e fail -e ext4 -e xfs -e nvme

11. Сетевые проблемы (Proxy / Firewall)

Если сервер «вылетает» только у игроков, а