Insights / Технические материалы
Как расследовать задержки Minecraft: тихий сбор метрик и анализ общего хранилища
От ненавязчивого сбора TPS/MSPT до сопоставления JFR с наблюдениями за I/O операционной системы. Здесь завершённое исследование причин отделено от ещё не проверенных улучшений производительности.
Содержание
Задержки Minecraft могут быть связаны с разными причинами: обработкой серверных tick, краткими паузами при сохранении, сетью или отрисовкой на клиенте. Мы анонимно описываем расследование на нескольких серверах Paper, не раскрывая внутренние имена хостов и конфигурацию.
Снимать первый профиль во время задержки
Запишите время задержки, число игроков и наличие сохранения; сопоставьте профиль с MSPT за этот период. Снимите также короткую нормальную выборку. Разделение роста вычислений и ожидания помогает выбрать между настройкой плагинов и исследованием хранилища.
PaperMC：Профилирование во время проблемы
Измеряйте средние значения и краткие остановки отдельно
Записывайте TPS, средний, максимальный и p95 MSPT, а также суммарное число медленных tick. Хорошее среднее значение может скрывать краткие остановки. Общая загрузка CPU хоста не позволяет отличить работу одного потока от ожидания I/O.
Собирайте данные без шума и отмечайте пропуски
В этом случае небольшой плагин записывал локальный JSON с измерениями из публичного API Paper, а сборщик объединял их в мониторинговые временные ряды. Файловый I/O выполнялся вне игрового main thread; замена временного файла не позволяла читателям увидеть частичное обновление. Обычные сообщения консоли не скрывались.
Также проверяйте временные метки и успешность сбора. Старое значение остановленного сборщика нельзя считать нормальным; пропущенные данные не заменяются нулевым TPS.
Сопоставляйте ограниченные наблюдения JVM, ОС и сохранения
Пока проблему удавалось воспроизводить, JFR, ожидания ОС и блочный I/O собирались в отдельных окнах ограниченной длительности. Наблюдения сопоставили с непрерывным рядом MSPT и периодической нагрузкой на I/O, чтобы отличить активность GC от ожиданий при синхронном сохранении. Все сборы не выполнялись одновременно. В качестве общего начала для Paper используйте официальное руководство по профилированию spark. В этом расследовании JFR и наблюдения ОС добавили для изучения ожиданий при сохранении.
В нормальном окне наблюдения длительностью 240 секунд и окне с зависаниями длительностью 220 секунд секундные медианы write-await составляли 1,60 мс и 43,71 мс, а максимумы — 6,00 мс и 123,57 мс. Это сравнение двух окон наблюдения, а не результат до и после меры и не общий бенчмарк.
Помимо ожиданий при синхронном сохранении и ожиданий journal файловой системы, задержки обнаружились и в запросах к устройству от нескольких приложений. Круг причин-кандидатов сузился до общего пути хранения. Событие завершения блочного tracepoint Linux может описывать только часть запроса, поэтому несопоставленные запросы не включались в статистику всего I/O. Длительность и объём сбора ограничили и учли нагрузку от измерений.
- Постоянный тихий сбор Записывайте TPS/MSPT и пропуски данных без увеличения обычного вывода в консоль.
- Ограниченное расследование Собирайте JFR, ОС и block I/O раздельно и сопоставляйте. Общее хранилище — возможная причина, а не подтверждённая неисправность.
Проверяйте следующий шаг отдельно
После расследования ограниченный сбор трассировки прекратили и подтвердили нормальную работу постоянного мониторинга. Сравнение нескольких циклов при сходной нагрузке после переноса хранилища ещё не проводилось. Эта запись готовит следующие меры с планами резервного копирования, восстановления и отката; она не снижает надёжность сохранения и не обвиняет GC или конкретный плагин без доказательств.
О различии между сигналами мониторинга и расследованием инцидентов см. Мониторинг и расследование инцидентов OpenClaw; проверка восстановления описана в Мониторинге резервных копий R2 и restic.