Cómo optimizar tu servidor de Minecraft contra el lag (Guía 2026)

Si tu servidor de Minecraft se traba en cuanto tres o cuatro jugadores empiezan a construir, minar o pelear al mismo tiempo, el problema casi nunca es “solo necesito más RAM”. El lag en un servidor de Minecraft casi siempre viene de tres sitios: una CPU insuficiente que no da abasto con los cálculos de tick en un solo hilo, un runtime de Java mal configurado, o datos del mundo que se dejaron crecer sin control durante meses. Esta guía repasa los tres, en el orden que realmente marca la diferencia.

Nada de esto requiere cambiar de proveedor de hosting ni gastar más dinero. Casi todo lo siguiente es gratis, toma menos de una hora, y aplica tanto si tienes un mundo de supervivencia pequeño para amigos como si administras un servidor público con 30+ jugadores simultáneos.

Por qué el lag de Minecraft no es realmente un problema de RAM

El bucle de tick del servidor de Minecraft corre en un solo hilo de CPU. Cada circuito de redstone, cada cálculo de pathfinding de un mob, cada chunk que necesita generarse y cada actualización de bloque se encolan en ese único hilo, 20 veces por segundo. Si el hilo no logra terminar su trabajo dentro de 50 milisegundos, el servidor “se atrasa” — eso es el tirón y el rubber-banding que sienten los jugadores.

La RAM evita crashes y pausas de garbage collection, pero no acelera ese hilo único. Por eso un servidor con 16GB de RAM puede seguir lageando mal si la velocidad de reloj por núcleo de la CPU es débil, o si el mundo está mal optimizado. Arregla primero los cuellos de botella ligados a la CPU — casi siempre son gratis.

Paso 1: Cambia a Paper (si no lo has hecho)

Los servidores vanilla y Spigot procesan cada entidad y chunk exactamente como lo escribió Mojang, sin atajos. Paper es un jar de servidor de reemplazo directo que mantiene compatibilidad total de plugins y de jugabilidad, pero reescribe partes enormes del bucle de tick para mejorar el rendimiento — seguimiento de entidades más inteligente, carga de chunks asíncrona, y docenas de optimizaciones configurables que vanilla ni siquiera expone.

Si sigues en vanilla o Spigot, este único cambio típicamente recupera más rendimiento que cualquier mejora de hardware. Descarga la última build de Paper para tu versión de Minecraft desde papermc.io, reemplaza el jar y reinicia — tu mundo, playerdata y la mayoría de los plugins se mantienen sin modificación.

Paso 2: Configura los flags correctos de Java

Cómo arrancas el servidor importa casi tanto como el hardware detrás. El garbage collector por defecto de Java nunca fue diseñado para una aplicación en tiempo real que hace tick 20 veces por segundo, y va a pausar periódicamente todo el servidor para hacer garbage collection — esto es lo que causa esos congelamientos aleatorios de medio segundo incluso en un servidor con poca gente.

El set de flags de Aikar (mantenido por uno de los desarrolladores originales de PaperMC) ajusta el garbage collector G1 específicamente para el patrón de asignación de memoria de Minecraft. Reemplaza tu comando de arranque actual por este, ajustando tu asignación real de RAM:

java -Xms6G -Xmx6G -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:MaxTenuringThreshold=1 -jar paper.jar nogui

Dos cosas importan aquí. Primero, siempre pon -Xms y -Xmx en el mismo valor — dejar que el heap cambie de tamaño dinámicamente causa sus propias pausas. Segundo, no asignes más RAM de la que el servidor necesita; un error común es asignar 12-16GB a un mundo de supervivencia pequeño, lo cual en realidad alarga las pausas de garbage collection porque hay más heap que escanear. Para la mayoría de servidores con menos de 20 jugadores, 4-8GB es suficiente.

Paso 3: Ajusta paper-world-defaults.yml

Paper expone docenas de configuraciones que cambian un poco de precisión vanilla por una gran cantidad de rendimiento. La mayoría de los jugadores nunca notan la diferencia; tu tick timer sí. Estas viven en config/paper-world-defaults.yml (o paper.yml en versiones más antiguas de Paper):

