Введение: слепой администратор — мёртвый сервер

В чат сыпятся жалобы: «блоки возвращаются», «мобы телепортируются», «еда не естся». Вы заходите на сервер — и правда, всё тормозит. Но КАК узнать, что именно вызывает лаги? Многие администраторы в панике перезагружают сервер, не понимая причины. Лаги проходят на час — и возвращаются. Это замкнутый круг. В этом гайде я дам вам чёткий алгоритм диагностики: 5 шагов, которые превратят вас из паникующего новичка в хладнокровного инженера, способного найти источник лагов за 10 минут.

Шаг 1: Измеряем TPS — ваш главный показатель

TPS (Ticks Per Second) — это пульс сервера. Норма — 20 тиков в секунду. Если TPS падает, игровой мир начинает «тормозить». Первое, что нужно сделать при жалобах на лаги — измерить TPS.

Как измерить TPS:

• Без плагинов (Paper/Purpur): в консоли сервера введите команду /tps. Вы увидите TPS за последние 5 секунд, 1 минуту, 5 минут и 15 минут. Если TPS за 5 секунд ниже 18 — сервер лагает прямо сейчас.
• Через Spark: /spark tps — показывает TPS с разбивкой по мирам (обычный мир, ад, край).
• Через EssentialsX: /memory — показывает использование памяти, но не TPS напрямую.

Интерпретация результатов:

• 20 TPS: идеально, проблем нет.
• 18-19 TPS: небольшие просадки, игроки почти не замечают.
• 15-17 TPS: заметные лаги: задержка при копании блоков, рывки мобов.
• 10-14 TPS: серьёзные лаги: невозможно комфортно играть.
• Менее 10 TPS: сервер практически неиграбелен, требуется немедленное вмешательство.

Важно: если TPS за 15 минут 20, а за 5 секунд упал до 12 — проблема временная (кто-то зашёл в новый чанк, сработала гигантская ферма). Если TPS за 15 минут стабильно 15 — проблема постоянная и требует поиска источника.

Шаг 2: Запускаем профайлер Spark — находим виновника

Spark — это MUST HAVE инструмент для любого администратора. Он показывает, КАКИЕ именно задачи потребляют процессорное время сервера.

Как запустить профайлинг:

1. Убедитесь, что плагин Spark установлен (/spark — если команда не найдена, скачайте с spark.lucko.me).
2. Запустите профайлер на 2-3 минуты (пока сервер лагает):
   /spark profiler start --timeout 180
3. Дождитесь окончания. Spark выдаст ссылку на веб-отчёт. Откройте её в браузере.
4. В отчёте вы увидите ДЕРЕВО ВЫЗОВОВ (Call Tree). Это список всех задач, которые выполнял сервер, и сколько процессорного времени они заняли.

Как читать отчёт Spark (на примерах):

• Ticking entity — 45% CPU. Проблема в мобах. Кто-то развёл гигантскую ферму животных (500 кур в одном чанке). Решение: найти чанк (/spark health → раздел Entities) и убить лишних мобов.
• Ticking block entity — 30% CPU. Проблема в блоках: воронки, печи, раздатчики. Гигантская сортировочная система или ферма на воронках. Решение: попросить игрока выключать ферму, когда она не нужна, или уменьшить скорость воронок в paper.yml.
• Pathfinding — 25% CPU. Мобы пытаются найти путь. Обычно это зомби, которые не могут дойти до игрока. Решение: уменьшить радиус pathfinding в paper.yml: pathfinding.max-distance: 32.
• Chunk loading / generation — 50% CPU. Игрок летит на элитрах, генерируя новые чанки. Решение: предзагрузить мир через Chunky.
• Название вашего плагина — 20% CPU. Плагин написан неоптимально. Решение: обновить плагин, заменить на альтернативу или отключить.

Шаг 3: Проверяем проблемные чанки — Timings Report

Встроенный в Paper/Purpur инструмент Timings показывает, какие именно ЧАНКИ нагружают сервер.

1. В консоли выполните: /timings paste.
2. Сервер соберёт отчёт и выдаст ссылку. Откройте её.
3. На вкладке «Chunks» вы увидите карту мира, раскрашенную по нагрузке:
   • Зелёные чанки: всё в порядке.
   • Жёлтые: умеренная нагрузка.
   • Красные: ЭТИ ЧАНКИ УБИВАЮТ СЕРВЕР.
4. Наведите на красный чанк — вы увидите координаты и тип нагрузки (entity, block entity, redstone).
5. Телепортируйтесь туда: /tp X Y Z — и увидите причину своими глазами (ферма на 1000 свиней, зацикленный редстоун, 500 воронок).
6. Устраните проблему на месте или договоритесь с игроком.

Шаг 4: Анализ памяти — утечки и GC-паузы

Иногда лаги вызваны не процессором, а памятью. Сборщик мусора Java (Garbage Collector) периодически «останавливает мир» для очистки памяти. Если пауза длится 5-10 секунд — сервер зависает.

Как проверить GC-паузы:

• Spark показывает GC-паузы в разделе «Memory». Если паузы длиннее 500 мс — проблема.
• В консоли сервера могут появляться сообщения: GC pause: 4500ms.
• Решение: используйте флаги Aikar для JVM (см. статью «Ошибка Java Heap Space»), уменьшите -Xmx, проверьте плагины на утечки памяти.

Шаг 5: Проверяем диск — I/O wait

Если сервер сохраняет мир на медленный HDD, запись чанков может блокировать главный поток. Симптомы: TPS падает каждые 30-60 секунд на несколько секунд (автосохранение).

Как проверить:

• На Linux: iostat -x 1 — смотрите на столбец %util. Если диск загружен на 100% — проблема в нём.
• На Windows: «Диспетчер задач» → вкладка «Производительность» → «Диск». Если время отклика >100 мс — проблема.
• Решение: перенести сервер на SSD/NVMe, уменьшить частоту автосохранения в paper.yml (max-auto-save-chunks-per-tick: 12).

Алгоритм действий при лагах (шпаргалка)

1. /tps — подтвердить, что TPS упал.
2. /spark profiler start --timeout 180 — запустить профайлер.
3. /timings paste — получить карту проблемных чанков.
4. Открыть отчёты, найти красные зоны.
5. Телепортироваться в проблемный чанк, устранить причину.
6. Если причина не в чанках — проверить память (Spark → Memory) и диск (iostat).
7. Если причина в плагине — обновить/отключить/заменить.
8. После устранения — проверить TPS снова. Если 20 — проблема решена.

Типичные ошибки администраторов при диагностике

• Перезагружают сервер, не найдя причину. После перезагрузки всё чистится (мобы, память), и сервер работает нормально — до следующего раза. Вы не решили проблему, а отложили её.
• Смотрят только на TPS, игнорируя Spark. TPS говорит «ЧТО» (сервер лагает). Spark говорит «ПОЧЕМУ» (из-за воронок в чанке XZ).
• Винят хостинг, не проверив диск. «У меня мощный VDS, а сервер лагает». Мощный VDS с HDD-диском будет лагать сильнее, чем слабый VDS с NVMe.

💡 Совет профи

Настройте автоматический мониторинг TPS. Плагин Plan (Player Analytics) записывает историю TPS и строит графики. Вы можете зайти в веб-панель и посмотреть, в какое время суток TPS падает (например, всегда в 19:00, когда заходит больше игроков). Это позволяет планировать профилактику: «В 19:00 всегда лагает из-за фермы игрока X. Попрошу его выключать ферму на это время или перенесу её в отдельный мир».