Cómo optimizar un servidor de Minecraft para que deje de laggear

Lo que suele pasar cuando alguien se pone a optimizar es esto: toca quince cosas de golpe, el servidor sigue igual de mal, y ya no hay manera de saber cuál de los quince cambios lo empeoró. Te va a costar menos trabajo hacerlo al revés, midiendo primero.

Primero, ¿de dónde viene el lag?

Hay tres cosas que la gente llama lag y no tienen nada que ver entre sí. Si estás en Paper o en algún fork, escribe /tps en la consola y fíjate en el número que te devuelve.

1. Si los TPS andan por debajo de 20 y se quedan ahí, el servidor no alcanza a procesar cada tick. Ese es el caso que cubre esta guía.
2. Si los TPS están en 20 pero los bloques que rompes reaparecen y los mobs se teletransportan, el problema está en la red. Eso se revisa aparte, en la latencia por región.
3. Si los TPS y el ping están bien y aun así la imagen va a saltos, entonces es tu computadora. Prueba bajando render distance, quitando shaders o instalando Sodium.

Menciono algo obvio porque se confunde muchísimo: los TPS son del servidor y los FPS son tuyos. Un servidor impecable se va a ver mal en una máquina vieja, y la mejor PC del mundo no le sube los TPS a un servidor saturado.

¿Qué es lo que normalmente se come el tick?

En los servidores que vemos casi siempre son las entidades. Después la carga de chunks y, ya más lejos, la redstone. La falta de memoria aparece bastante abajo en esa lista, aunque sea lo primero que uno sospecha.

Y cuando digo entidades no me refiero solo a los mobs. También cuentan los ítems tirados en el suelo, los marcos, los barcos y las armaduras puestas. Una granja mal armada con un cofre desbordado te tira un servidor de 16 GB sin ningún problema.

1. Instala spark y arranca el perfilador desde el chat con /spark profiler. Cuando lo detengas te va a dar un enlace con el desglose de qué ocupó cada tick.
2. De paso revisa /spark tps y /spark healthreport. El segundo te dice si el cuello está en la recolección de basura, en el disco o en la CPU, y eso te ahorra andar adivinando.
3. Si el perfil te señala una entidad o un chunk en concreto, ve directo ahí. En la mayoría de los casos el problema es uno solo y no hace falta cambiar ninguna configuración.

Ojo con las guías viejas: Paper ya trae spark integrado y quitó Timings, así que si te mandan a hacer /timings paste, ese comando ya no existe.

Ajustes de server.properties que sí valen la pena

1. view-distance en 6 o 7. De todo lo que puedes tocar es lo que más se nota con menos riesgo. Pasar de 10 a 6 puede dejar en la mitad los chunks que el servidor mantiene por cada jugador.
2. simulation-distance en 4. Separa lo que se ve de lo que se simula, así que los mobs y los cultivos solo trabajan cerca de alguien.
3. network-compression-threshold en 256. Si tus jugadores están más o menos en la misma región que el servidor, subirlo le quita carga a la CPU.
4. max-players en un número realista. Cada jugador conectado carga su propio juego de chunks, y ese costo no se reparte entre los demás.

Por si te da miedo bajar la distancia: con view-distance en 6 nadie se queja, porque el cliente sigue mostrando lo que ya recibió. En 4 sí se empieza a notar, y a partir de ahí conviene buscar el problema en otro lado.

¿Y en Paper qué toco?

Todo lo que sigue está en config/paper-world-defaults.yml. Son cuatro ajustes y entre ellos dan casi todo el resultado.

1. entity-activation-range: animals en 16 y monsters en 24. Lo que quede fuera de ese radio deja de tickear.
2. redstone-implementation en ALTERNATE_CURRENT. Si tu mundo tiene granjas con redstone, cambia a una implementación más eficiente sin alterar cómo se comportan.
3. ticks-per.hopper-transfer y ticks-per.hopper-check. Subirlos ayuda bastante cuando hay cadenas largas de hoppers, que es lo típico en servidores con muchas granjas.
4. max-auto-save-chunks-per-tick. Si notas un tirón que se repite cada tantos minutos, casi siempre es el autoguardado.

Una recomendación que te va a ahorrar dolores de cabeza: no copies un paper-world-defaults.yml completo de internet. Vienen con las decisiones del servidor de otra persona, y después uno acaba preguntándose por qué dejaron de aparecer los mobs.

¿No sería más fácil ponerle más RAM?

Es lo primero que uno piensa, pero normalmente no ayuda y a veces empeora las cosas. Mientras más memoria le asignas, más tarda el recolector de basura en cada limpieza, y esas pausas se sienten igual que un tirón.

La memoria sí se queda corta en dos situaciones concretas: cuando la consola te escupe un OutOfMemoryError, o cuando pasas de un mundo sencillo a un modpack de doscientos mods. Si andas en esa duda, en cuánta RAM necesita un servidor de Minecraft están los tramos con los que trabajamos.

Ya hice todo y sigue laggeando

Si llegaste hasta aquí con el perfil de spark limpio, lo que queda es el hardware. Y aquí hay un detalle que casi no se menciona: Minecraft procesa el mundo en un solo hilo, así que no importa tanto cuántos núcleos tengas como qué tan rápido va uno.

Por eso un VPS barato con ocho núcleos compartidos suele rendir peor que dos núcleos dedicados en un Ryzen reciente. En nuestro caso son Ryzen 9 9900X de 12 núcleos a 5.6 GHz con NVMe Gen4, y el disco pesa más de lo que parece, porque cargar chunks es leer del disco.

Si quieres comparar antes de mover nada, ahí están los planes y la latencia medida por país. Y si prefieres que le echemos un ojo a tu caso, mándanos el enlace de tu perfil de spark por ticket: con eso se identifica el problema en un par de minutos.