Cómo investigar el lag de Minecraft: métricas silenciosas y almacenamiento compartido

El lag de Minecraft puede deberse a causas distintas: procesamiento de ticks del servidor, pausas breves al guardar, red o renderizado del cliente. Presentamos de forma anónima una investigación en varios servidores Paper, sin revelar nombres de host ni configuración internos.

Capturar el primer perfil mientras ocurre el lag

Registre hora del lag, jugadores y actividad de guardado; compare el perfil con el MSPT de ese período. Tome también una muestra breve en condiciones normales. Distinguir más procesamiento de más espera ayuda a elegir entre ajustar plugins o investigar almacenamiento.

PaperMC：Perfilar durante el problema

Medir por separado los promedios y las pausas breves

Registra TPS, MSPT medio, máximo y p95, y el total acumulado de ticks lentos. Un promedio bueno puede ocultar pausas breves. El uso de CPU de todo el host no permite distinguir el trabajo de un único hilo de una espera de E/S.

Recopilar sin ruido y registrar los datos ausentes

En este caso, un pequeño plugin escribió en JSON local mediciones obtenidas mediante la API pública de Paper, y un recolector las agregó en series temporales de monitorización. La E/S de archivos se ejecutó fuera del hilo principal del juego; sustituir un archivo temporal evitó que los lectores vieran una actualización incompleta. No se ocultaron los mensajes habituales de la consola.

Comprueba también las marcas de tiempo y si la recopilación tuvo éxito. No trates como saludable un valor antiguo de un recolector detenido ni sustituyas datos ausentes por cero TPS.

Correlacionar ventanas acotadas de JVM, SO y guardado

Mientras el problema se reproducía, se recopilaron JFR, observaciones de espera del SO y E/S de bloques en ventanas separadas y limitadas. Se compararon con la serie continua de MSPT y la presión periódica de E/S para distinguir la actividad del GC de las esperas durante los guardados síncronos. Las capturas no se realizaron todas al mismo tiempo. Para empezar con Paper, consulta la guía oficial de perfilado con spark. En este caso se añadieron JFR y observaciones del SO para investigar las esperas al guardar.

En una ventana normal de 240 segundos y otra con atascos de 220 segundos, las medianas por segundo de write-await fueron de 1.60 ms y 43.71 ms; los máximos fueron de 6.00 ms y 123.57 ms. Son dos ventanas de observación, no resultados antes y después ni un benchmark general.

Además de las esperas en los guardados síncronos y el journal del sistema de archivos, también se vieron retrasos en solicitudes al dispositivo de varias aplicaciones; así se acotó el candidato a la ruta de almacenamiento compartido. Un evento de finalización de un tracepoint de bloques de Linux puede representar solo parte de una solicitud; por eso no se mezclaron solicitudes sin correspondencia en una estadística de toda la E/S. Se limitaron el tiempo y el volumen de captura y se tuvo en cuenta la sobrecarga de la medición.

1. 1 Métricas continuas discretas Registra TPS/MSPT y datos ausentes sin añadir mensajes rutinarios a la consola.
2. 2 Investigación acotada Recopila JFR, SO y block I/O por separado y compáralos. El almacenamiento compartido es una causa candidata, no un fallo confirmado.

Tratar el siguiente paso como una prueba aparte

Tras la investigación se detuvo el trazado acotado y se confirmó que la recopilación continua funcionaba. Aún no se ha comparado el rendimiento durante varios ciclos de uso similar tras migrar el almacenamiento. Este registro prepara el siguiente paso con planes de copia de seguridad, restauración y reversión; no reduce la durabilidad de los guardados ni culpa al GC o a un plugin sin pruebas.

Para distinguir señales de monitorización de un diagnóstico, consulta Monitorización e investigación de incidentes con OpenClaw. Para probar la recuperación, consulta Monitorización de copias con R2 y restic.