--- title: "Servidor Minecraft Paper: diagnosticar y estabilizar el TPS" description: "Alojamiento para servidor Paper centrado en lo que tumba el tick: lectura del mspt, perfilado con spark, claves del paper-world-defaults.yml y el plugin culpable." url: "https://streethosting.com.br/es/minecraft-paper" type: "page" language: "es" --- Paper, plugins y lectura del mspt # Servidor Paper con un TPS que puedes explicar Paper es el fork de plugins que usa la mayoría de servidores públicos. Aquí el tema es qué optimiza de verdad, qué claves de configuración merecen que las toques y cómo encontrar el plugin que se come el tiempo del tick. [Ver planes para correr Paper](https://streethosting.com.br/es/minecraft-pro#plans) [Entender TPS y mspt antes](https://streethosting.com.br/es/guias/minecraft/o-que-e-tps-minecraft-como-melhorar) * São Paulo, Brasil * Anti-DDoS hasta 400 Tbps * NVMe Respuesta rápida Paper es un fork de Spigot que mantiene la API de Bukkit y reescribe partes caras del servidor, como la carga de chunks y el ticking de entidades. En la práctica, el TPS de un servidor Paper depende mucho más de la frecuencia por núcleo y de dos o tres plugins pesados que de la RAM contratada. ## Paper es un fork de plugins, y eso define el ecosistema El linaje es CraftBukkit, Spigot y Paper. Como Paper conserva la API de Bukkit y de Spigot, el jar de un plugin compilado para Spigot arranca sin recompilar. Por eso la base instalada de EssentialsX, LuckPerms, Vault y WorldGuard sigue funcionando tras el cambio. Lo que Paper añade es implementación, no una API nueva incompatible: chunks reescritos, motor de luz, rastreo de entidades, tolvas. Nada de eso vuelve paralelo el tick, la ganancia viene de que cada tick cuesta menos. Cambiar el jar rinde una mejora real y limitada, y el resto depende de la configuración y de qué plugins aceptes cargar. ## El mspt es la métrica, el TPS es solo el síntoma El TPS tiene techo en 20. Un servidor gastando 45 milisegundos por tick marca 20,0 y parece sano, cuando le quedan 5 milisegundos de holgura. Basta una explosión o alguien explorando terreno nuevo para pasar de 50 y que el número se desplome. Quien solo mira el TPS descubre el problema después que el jugador. Mira la distribución, no la media. Mediana baja con percentil 95 alto indica pico periódico, y el sospechoso suele ser el autosave, una tarea programada o la generación de terreno. Media alta con distribución estrecha indica carga constante, casi siempre entidades, tolvas o código que se ejecuta en cada evento de movimiento. Conviene además separar el lag de tick del lag de red. Si el mspt está cómodo y el jugador sigue notando retraso, ninguna clave de yml lo arregla. ## Dónde vive la configuración y qué tiene sentido tocar A partir de Paper 1.19 la configuración se dividió en dos archivos dentro de la carpeta config: paper-global.yml, con lo que vale para todo el servidor, y paper-world-defaults.yml, con los valores por defecto de los mundos. Cada mundo todavía puede sobrescribir lo que quiera en su propio paper-world.yml. Los tutoriales antiguos siguen mandando editar un paper.yml en la raíz, que en esas versiones ya no existe. En el archivo global casi todo se queda por defecto, y lo que justifica una edición es la integración con proxy, el limitador de paquetes y la carga de chunks. Las ganancias que la gente busca están en el archivo de mundo: rangos de despawn, mobs por jugador, colisión, tolvas e implementación de redstone. La sobrescritura por mundo es el recurso más desaprovechado. Un mundo de minería aguanta despawn agresivo y simulación corta sin que nadie se queje, mientras el survival principal se queda conservador. Aplicar la misma configuración agresiva a todos los mundos convierte la optimización en un ticket de soporte. ## La trampa de la configuración copiada ya hecha Ese archivo optimizado que circula por los foros aplica decenas de cambios de golpe. Funciona en el servidor de quien lo escribió. En el tuyo, dos o tres de esas claves van a romper algo, y no tendrás forma de saber cuáles porque lo pegaste todo junto. Los destrozos son previsibles. Un despawn muy corto sumado a un rango de spawn reducido genera la queja clásica de que no nacen mobs para farmear. Un rango de activación demasiado bajo hace que el mob deje de caminar y la granja se pare con él. Quitarles la inteligencia a los mobs de spawner mata mecánicas que dependen del movimiento. Un radio de fusión alto cambia cómo se agrupan los drops en el suelo. Y cambiar la implementación de redstone altera el orden de actualización de los cables, lo bastante para que una contraption sensible al timing cambie de comportamiento. Acepta también que buena parte de la ganancia no está en ningún yml. El plugin pesado casi nunca es el del jar más grande, sino el que consulta la base de datos de forma síncrona en cada evento, recorre entidades en una tarea repetida o fuerza carga de chunks fuera del camino asíncrono. Infraestructura ## Qué optimiza Paper de verdad * Carga y generación de chunks fuera del hilo principal, sacando del tick una de las operaciones más caras del servidor original. * Ticking de entidades, tolvas y colisiones con atajos que Spigot no tiene, además de un mobcap contado por jugador en lugar de global. * Una capa de API propia sobre Bukkit, que los plugins modernos usan para programar trabajo sin frenar el tick. * El bucle de tick sigue en un solo hilo. La frecuencia por núcleo pesa más que la cantidad de núcleos, y el Ryzen 9 9950X con DDR5 abre holgura de mspt. Casos de uso ## Perfiles de servidor donde esta elección importa * Survival con economía, protección de terreno y registro de bloques, donde el cuello de botella es la escritura en disco dentro del tick, no la falta de RAM. * Servidor de evento con pico de entidades, ítems en el suelo y mobs concentrados en una región pequeña. * Spawn de autor lleno de redstone y tolvas, donde la configuración del mundo pesa más que el plan contratado. * Backend de network detrás de un proxy, donde cada instancia necesita un mspt previsible para que el proxy no acumule cola. Optimización ## Claves de configuración que merecen la pena * En server.properties, simulation-distance recorta trabajo de tick de verdad. view-distance cuesta ancho de banda y envío de chunks, no procesamiento. * En paper-world-defaults.yml, los rangos de despawn, el per-player-mob-spawns y el límite de colisión por entidad resuelven la mayoría de los casos de exceso de entidades. * En spigot.yml, entity-activation-range y merge-radius tienen efecto inmediato, y son también los que más rompen granjas cuando te pasas. * Las Aikar flags actúan sobre la pausa del recolector de basura de la JVM, no sobre el coste de plugin dentro del tick. Confundir ambas cosas quema tiempo de diagnóstico. Ficha técnica ## Números para dimensionar antes de contratar Datos de plan y de operación, sin estimaciones. Línea Performance Desde R$ 54/mes con 4GB DDR5 Ryzen 9 9950X, indicada cuando el mspt ya lo dominan plugins y entidades. Pagando por año R$ 48,60/mes en el 4GB El anual descuenta un 10% y el trimestral, un 4%. CPU asignada 300% en el plan de 4GB Tres núcleos. El tick usa uno, el resto atiende chunks asíncronos, recolección de basura y disco. Disco en el plan de entrada 30GB NVMe Mantiene el autosave y la lectura de archivos de región lejos del camino crítico. Valoración pública 4,7 de 5 en Trustpilot, con 45 valoraciones Comparativa ## Spigot, Paper y Purpur uno al lado de otro Los tres corren plugins de Bukkit. La diferencia está en cuánto del servidor se reescribió y en cuánto comportamiento original aceptas perder a cambio. | Elemento | Spigot | Paper | Purpur | | -------------------------------------------- | -------------------------------- | ------------------------------------------ | ---------------------------------------------- | | API de plugins | Bukkit y Spigot | Bukkit y Spigot, más capa propia | Todo lo de Paper, más extensiones | | Chunks fuera del hilo principal | No tiene | Tiene | Heredado de Paper | | Claves de rendimiento | Pocas, en spigot.yml | Muchas, separadas entre global y mundo | Las de Paper y decenas de opciones de mecánica | | Riesgo de alterar el comportamiento original | Bajo | Medio, según lo que actives | Alto si vas activando opciones sin leer | | Cuándo elegirlo | Plugin muy antiguo sin sustituto | Estándar para servidor público con plugins | Cuando personalizar mecánicas es el objetivo | Paper es el término medio previsible. Purpur solo compensa si vas a usar las opciones extra a propósito, y cada una de ellas es una decisión de jugabilidad antes que de rendimiento. Paso a paso ## Flujo para investigar una caída de TPS El orden importa: cada paso descarta una hipótesis antes del siguiente. 1. 01 ### Confirma que el problema es de tick Mira el mspt en la consola o en el panel. Por debajo de 50 con el jugador todavía quejándose, la investigación pasa a red, proxy o cliente. 2. 02 ### Lee la distribución en lugar de la media Compara el valor mediano con el percentil 95. Un pico aislado apunta a autosave, tarea programada o generación de terreno. Un valor alto y constante apunta a entidades, tolvas o código que corre en cada evento. 3. 03 ### Perfila durante el pico real Timings se jubiló en Paper y spark ocupó su lugar, integrado en las versiones actuales y disponible como plugin en las antiguas. Empieza la muestra con el servidor lleno. Un perfil con el servidor vacío no enseña lo que estás cazando. 4. 04 ### Separa coste de plugin de coste de mundo Mira si el tiempo está en código de plugin o en el ticking de entidades y chunks del servidor. Antes de editar archivos, cuenta entidades: ítems en el suelo y animales acumulados explican buena parte de las caídas. 5. 05 ### Cambia una cosa y vuelve a medir Aplica un ajuste, vuelve al mismo horario de carga y compara el mismo percentil. Sin la segunda medición no sabes si mejoró o si el pico cambió de hora. Lista de comprobación ## Antes de aplicar una configuración que encontraste ya hecha Cinco comprobaciones que evitan la semana perdida averiguando qué clave rompió qué. * Apunta el mspt mediano y el percentil 95 de ahora, con el servidor lleno, para tener un antes. * Haz copia de seguridad del mundo y de la carpeta config antes de editar cualquier archivo. * Comprueba la versión de Paper: el material antiguo cita archivos y claves que ya no existen. * Divide los cambios por tema, como entidades, chunks, redstone y red, y aplica un grupo cada vez. * Prueba las granjas y las contraptions del spawn después de tocar el rango de activación o la redstone. ## Preguntas frecuentes 01 ¿Un plugin hecho para Spigot funciona en Paper? Funciona. Paper conserva la API de Bukkit y de Spigot, así que el jar arranca sin recompilar. El camino inverso no siempre vale: un plugin que use la capa exclusiva de Paper no corre en Spigot puro. 02 ¿Dónde están los archivos de configuración de Paper? A partir de Paper 1.19 están en la carpeta config, separados en paper-global.yml, para todo el servidor, y paper-world-defaults.yml, para los mundos, con sobrescritura individual en paper-world.yml. El contenido antiguo todavía menciona un paper.yml en la raíz, que en esas versiones no existe. 03 ¿Cómo descubrir qué plugin está tumbando el TPS? Perfilando con el servidor en carga real. Un informe agrupado por plugin a veces acusa a quien solo disparó una operación cara del propio servidor, así que revisa la pila de llamadas antes de desinstalar nada. 04 ¿Que el TPS marque 20 significa que todo está bien? No necesariamente. El TPS tiene techo en 20, así que un servidor gastando 45 milisegundos por tick sigue marcando 20. Vigila el mspt: por debajo de 50 hay holgura, y es el tamaño de esa holgura el que decide si el siguiente evento pesado tumba el servidor. 05 ¿Merece la pena copiar una configuración optimizada ya hecha? Sirve como lista de claves para estudiar, no para pegar. Valores agresivos de despawn, de rango de activación y de fusión de ítems cambian el spawn de mobs y el funcionamiento de las granjas. Aplícalos en grupos pequeños y mide el mspt antes y después de cada grupo. Sigue por aquí ## Guías para ejecutar lo que se describe aquí * [Cómo reducir el lag en un servidor Paper TPS y mspt en la práctica, con las claves en el orden en que valen la pena.](https://streethosting.com.br/es/guias/minecraft/como-reduzir-lag-servidor-paper) * [Analizar el lag con el spark profiler Cómo tomar la muestra y leer el resultado sin acusar al plugin equivocado.](https://streethosting.com.br/es/guias/minecraft/spark-profiler-analisar-lag-minecraft) * [Paper contra Spigot en producción Qué cambia en el día a día cuando cambias el jar del servidor.](https://streethosting.com.br/es/guias/minecraft/paper-vs-spigot-servidor-minecraft) * [Purpur contra Paper Cuándo compensan las opciones extra y cuándo solo crean bugs de jugabilidad.](https://streethosting.com.br/es/guias/minecraft/purpur-vs-paper-servidor-minecraft) 4.7/5 en Trustpilot Garantía o reembolso Activación en 60 s Soporte Premium Avalado por más de 2.500 clientes ## Qué acompaña al plan * Panel con consola, reinicio e historial de consumo, donde el pico aparece antes de convertirse en queja. * Soporte en portugués acostumbrado a leer perfiles de rendimiento e informes de crash. * Ampliación de RAM sin migración manual cuando la economía y el registro de bloques crezcan. [Ver planes para correr Paper](https://streethosting.com.br/es/minecraft-pro#plans) [Contactar con soporte](https://streethosting.com.br/es/contact) Ninguna configuración ya hecha sustituye una medición tuya: mide, cambia una clave, vuelve a medir.