Aikar Flags para Paper

Aikar Flags para Paper guía de JVM flags y memoria sin lag

Si administras un server de Minecraft (Paper/Purpur) y tu TPS pega brincos raros, el 80% de las veces el villano es GC (Garbage Collection) mal “alimentado” o memoria mal asignada. Ahí entran las Aikar Flags: un set de flags para la JVM pensado para que Paper corra más estable, con pausas más controladas y menos “lag spikes”.

Qué son las Aikar Flags

Paper las define directo: son flags de inicio de la JVM diseñadas para mejorar rendimiento del servidor. El enfoque principal es ajustar G1GC y comportamiento de memoria para el patrón típico de Minecraft (muchas asignaciones, objetos de vida corta, etc.).

Cuándo vale la pena usarlas (y cuándo no)

Úsalas si:

Corres Paper/Purpur con plugins, mundos pesados, y buscas estabilidad.
Tienes suficiente RAM para que G1GC trabaje cómodo (Paper recomienda bastante margen).

Piénsalo dos veces si:

Tu server es mini, sin plugins, y ya va fino. En JVM modernas, muchas cosas ya vienen bastante optimizadas “de fábrica” (y over-tunear puede ser ruido).
Aun así, Paper sigue publicando estas flags como baseline recomendado, así que no estás haciendo brujería: estás siguiendo doc oficial.

Flags recomendadas oficiales para Paper

Paper incluye un comando recomendado (ejemplo con 10G). La idea clave: Xms = Xmx, usar G1GC, y activar varios ajustes para pausas y regiones de heap.

Ejemplo (ajusta el jar y la memoria a tu caso):

java -Xms10G -Xmx10G -XX:+UseG1GC -XX:+ParallelRefProcEnabled -XX:MaxGCPauseMillis=200 -XX:+UnlockExperimentalVMOptions -XX:+DisableExplicitGC -XX:+AlwaysPreTouch -XX:G1NewSizePercent=30 -XX:G1MaxNewSizePercent=40 -XX:G1HeapRegionSize=8M -XX:G1ReservePercent=20 -XX:G1HeapWastePercent=5 -XX:G1MixedGCCountTarget=4 -XX:InitiatingHeapOccupancyPercent=15 -XX:G1MixedGCLiveThresholdPercent=90 -XX:G1RSetUpdatingPauseTimePercent=5 -XX:SurvivorRatio=32 -XX:+PerfDisableSharedMem -XX:MaxTenuringThreshold=1 -Dusing.aikars.flags=https://mcflags.emc.gs -Daikars.new.flags=true -jar paper.jar --nogui

¡20% de descuento en tu servidor!

Servidores de alto rendimiento para una experiencia de juego fluida. Configura hoy tu servidor y obtén 20% de descuento el primer mes.

Comienza hoy

Ese bloque sale tal cual en la doc de Paper (solo cambia el tamaño y el jar).

Por qué Xms debe igualar a Xmx (en cristiano)

Paper lo explica así: si tu Xms es menor que Xmx, dejas memoria “sin usar” al inicio y la JVM anda ajustando el heap en caliente. Con G1GC, darle un heap estable ayuda a mantener pausas más consistentes.

Cuánta RAM asignar (y el error que tumba servers)

Dos reglas prácticas que Paper recalca:

No asignes toda la RAM que “tienes” en hosts compartidos. Java + el OS necesitan overhead.
Como guía, baja Xmx/Xms ~1000–1500MB por debajo de tu RAM “total” para no provocar OOM / OOMKiller.

Y sobre “cuánta RAM es buena”: Paper recomienda mínimo 6–10GB aunque tengas pocos jugadores, porque G1GC suele rendir mejor con más memoria disponible (hasta cierto punto; después hay rendimientos decrecientes).

Cómo generar tu script sin equivocarte

Paper literalmente te dice “si quieres generar un script, usa el generador”.
Y si quieres un generador directo de scripts de arranque, flags.sh te arma el start script (y recomienda al menos 4GB de RAM como base).

Generador: https://flags.sh/

GC logging para diagnosticar lag (no adivinar)

Si sospechas que el lag viene de GC (picos de CPU, pausas, “rubber banding” sin razón), activa logs.

Paper da flags de logging por versión:

Java 11+:

-Xlog:gc*:logs/gc.log:time,uptime:filecount=5,filesize=1M

Paper menciona que el GC logging no debería afectar rendimiento y que los logs no ocupan mucho espacio.

Errores típicos con Aikar Flags (speedrun a tickets)

Poner Xmx gigante “porque sí”: más RAM no siempre = más rendimiento; llega un punto donde solo desperdicias.
Asignar toda la RAM del host al Xmx: clásico “se murió el server y no sé por qué”. Overhead + OS existen.
No medir: si no estás revisando timings o GC logs, estás tuneando a ciegas.

Conclusión

Las Aikar Flags siguen siendo un baseline sólido para servers Paper cuando quieres menos spikes y una JVM más “domesticada”, especialmente si traes plugins y carga real. Usa el set recomendado, asigna memoria con margen, y si hay lag: activa GC logging y decide con datos, no con vibes.