• entity-per-chunk-save-limit — limita cuántas entidades (ítems, mobs, minecarts) se guardan por chunk, evitando que granjas de duplicación de ítems o mataderos de mobs disparen el tiempo de guardado del mundo.
• mob-spawner-tick-rate — los spawners por defecto hacen tick cada ciclo; subir esto a 2-4 reduce la carga relacionada a spawners sin cambio visible en la jugabilidad.
• configuración de tick/transferencia de hoppers — las granjas con muchos hoppers son una de las mayores fuentes silenciosas de lag en servidores de supervivencia. Bajar ligeramente la velocidad de tick de los hoppers reduce dramáticamente la carga en construcciones de clasificación de ítems.
• non-player-arrow-despawn-rate e item-despawn-rate — tiempos de desaparición más cortos para ítems tirados y flechas perdidas evitan que el conteo de entidades crezca durante sesiones concurridas.

Cambia estas configuraciones gradualmente y reinicia entre cambios — ajustar diez configuraciones a la vez hace imposible saber qué realmente ayudó.

Paso 4: Diagnostica antes de adivinar

No ajustes a ciegas. Paper incluye dos comandos que te dicen exactamente a dónde se va el tiempo de tick en lugar de dejarte adivinando:

• /tps — muestra tus ticks por segundo de los últimos 1, 5 y 15 minutos. Cualquier valor consistentemente por debajo de 19 significa que el servidor se está atrasando.
• /timings report — genera un desglose completo de exactamente qué plugins, entidades o regiones del mundo están consumiendo tiempo de tick, con un enlace compartible. Esta es la herramienta de diagnóstico más útil disponible y toma menos de 2 minutos en ejecutarse.

Corre un reporte de timings antes de hacer cualquier cambio, y otro después. Si un plugin específico o una región del mundo aparece consistentemente arriba de la lista, ese es tu cuello de botella real — no lo que asumiste que era.

Paso 5: Limpia el mundo en sí

Los mundos que llevan meses en uso acumulan chunks que se generaron una vez, se exploraron y nunca se volvieron a visitar. Cada uno de esos chunks se sigue cargando, guardando y procesando si una entidad o jugador anda cerca. Dos herramientas gratuitas arreglan esto:

• MCA Selector o la función Prune-chunks de algunos paneles te permite borrar chunks que la comunidad de jugadores nunca exploró, reduciendo el tamaño del mundo y el tiempo de carga sin tocar construcciones cerca del spawn.
• view-distance y simulation-distance en server.properties — bajar view-distance del valor por defecto (a menudo 10) a 6-8 reduce dramáticamente la sobrecarga de carga de chunks con un impacto visual mínimo para la mayoría de los jugadores, y simulation-distance controla qué tan lejos realmente hacen tick las entidades/redstone, lo cual importa incluso más que view-distance para la carga de CPU.

Preguntas frecuentes

¿Los flags de Aikar funcionan en cualquier host?

Sí — son solo argumentos de arranque de Java, así que funcionan en cualquier host que te deje editar el comando de inicio, incluyendo configuraciones VPS autoadministradas. Algunos hosts administrados con un script de arranque fijo (ciertos paneles de hosting compartido económico) puede que no te dejen editar los flags directamente; revisa primero la sección de configuración de Java/JVM de tu panel.

¿Qué tanto view-distance debería usar realmente?

8 es un valor por defecto razonable para la mayoría de servidores de supervivencia. Baja a 6 si estás limitado en CPU y corres 15+ jugadores; sube a 10+ solo si tienes margen de CPU de sobra y los jugadores se quejan específicamente del pop-in.

¿Necesito cambiar de host para arreglar el lag?

Usualmente no. Los pasos anteriores arreglan la mayoría de las quejas de lag sin tocar el hardware. Si ya aplicaste Paper, los flags de Aikar y la limpieza del mundo, y /timings muestra que el tiempo de tick es genuinamente limitado por CPU sin un culpable único, ese es el punto donde un host con una CPU de núcleo más rápido realmente ayuda.

Conclusión

Las soluciones de lag funcionan mejor en orden: cambia a Paper si no lo has hecho, aplica los flags correctos de JVM, ajusta el puñado de configuraciones de world-defaults que importan, diagnostica con /timings en lugar de adivinar, y limpia chunks y view-distance al final. La mayoría de servidores que “necesitan mejor hosting” en realidad solo necesitan estos cinco pasos bien hechos — pruébalos antes de gastar dinero en más hardware.