Para solucionar el lag de un servidor de Minecraft con spark, primero identifica qué se está degradando: la conexión, el bucle de ticks o ambos. Mide TPS, MSPT y ping; captura el periodo problemático con el profiler; revisa el trabajo del Server thread; aplica un solo cambio; y repite la misma medición. Un ping alto no se arregla eliminando plugins, y 20 TPS no descarta picos breves que los jugadores sí perciben.
Respuesta rápida: si el servidor mantiene cerca de 20 TPS y el MSPT permanece por debajo de 50 ms, pero uno o varios jugadores tienen ping alto, investiga primero red, ruta y cliente. Si el MSPT supera 50 ms y los TPS caen, el servidor no alcanza a completar cada tick a tiempo: perfila el hilo principal para localizar la carga. Son señales de diagnóstico, no pruebas aisladas, y ambos problemas pueden coexistir.
Antes de perfilar: qué mide spark
Minecraft intenta ejecutar 20 ticks por segundo. Para sostenerlos, cada tick debe terminar dentro de un presupuesto de 50 milisegundos. TPS indica el ritmo conseguido; MSPT indica cuánto tarda el trabajo de cada tick. spark recomienda mirar la distribución —como mediana, percentil 95 y máximo— en lugar de decidir por una sola media. Consulta la explicación oficial de TPS y MSPT y su guía del bucle de ticks.
| Síntoma | Métrica útil | Prueba siguiente | Acción inicial |
|---|---|---|---|
| Bloques que reaparecen, mobs congelados, comandos tardíos | MSPT y TPS | Perfil del Server thread | Localizar el trabajo que consume el tick |
| Solo algunos jugadores sufren retraso o desconexiones | Ping por jugador | Comparar jugadores, ubicación y horario | Revisar cliente, Wi-Fi, ruta y pérdida de paquetes |
| Congelones breves con métricas normales la mayor parte del tiempo | Máximo, p95 y tick monitor | Capturar únicamente ticks lentos | Buscar tareas periódicas, guardados, generación de chunks o GC |
| Lag al explorar terreno nuevo | MSPT durante exploración | Perfil controlado reproduciendo el recorrido | Examinar generación/carga de chunks y distancia de simulación |
| Lag después de instalar o actualizar algo | Comparación antes/después | Rollback controlado | Revertir una modificación y volver a medir |
Prerrequisitos, compatibilidad y respaldo
- Acceso a la consola o una cuenta con permisos de spark.
- Una ventana representativa: jugadores conectados y la carga que normalmente provoca el problema.
- Una copia de seguridad verificable de mundos, configuración y lista de plugins o mods.
- La plataforma y versión exactas del servidor.
Paper 1.21 y posteriores incluyen spark, por lo que normalmente no necesitas instalar otro JAR. Si quieres usar el plugin externo en Paper, su documentación indica iniciar Java con la propiedad siguiente. Reinicia el servidor por completo; no uses /reload.
java -Dpaper.preferSparkPlugin=true -jar paper.jar --nogui
En Bukkit, Fabric, Forge o NeoForge, descarga desde la página oficial de spark el build correspondiente a tu plataforma. Con el servidor apagado, coloca el JAR en plugins/ para plataformas Bukkit o en mods/ para loaders de mods y arranca de nuevo. No mezcles builds ni asumas compatibilidad por el nombre de un fork; compruébala para la plataforma y versión que realmente ejecutas. La documentación de instalación mantiene las instrucciones vigentes.
Para deshacer la instalación externa, apaga el servidor, retira el JAR que agregaste, restaura la configuración o el backup si fue modificada y reinicia. No borres mundos como parte del diagnóstico.
Permisos mínimos
El permiso general es spark. Para delegar solo ciertas funciones, spark documenta permisos granulares como spark.tps, spark.healthreport, spark.ping, spark.profiler y spark.tickmonitor. Limita la creación y publicación de perfiles a administradores: los reportes pueden revelar nombres de plugins, configuración y otros detalles operativos.
Paso 1: registra una línea base
Anota hora, jugadores conectados, acción que reproduce el lag, uso de CPU y memoria del panel, versión del servidor y cambios recientes. Después ejecuta:
/spark tps
/spark health
/spark tps muestra el ritmo de ticks y métricas de duración. /spark health ofrece un resumen de salud. Si necesitas compartir el informe, /spark health --upload lo sube al servicio de spark. Revisa el enlace antes de compartirlo y trátalo como información operativa; la documentación no debe interpretarse como una promesa de privacidad, no indexación o expiración.
/spark health --upload
Guarda los valores de mediana, p95 y máximo. Una mediana sana junto a un máximo muy alto es compatible con picos: no concluyas que “todo está bien” a partir del promedio.
Paso 2: separa ping alto de tick lag
/spark ping
/spark ping --player NombreDelJugador
Si los TPS están cerca de 20 y el MSPT se mantiene por debajo de 50 ms, pero el ping es alto, investiga latencia de red, pérdida, Wi-Fi, ruta entre el jugador y el centro de datos, saturación de subida del cliente y descargas concurrentes. Compara varios jugadores y horarios. Una sola lectura de ping no identifica la causa, y una conexión mala puede coexistir con ticks lentos.
Si el MSPT supera el presupuesto de 50 ms y los TPS descienden, continúa con el profiler. En Paper, /timings está deprecado; spark es la herramienta actual indicada en la referencia de comandos de Paper.
Paso 3: captura una muestra representativa
Inicia el perfil justo antes de reproducir el problema y detenlo después. No dejes correr una captura sin contexto durante horas: una muestra enorme puede mezclar estados distintos y ocultar el evento útil.
/spark profiler start
/spark profiler info
/spark profiler open
/spark profiler stop
stop termina el perfil y sube el resultado para abrirlo en el visor. Si no quieres subir la captura, usa cancel para descartarla o guarda el perfil en un archivo local:
¿Tu servidor necesita más margen para los picos?
Elige recursos adecuados para tu versión, plugins y número de jugadores, y vuelve a medir con spark después de migrar.
/spark profiler cancel
/spark profiler stop --save-to-file
También puedes limitar la duración:
/spark profiler start --timeout 120
Para un diagnóstico general empieza por la configuración predeterminada. --thread * amplía la muestra a todos los hilos; úsalo solo si necesitas investigar trabajo asíncrono o no sabes en qué hilo ocurre. --alloc estudia asignaciones de memoria y añade coste, así que no es el primer paso para cualquier caso.
/spark profiler start --thread *
/spark profiler start --alloc
Paso 4: captura picos que aparecen y desaparecen
Para recibir avisos cuando un tick cruza un umbral de 50 ms:
/spark tickmonitor --threshold-tick 50
Para perfilar solo los ticks que superen el umbral elegido, usa la sintaxis actual documentada por spark:
/spark profiler start --only-ticks-over 100
Elige el umbral según el síntoma. Un valor de 100 ms busca ticks que tardan al menos el doble del presupuesto normal. Reproduce el evento —teletransporte, exploración, granja activa, guardado o tarea programada— y detén la captura cuando hayas recogido varios ejemplos. La guía oficial explica este flujo en Finding lag spikes.
Paso 5: interpreta el visor sin culpar al primer nombre
- Abre el Server thread cuando investigues tick lag.
- Busca ramas anchas o con un porcentaje relevante durante la ventana problemática.
- Expande la rama hasta llegar a métodos o tareas que puedas relacionar con una mecánica, plugin, mod, entidad o carga de chunks.
- Compara con el momento exacto y el escenario que reprodujiste.
Ver parked o waitForNextTick en una muestra puede ser una señal saludable: el hilo terminó su trabajo y espera el siguiente tick. La vista Sources agrupa muestras por origen, pero que un plugin aparezca arriba no demuestra por sí solo causalidad. Puede estar llamando código del servidor, reaccionando a otra carga o simplemente ser visible durante una muestra sesgada. spark es un profiler de muestreo: muestra dónde se observaron muestras, no una factura exacta de CPU ni una prueba automática de culpabilidad. Usa la guía oficial del visor para conocer sus vistas.
Patrones que sí orientan la siguiente prueba
- Plugin o mod: desactívalo únicamente en una copia de prueba o durante una ventana controlada, conserva sus datos y repite el mismo escenario. Actualizar a una versión compatible suele ser preferible a borrar configuración a ciegas.
- Entidades o block entities: identifica mundo y zona; revisa granjas, hoppers, aldeanos, redstone y acumulaciones. No ejecutes eliminaciones masivas sin backup.
- Generación o carga de chunks: compara terreno nuevo contra chunks ya generados; revisa distancias y tareas de pregeneración sin asumir que más hilos solucionarán el tick principal.
- Guardados, backups o tareas programadas: correlaciona el pico con el horario. Mueve tareas pesadas fuera de las horas activas y vuelve a medir.
- GC o asignaciones: confirma el patrón con métricas de memoria y, solo si hace falta, un perfil de asignaciones. No cambies flags de Java basándote en una sola captura.
Aplica cambios de uno en uno y valida
Una optimización sin comparación es una corazonada. Conserva la línea base, aplica un único cambio reversible y repite la misma carga durante una ventana comparable. Comprueba:
- TPS cerca del objetivo bajo la misma cantidad de jugadores.
- Reducción de mediana, p95 y máximo de MSPT.
- Menos ticks que superan el umbral del monitor.
- Ausencia de errores nuevos en consola.
- Funcionamiento correcto de mecánicas, plugins, mods y guardados.
Si empeora o aparece una regresión, restaura el archivo o configuración anterior, reinicia limpiamente y confirma que las métricas regresan a la línea base. No uses /reload para validar cambios en plugins.
Errores frecuentes de spark
“Unknown command”
Confirma plataforma, versión y que spark esté realmente cargado. En Paper 1.21 o posterior prueba desde consola; con un plugin externo, revisa que el JAR esté en la carpeta correcta y que hayas realizado un reinicio completo. Consulta el log de inicio en busca de errores de carga.
El comando existe, pero el jugador no puede usarlo
Ejecuta desde consola o asigna únicamente el permiso granular necesario. Verifica que el gestor de permisos opere en el contexto y mundo correctos.
El perfil no capturó el pico
Reduce la ventana, inicia antes del evento reproducible o usa --only-ticks-over. Repite más de una vez: los picos esporádicos requieren varias muestras comparables.
El profiler nativo no inicia
spark documenta un fallback al sampler de Java. Úsalo si el entorno no permite el profiler nativo:
/spark profiler start --force-java-sampler
Mantenimiento para que el lag no vuelva “de sorpresa”
- Registra una línea base después de cada actualización importante.
- Conserva versiones de servidor, Java, plugins y mods junto al reporte.
- Programa backups y tareas intensivas fuera de los picos de jugadores.
- Prueba actualizaciones en staging o con una copia antes de producción.
- Repite el perfil cuando cambie la carga; un reporte antiguo no describe necesariamente el servidor actual.
Si estás eligiendo o migrando infraestructura, dimensiona el servidor por su carga real y no solo por el número de slots. Los modpacks, la distancia de simulación, la generación de chunks y los plugins pueden cambiar drásticamente el trabajo por tick. Puedes revisar nuestra guía publicada de modpacks de Minecraft como referencia para evaluar cargas distintas.
Preguntas frecuentes
¿20 TPS significa que el servidor no tiene lag?
No siempre. Puede haber picos breves ocultos por una lectura agregada, o lag de red con el tick loop sano. Revisa MSPT, p95, máximo y ping durante el problema.
¿Cuánto tiempo debe correr el profiler?
Lo suficiente para capturar varias veces el evento representativo, no una duración arbitraria. Para un fallo reproducible pueden bastar uno o dos minutos; un problema periódico necesita una ventana alineada con su aparición.
¿El plugin que encabeza Sources es el culpable?
No necesariamente. Es una pista para diseñar una prueba. Revisa el árbol del Server thread, el método implicado y el contexto; después compara con y sin el cambio en condiciones controladas.
¿spark reemplaza las pruebas de red?
No. spark ayuda a observar el servidor y el ping de jugadores, pero la pérdida de paquetes y una ruta deficiente requieren pruebas de red adicionales desde los extremos afectados.
Conclusión
El resultado útil de spark no es un enlace con muchos porcentajes: es una hipótesis comprobable. Conserva la línea base, captura el síntoma correcto, relaciona la rama costosa con una acción real y valida un cambio reversible. Así sabrás si necesitas ajustar software, reducir una carga concreta, revisar la red o dimensionar mejor el servidor, sin convertir el diagnóstico en una ruleta de plugins.
