El lag tiene causas concretas y soluciones concretas. Casi siempre se arregla sin gastar un peso más: la mayoría de servidores con tirones no necesitan más RAM, necesitan tres ajustes y quitarse de encima un plugin. Esta guía va en el orden en que hay que hacerlo, del cambio que más devuelve al que menos.
Antes de tocar nada: mide
Escribe /tps en la consola. Si marca 20, tu servidor va bien y el problema es la conexión del jugador, no el servidor. Si marca 15, 12 o menos, sigue leyendo. Anota el número: es tu punto de partida y sin él no vas a saber si lo que haces sirve.
Distingue dos cosas que la gente confunde todo el rato: TPS bajo es el servidor ahogado y lo sufren todos a la vez; ping alto es la distancia entre el jugador y el datacenter y lo sufre solo él. Los ajustes de abajo arreglan lo primero y no tocan lo segundo.
Los ajustes de server.properties que más pesan
view-distance: bájalo a 6-8. Es, con diferencia, el ajuste individual con más impacto. Cada punto de más multiplica los chunks que el servidor mantiene cargados por cada jugador.simulation-distance: 5 o 6 basta. Controla hasta dónde "vive" el mundo: cultivos, mobs, redstone. Es distinto de view-distance, que solo controla lo que se ve.max-players: ponlo en lo que tu plan aguanta de verdad. Un servidor con hueco para 100 y RAM para 20 va mal para los 20.network-compression-threshold: déjalo como está salvo que sepas qué haces.
Después de cambiar esto, reinicia y vuelve a mirar /tps. En muchos servidores el problema termina aquí.
Cambia a Paper o Purpur
Si sigues en Vanilla o Spigot, esto es lo siguiente. Paper es un fork de Spigot con muchísimas optimizaciones y, sobre todo, con archivos de configuración que te dejan limitar cosas que en Vanilla no se pueden tocar. Purpur va un paso más allá con aún más opciones. En el panel se cambia en un par de clics; haz respaldo antes.
Los ajustes de paper-world-defaults.yml que más rescatan un survival veterano:
- Rangos de activación de entidades (
entity-activation-range): reduce mobs, animales y monstruos. Bajarlos hace que los mobs lejanos dejen de calcular su IA. - Fusión de items y experiencia (
merge-radius): junta los items tirados en el suelo en vez de simular cada uno. - Límite de mobs por chunk: corta en seco las granjas desbocadas.
- Optimización de hoppers: los hoppers son de lo más caro que existe en Minecraft por unidad.
Arranca con las flags correctas
Java no libera la memoria de forma continua: la libera a ratos, y si lo hace mal el servidor se congela medio segundo cada pocos minutos. Eso son los "lag spikes" periódicos que no se explican mirando plugins. Las flags de Aikar reparten ese trabajo para que no se note. No hay que aprendérselas: nuestro generador de start te escribe la línea completa según la RAM de tu plan.
Pregenera el mapa
Generar terreno nuevo es lo que más CPU consume en todo Minecraft, y ocurre justo cuando un jugador está explorando. Pregenerar con Chunky lo elimina de raíz: el terreno ya existe en disco antes de que nadie llegue. Está paso a paso en cómo pregenerar el mapa con Chunky. Acompáñalo siempre de un borde de mundo, o los jugadores saldrán de la zona generada y volverá el problema.
Granjas, entidades y hoppers
En servidores survival con meses de vida, esta suele ser la causa real. Granjas de mobs gigantes, miles de items en el suelo, cientos de hoppers encadenados y villagers acumulados en un espacio pequeño. Un solo jugador con una granja mal hecha puede tirar el TPS de todo el servidor.
Búscalas antes de prohibirlas: con los límites de Paper por chunk y una charla con el dueño de la granja suele bastar. Prohibir granjas en un survival es matar media diversión.
Los plugins sospechosos
Menos plugins es más TPS, pero no todos pesan igual. Los que más problemas dan en la práctica son los de protección de terreno mal configurados, los que guardan datos en disco cada tick, los de dynmap sin limitar y cualquiera que lleve años sin actualizarse. Revisa también los que hacen tareas programadas: un plugin que recorre todos los chunks cada minuto arruina un servidor entero él solo.
Caza al culpable con Spark
Si después de todo lo anterior sigue habiendo lag, deja de adivinar. Instala Spark, ejecuta /spark profiler start mientras el servidor va mal, déjalo unos minutos y para con /spark profiler stop. El reporte dice exactamente qué plugin, qué granja o qué chunk se está comiendo el tick.
El reporte de Spark es denso y se lee raro la primera vez. Pega el enlace en nuestro analizador de Spark y te lo traduce a recomendaciones concretas.
Cuándo el problema no eres tú
Hay un punto en el que la configuración ya no da más de sí. Señales de que el límite es el hardware y no tus ajustes: el TPS cae en cuanto entran jugadores aunque el mundo esté pregenerado y limpio, la RAM va al tope constantemente, o el proveedor mete 40 servidores en una máquina pensada para 15. En modpacks pesados esto llega antes: un pack de 300 mods pide de 8 GB para arriba y no hay ajuste que lo evite.
Lo que manda en Minecraft es el rendimiento en un solo núcleo, no el número de núcleos: el tick principal del servidor corre en un hilo. Por eso una CPU moderna a 4,5 GHz mueve mejor un servidor que una de servidor con 32 núcleos lentos. Lo desarrollamos en hosting de Minecraft sin lag.
Checklist rápida
- Mide el TPS y anótalo.
- view-distance 6-8, simulation-distance 5-6.
- Pásate a Paper o Purpur.
- Arranca con las flags de Aikar.
- Pregenera con Chunky y pon borde de mundo.
- Limita entidades y revisa granjas.
- Quita plugins muertos o mal configurados.
- Si sigue mal: Spark, y ahí ya sabrás si es tu servidor o tu proveedor.