Las flags de Aikar cambian a los 12 GB: cinco de ellas, y una disminuye
Copiar un conjunto de flags de 4 GB en un servidor de 16 GB deja cinco valores incorrectos. Aquí te mostramos exactamente cuáles son esos cinco, además del número de jugadores en el que un servidor con mods cruza la línea y uno vanilla no.
Las flags de Aikar son los argumentos JVM estándar de la comunidad para un servidor Paper, y suelen copiarse como un bloque. Pero no son un bloque: de los veinte argumentos, cinco cambian dependiendo de si tu heap es inferior o superior a 12 GB. Pegar un conjunto de flags para un heap pequeño en un servidor con un heap grande es la forma más común de ejecutar "las flags recomendadas" y no obtenerlas.
Las cinco que cambian
| flag | menos de 12 GB | 12 GB o más |
|---|---|---|
-XX:G1NewSizePercent | 30 | 40 |
-XX:G1MaxNewSizePercent | 40 | 50 |
-XX:G1HeapRegionSize | 8M | 16M |
-XX:G1ReservePercent | 20 | 15 |
-XX:InitiatingHeapOccupancyPercent | 15 | 20 |
G1ReservePercent es la que disminuye. Cuatro de las cinco aumentan con el tamaño del heap y esa disminuye, por lo que un "aumentar los números para un servidor grande" recordado a medias produce un conjunto incorrecto en lugar de uno meramente subóptimo. Reserva una fracción del heap contra fallos de evacuación, y un heap más grande necesita una fracción menor para mantener el mismo margen absoluto.
Los trece argumentos -XX: restantes son idénticos para cualquier tamaño de heap — -XX:+UseG1GC, -XX:MaxGCPauseMillis=200, -XX:+AlwaysPreTouch, -XX:SurvivorRatio=32, -XX:MaxTenuringThreshold=1 y el resto no se mueven. Solo -Xms y -Xmx siguen el tamaño del heap.
Dónde cae realmente la línea de los 12 GB
El generador de esta página dimensiona el heap según tu número de jugadores:
GB = clamp( ceil( (modded ? 2.5 : 1) × (2 + players / 12) ), 2, 32 )Los servidores con mods se presupuestan a 2.5× los vanilla, y ese factor decide quién llega a ver la rama de heap grande:
| jugadores | vanilla | con mods |
|---|---|---|
| 10 | 3 GB | 8 GB |
| 20 | 4 GB | 10 GB |
| 29 | 5 GB | 12 GB ← con mods cruza aquí |
| 50 | 7 GB | 16 GB |
| 100 | 11 GB | 26 GB |
| 109 | 12 GB ← vanilla cruza aquí | 28 GB |
Un servidor con mods alcanza las flags de heap grande con 29 jugadores. Uno vanilla no lo hace hasta los 109. Así que para la mayoría de las personas que ejecutan Paper vanilla, el conjunto de heap pequeño es el correcto permanentemente, y para la mayoría de las personas que ejecutan con mods, deja de ser correcto mucho antes de lo que esperan.
Dos límites en esa fórmula que vale la pena conocer
Nunca recomienda más de 32 GB. Vanilla alcanza el límite con 349 jugadores y se mantiene ahí. Esto no es un artefacto de redondeo: a partir de aproximadamente 32 GB, la JVM pierde los punteros de objetos comprimidos y cada referencia en el heap se hace más grande, por lo que más RAM puede significar menos heap utilizable. Escalar más allá de ese punto es trabajo para un segundo servidor, no para uno más grande.
Nunca recomienda menos de 2 GB, incluso para un solo Jugador, porque el límite inferior es el software del servidor, no la población.
Y sea lo que sea que diga la fórmula: no le des a la JVM todo lo que tiene la máquina. -Xms y -Xmx se establecen al mismo valor aquí a propósito —un heap fijo evita que la JVM cambie de tamaño bajo carga— lo que significa que el número que elijas se reclama de inmediato y de forma permanente. Deja al sistema operativo 1-2 GB por los que no tenga que luchar contigo.