Generador de flags de Java para servidores de Minecraft

Por qué -Xms y -Xmx siempre deben ser iguales

-Xms fija el heap inicial que la JVM reserva al arrancar, y -Xmx el máximo al que puede crecer. En un servidor dedicado (que corre 24/7 y no comparte esa RAM con otra cosa) no tiene sentido dejar margen entre ambos: cada vez que la JVM necesita crecer el heap desde -Xms hacia -Xmx, tiene que pedirle más memoria al sistema operativo y reorganizar sus regiones internas, lo cual genera una pausa perceptible ("stop-the-world") justo cuando el servidor ya está bajo carga. Si -Xms y -Xmx son iguales desde el arranque, la JVM reserva todo el heap una sola vez y se evita ese resize por completo. La única desventaja es un arranque levemente más lento, que es un precio mucho menor que un lag spike con jugadores conectados.

Qué hace realmente el tuning de pausas de G1GC

G1GC (Garbage-First) divide el heap en regiones pequeñas y prioriza recolectar primero las que tienen más basura ("garbage first"), en vez de recorrer todo el heap de una vez como los recolectores más viejos. -XX:MaxGCPauseMillis=200 no es una garantía dura, es un objetivo: G1 ajusta dinámicamente cuántas regiones recolecta por ciclo para intentar no superar ese tiempo de pausa. Los flags de Aikar afinan además cuándo arranca el ciclo de recolección concurrente (InitiatingHeapOccupancyPercent=15, mucho antes que el 45% por defecto de la JVM) para que G1 tenga tiempo de sobra de limpiar basura antes de que el heap se llene y fuerce una pausa larga "a las apuradas". Por eso ese set de flags reduce tanto los picos de lag en Paper/Spigot comparado con los valores por defecto de Java.

Más RAM no siempre es mejor: el problema del page cache

Este es un error muy común: asignarle a Java toda la RAM del VPS "para que sobre". El sistema operativo usa la RAM libre (la que no está reservada por ningún proceso) como caché de disco (page cache) para los archivos de región del mundo (.mca) que Minecraft lee y escribe constantemente. Si le das a -Xmx casi toda la RAM del servidor, no dejás espacio para ese caché, y el sistema operativo tiene que leer esos archivos de disco todo el tiempo en vez de servirlos desde memoria — lo cual genera MÁS lag de I/O, no menos, incluso con un heap de Java enorme y libre. La regla práctica: asignale a -Xmx la RAM que tu servidor realmente necesita según su cantidad de jugadores y mundos cargados, y dejá el resto de la RAM del VPS libre para el sistema operativo y el page cache.

¿Cuándo conviene ZGC y cuándo es overkill?

ZGC es un recolector de pausas ultra cortas (típicamente por debajo de 1ms) que logra eso haciendo casi todo su trabajo de forma concurrente, en paralelo con la ejecución normal del servidor. La contra es que ese trabajo concurrente consume más CPU y necesita heaps grandes para no tener que apurarse — con poca RAM (por debajo de 8-10 GB) suele rendir peor que un G1GC bien afinado, porque no tiene margen de sobra para trabajar con calma. Donde ZGC brilla de verdad es en servidores grandes (16 GB+ de heap, redes con muchos jugadores o modpacks pesados) donde los picos de pausa de G1, aunque raros, son inaceptables. Para un servidor chico o mediano con 4-16 GB, los flags de Aikar (G1GC afinado) casi siempre dan mejor resultado real.

Dónde va esto: en el script de arranque, no en server.properties

Estos flags son argumentos de la línea de comandos con la que arrancás el proceso de Java (start.sh en Linux, start.bat en Windows, o la variable JAVA_OPTS/STARTUP en un panel como Pterodactyl) — no se pegan dentro de server.properties, que sólo configura el juego en sí (puerto, dificultad, whitelist, etc.), nada relacionado a la JVM. Si usás un panel de hosting, buscá el campo de "comando de inicio" o "argumentos de Java" y pegá ahí el comando completo o sólo los flags, según lo que tu panel te pida.

Preguntas frecuentes