El problema
Las caídas de TPS en horas pico casi nunca tienen una sola causa. Granjas de mobs, redstone activa, chunks cargados y distancias de visualización altas se van sumando hasta que el servidor ya no se recupera.
La respuesta clásica es manual y pareja: matar entidades, recortar ajustes del mundo, bajar la view distance para todos. El lag desaparece, sí, pero el servidor se siente peor para todos, incluso para quienes no tenían la culpa.
Y la mayoría de las herramientas te obligan a elegir: o estás encima del servidor todo el día, o dejas que un automatismo agresivo decida por ti. Ninguna de las dos rutas termina bien.
Lo que un operador necesita es puntería: actuar solo sobre la fuente real del problema y revertir el cambio con el mismo cuidado.
La solución: cómo está armado
La idea es simple: observar antes de actuar, mitigar solo donde hace falta y revertir con cuidado. Cada capa decide por su cuenta.
AIMD Congestion Control
El sistema usa Additive Increase Multiplicative Decrease, el mismo principio del control de congestión de TCP: afloja poco a poco cuando hay margen y recorta de golpe bajo presión. Nadie tiene que calibrar esa curva a mano. Un umbral fijo sería frágil.
Circuit Breakers
Si una acción falla una y otra vez, el sistema deja de intentarla en vez de empeorar las cosas. Tres fallos abren el breaker y hay 120 segundos de pausa antes de reintentar. Es el mismo patrón de los sistemas distribuidos, aplicado a un servidor de juego.
Regional Auto-Revert
Bajar la view distance global es un martillo. El auto-revert revisa si la zona concreta donde se aplicó la acción ya se recuperó, no el servidor entero. Así se revierte antes y con menos daño colateral.
Observer / Decision Separation
El Eye nunca decide y el orquestador nunca observa directamente. Gracias a eso se puede cambiar cualquier submotor sin tocar la telemetría, y cada dominio se observa a su propio ritmo sin frenar las decisiones.
El Eye: observabilidad en tiempo real
El Eye es la telemetría del plugin. Corre dentro del mismo proceso del servidor y muestra el estado en tiempo real, sin necesitar infraestructura externa.
Servidor
Tiempo de tick, uptime, estado de JVM
Memoria
Uso, libre, eventos de GC
Rendimiento
TPS, MSPT, varianza
Mundos
Entorno, tiempo, clima, conteos de chunks
Chunks
Cargados, simulados, forzados, hotspots
Entidades
Total, por tipo, tile entities
Jugadores
Mundo, distancia de visualización, ping
Red
Paquetes, ancho de banda
Mecánicas
Pistones, hoppers, redstone, generación de mobs
La mayoría de los plugins de optimización actúan a ciegas. Este observa primero.
Capacidades automáticas
En modo ACTIVE, el orquestador elige y aplica estas acciones según lo que está pasando en el servidor, sin que nadie toque nada.
Presión de entidades
- Pausa de IA de mobs por radio de chunk
- Fusión de items
- Despawning heurístico de items
- Límites dinámicos de spawn
- Simplificación de objetivos de mobs
Saturación de chunks
- Reducción de view distance por jugador
- Overrides por mundo y por región
- Ajuste de simulation distance
- Jerarquía de prioridad: admin override -> inmunidad -> tope por permiso -> región WorldGuard -> perfil activo -> heurística base
Redstone y mecánicas
- Throttle de actualizaciones de redstone (updates/sec)
- Throttle inteligente de hoppers
- Límites de activación de pistones
- Reducción de densidad de partículas
- Ajuste de entity tracking range
Soporte nativo para Folia
Folia trae ticks multihilo por región a los servidores Paper: regiones independientes del mundo corren en paralelo.
Ahí se rompen casi todos los plugins, porque asumen un solo hilo de tick. Su scheduler, su manejo de estado y sus accesos entre hilos no sobreviven a la ejecución por regiones.
Aurora Optimizer soporta Folia de forma nativa, no con un shim de compatibilidad. La capa de ejecución tiene implementaciones separadas para Paper y para Folia. Casi ningún plugin de optimización maneja Folia bien; este sí.
En la práctica
Red con rangos de usuario
Los jugadores VIP pagan por una mejor experiencia, pero sin priorización sufren el mismo lag que el resto en horas pico. Aurora aplica límites distintos por grupo de permisos y, bajo carga, degrada a todos en proporción: la diferencia entre rangos se mantiene.
Servidor survival con granjas pesadas
Las granjas de mobs son la causa más común de picos de lag. El sistema detecta los chunks saturados, pausa la IA de los mobs solo ahí y revierte el cambio cuando la densidad vuelve a la normalidad. Nadie del staff interviene, y los jugadores fuera de la granja ni se enteran.
Diagnóstico de lag inexplicable
El modo análisis corre una sesión completa sin tocar nada, solo mirando. Al final entrega un reporte con las causas que encontró y recomendaciones de configuración. Es el primer paso recomendado en un servidor nuevo.
Stack técnico
- Lenguaje
- Java 21
- Plataforma
- Paper 1.21.x / Folia 1.21.x (nativo)
- Dep. requerida
- ProtocolLib 5.3.0+
- Opcional
- LuckPerms · PlaceholderAPI · WorldGuard · Spark
- Configuración
- YAML + archivos de política .hopl (soporte hot-reload)
- API pública
- Sí: submotores externos y proveedores de métricas
- Analítica
- Solo opt-in, desactivada por defecto
Contacto
¿Te interesa para tu servidor o red?