Cuando Minecraft va a tirones en el equipo de un amigo, puede que sus FPS sean bajos, que la conexión responda con retraso o que el servidor procese sus pasos de juego demasiado despacio. spark ayuda con el servidor en funcionamiento; no demuestra la causa de cada tirón a partir de un único número. Empezad con la observación concreta durante vuestra partida conjunta.
Esta guía reúne un diagnóstico manejable para un grupo pequeño de MCF. Un servidor gratuito con 2 GB de RAM tiene recursos limitados, pero más RAM no es una solución universal para cualquier retraso. Si un pack ni siquiera termina de arrancar, seguid primero el diagnóstico de arranque.
Comprobado: 7 de octubre de 2026. Las capturas de pantalla muestran una prueba anterior con Paper 1.21.4. Sus valores no son un nuevo benchmark de MCF ni un rendimiento garantizado para vuestro mundo.
Anotar la observación conjunta
Apuntad el momento, el lugar de juego y la acción: ¿alguien vuela hacia terreno nuevo, hay una granja en marcha o se traba ya al girar la cámara? Comparad con un segundo amigo en el mismo periodo. «Solo uno está afectado» acota el diagnóstico, pero todavía no demuestra que su conexión a internet sea la causa.
| Observación | Siguiente comparación |
|---|---|
| La cámara y la imagen se traban | Comprobar FPS del cliente, carga gráfica y dispositivo |
| Los bloques reaccionan tarde | Valorar juntos los ticks actuales del servidor y la conexión |
| Solo un amigo se desconecta | Comparar su mensaje, su cliente y su conexión con una entrada correcta |
| El servidor aún no arranca | Revisar el log de inicio actual en lugar del profiler en ejecución |
Un promedio de TPS de varios minutos puede ocultar una interrupción breve. Por eso, anotad el momento exacto y observad ventanas de tiempo adecuadas. Observad la actividad normal de juego en la que aparece el problema; una carga extrema generada artificialmente responde a otra pregunta. Si el mundo se ha cargado hace poco, justo después de despertar el servidor, medid además una partida posterior en curso: la carga de arranque y la carga recurrente durante el juego son situaciones distintas. Un servidor vacío solo sirve como medición de comparación y no demuestra que vuestra partida vaya fluida.
Comprobar si spark ya está disponible
Paper incluye spark desde Minecraft 1.21. Así lo describe la documentación de profiling de Paper. Comprobad primero el comando existente y la salida de inicio actual. Un mensaje de error en /version spark por sí solo no demuestra que falte un plugin si la integración viene incorporada.
En otras versiones de servidor puede que necesitéis la edición adecuada del plugin o del mod. Un plugin de Bukkit no pertenece a un servidor Fabric puro. Comprobad la compatibilidad con la versión instalada de Minecraft y del loader antes de añadir otro archivo.
Una cuenta responsable puede recibir de forma específica spark.tps y, si hace falta, spark.profiler. El permiso general spark abarca más que la primera comparación de valores. La referencia oficial de comandos indica los permisos correspondientes. Los amigos normales no necesitan gestionar el profiler ni tener acceso de propietario de MCF para informar del problema.
Leer la duración del tick y los TPS en el periodo correcto
Ejecutad durante el retraso observado:
/spark tps
El valor objetivo normal de 20 ticks por segundo equivale, en términos de cálculo, a un presupuesto de tiempo de 50 milisegundos por tick: 1.000 ms divididos entre 20. La explicación de spark sobre TPS y MSPT distingue entre la frecuencia de ticks y el tiempo de tick necesario.
Además de la mediana, leed también los valores superiores y la ventana de tiempo correspondiente. El percentil 95 describe una distribución; no es ni el peor valor individual ni, por sí solo, una prueba de la percepción de los jugadores. No existe un límite universal por el que hasta 19 TPS nadie note nada y por debajo todos tengan la misma experiencia.
Captura anterior: en los últimos diez segundos aparecen 20 TPS, además de 2,4 ms de mediana y 4,4 ms en el percentil 95. Esta prueba tranquila no dice nada sobre vuestra granja posterior ni sobre otro momento de carga.
La CPU del sistema y la CPU del proceso son datos distintos. También los límites del contenedor, el número de procesadores y el método de medición influyen en la interpretación. Un porcentaje bajo por sí solo no demuestra un procesamiento del hilo principal lo bastante rápido. La RAM contratada, el heap de Java y la memoria total del proceso también se consideran por separado.
Realizar una grabación limitada si hace falta
Si los números dejan la causa todavía abierta, una cuenta responsable puede iniciar el profiler. Acordad una actividad de juego normal y breve, y anotad el inicio y el final:
/spark profiler start
/spark profiler info
Dejad que la ejecución incluya la interrupción real. Un minuto puede servir como primera prueba propia, pero no es una duración mínima ni de éxito garantizada. Con interrupciones poco frecuentes necesitáis un periodo acorde con la observación y debéis finalizar la grabación de forma consciente.
Los comandos actuales distinguen las salidas: /spark profiler stop finaliza la ejecución y normalmente entrega un informe en el visor web, cuyo enlace volvéis a encontrar en la salida de la consola al terminar el profiler (anotadlo junto con vuestra situación de juego); /spark profiler cancel la descarta sin la subida final. /spark profiler open abre un visor para el diagnóstico en curso y no es una visualización local directamente en el juego.
Para obtener un archivo en lugar de la subida normal, la documentación actual indica:
/spark profiler stop --save-to-file
Comprobad que vuestra versión instalada ofrece esta vía y anotad la ruta de archivo indicada. Un archivo guardado localmente todavía no es un enlace de visor accesible públicamente. No concedáis además permisos de heapdump solo para reunir un primer diagnóstico de ticks.
Demostración de uso anterior. El mensaje visible sobre un plugin no encontrado y el profiler integrado que se ejecuta después no son un diagnóstico actual de la instalación de vuestro servidor.
Revisar el informe antes de compartirlo
Un informe de spark no está libre de datos personales en todos los casos. La descripción oficial de los datos en bruto muestra metadatos con el nombre y el identificador del usuario que lo ejecuta. Otros contenidos dependen del tipo de informe, del servidor y de las opciones.
Revisad el informe real antes de enviarlo y compartidlo de forma dirigida con el soporte responsable. Un visor ya abierto o publicado no se retira por cancelar después otra ejecución distinta. Tratad también un archivo de heapdump como algo distinto de una captura de pantalla anónima corriente.
Para el primer diagnóstico de soporte, añadid el momento, las versiones del pack o de los plugins, el número de jugadores activos y la acción observada. No añadáis credenciales ajenas ni una exportación completa de archivos sin control.
Derivar del diagnóstico un cambio verificable
Un árbol de llamadas muestra dónde se observó tiempo en el periodo medido. Una proporción alta en un plugin es un punto de partida para seguir investigando y no prueba automáticamente que ese plugin sea el único defectuoso. La guía de spark sobre picos de lag ayuda a leer los datos en el momento adecuado.
Si intervienen zonas de terreno nuevas, se distinguen la generación y la carga de chunks ya existentes. Chunky puede preparar una zona acordada, pero no libera al servidor en marcha de todo el trabajo de chunks posterior. Comprobad la memoria y la carga antes de generar una zona grande.
Si intervienen pausas largas de recolección de memoria, examinad el consumo y su evolución. Por sí solas no demuestran una fuga de memoria ni que baste con una mejora de plan. La guía de RAM de Cobblemon (en) separa los valores históricos de los límites del plan y del proceso.
Antes de cambiar nada, guardad el estado inicial. Modificad una sola cosa justificada y repetid la misma actividad de juego en condiciones comparables. Documentad los valores individuales, las ventanas de tiempo y el número de jugadores; un segundo minuto más tranquilo por casualidad no es una prueba sólida de mejora.
FAQ
¿20 TPS significan que el servidor nunca se traba brevemente?
No. Un promedio puede ocultar interrupciones breves. Comprueba las duraciones de tick y el periodo de la observación concreta, así como el cliente y la conexión.
¿El Paper actual necesita un plugin adicional de spark?
Paper incluye spark desde la 1.21. Comprueba la integración existente y sus funciones antes de instalar nada más.
¿profiler open es un informe local sin subida?
Abre el visor del diagnóstico en curso. Para un cierre expresamente local, comprueba la vía de guardar en archivo que ofrezca tu versión instalada.
¿El informe garantiza que no contiene datos personales?
La documentación oficial de datos en bruto muestra, entre otros, el nombre de usuario y el identificador en los metadatos. Revisa el informe real antes de compartirlo.
¿Que solo un amigo esté afectado demuestra un problema de internet?
Es solo una pista comparativa. Hay que seguir comprobando el cliente, la conexión y los procesos del servidor para ese jugador a partir de la observación concreta.
¿Debo subir la RAM enseguida cuando hay lag?
Primero justifica el límite de recursos. La RAM no ayuda por sí sola contra un trabajo de ticks lento, un cliente inadecuado o problemas de conexión.