⚡ Cómo Optimizar tu Servidor Minecraft 2026 — Guía Completa -90% Lag

📅 3 de Marzo, 2026 • ⏱️ 20 min lectura • 🏷️ Performance, Paper, JVM, Optimización

Si tu servidor de Minecraft tiene lag, baja TPS o crashea con muchos jugadores, esta guía te da las soluciones reales. Cubre desde los JVM flags de Aikar, configuración avanzada de Paper, Spigot y Bukkit, hasta límites de entidades y chunks. Con los ajustes de esta guía pasamos de 12 TPS a 19.8 TPS estables en producción con 60 jugadores y 30+ plugins activos.

  ⚡ Indicador clave: en Minecraft, 20 TPS = servidor perfecto. Por debajo de 15 TPS los jugadores notan lag. Por debajo de 10 TPS el servidor se vuelve injugable. Todo lo que sigue va orientado a mantener los 20 TPS constantes.

🧰 Antes de Empezar: Diagnóstico con Spark

No optimices a ciegas. Instala el profiler Spark (el mejor plugin gratuito de análisis de rendimiento para Paper/Spigot) y ejecuta:

/spark profiler start — inicia el profiler durante 2-3 minutos con jugadores activos
/spark profiler stop — genera un reporte online con exactamente qué consume tu CPU
/spark tps — muestra TPS actual y uso de RAM en tiempo real
/spark health — resumen de estado general del servidor

Con el reporte de Spark sabrás si el problema es un chunk, una entidad específica, un plugin mal programado o la JVM. Sin ese dato estás optimizando a ciegas.

🚀 Paso 1: JVM Flags de Aikar (El Cambio Más Impactante)

Los flags de la JVM controlan cómo Java gestiona la memoria. Los flags de Aikar son la configuración más probada para servidores de Minecraft y se usan en producción en miles de servidores. Reemplazan el clásico -Xms -Xmx básico con una gestión del garbage collector mucho más eficiente.

Para servidores con 10 GB de RAM o más:

java -Xms10G -Xmx10G \
  -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:+PerfDisableSharedMem \
  -XX:MaxTenuringThreshold=1 \
  -Dusing.aikars.flags=https://mcflags.emc.gs \
  -Daikars.new.flags=true \
  -jar paper.jar nogui

Para servidores con menos de 10 GB de RAM (ajusta -G1HeapRegionSize):

java -Xms6G -Xmx6G \
  -XX:+UseG1GC \
  -XX:+ParallelRefProcEnabled \
  -XX:MaxGCPauseMillis=200 \
  -XX:+UnlockExperimentalVMOptions \
  -XX:+DisableExplicitGC \
  -XX:+AlwaysPreTouch \
  -XX:G1NewSizePercent=30 \
  -XX:G1MaxNewSizePercent=40 \
  -XX:G1HeapRegionSize=4M \
  -XX:G1ReservePercent=20 \
  -XX:G1HeapWastePercent=5 \
  -XX:G1MixedGCCountTarget=4 \
  -XX:InitiatingHeapOccupancyPercent=15 \
  -XX:G1MixedGCLiveThresholdPercent=90 \
  -XX:G1RSetUpdatingPauseTimePercent=5 \
  -XX:SurvivorRatio=32 \
  -XX:+PerfDisableSharedMem \
  -XX:MaxTenuringThreshold=1 \
  -jar paper.jar nogui

Regla de oro: pon -Xms y -Xmx al mismo valor para que Java no redimensione el heap en runtime (costoso). Si tienes 8 GB para el servidor, usa ambos a 8G.

🗂️ Paso 2: Configurar bukkit.yml

El archivo bukkit.yml controla el spawn de mobs y algunos ciclos del servidor. Las opciones más importantes:

spawn-limits:
  monsters: 50      # vanilla: 70 — reduce hasta 50 en servidores grandes
  animals: 10       # vanilla: 10
  water-animals: 5  # vanilla: 15
  water-ambient: 2  # vanilla: 20
  water-underground-creature: 3
  ambient: 1        # murciélagos, útiles cero

chunk-gc:
  period-in-ticks: 400   # descarga chunks sin jugadores

ticks-per:
  animal-spawns: 400     # defaults 400, OK
  monster-spawns: 5      # no bajar de 5 o mobs no spawnean bien
  water-spawns: 11
  water-ambient-spawns: 21
  ambient-spawns: 21
  autosave: 6000         # autosave cada 5 min (6000 ticks)

⚙️ Paso 3: Configurar spigot.yml

Spigot añade opciones cruciales de rendimiento sobre Bukkit. Estas son las que más impactan:

world-settings:
  default:
    view-distance: 6          # VANILLA es 10 — MAYOR causa el lag
    simulation-distance: 4    # chunks que el servidor simula (independiente del view-distance)
    
    mob-spawn-range: 6        # rango de spawn de mobs en chunks
    
    entity-activation-range:  # entidades fuera del rango "duermen"
      animals: 32
      monsters: 32
      raiders: 48
      misc: 16
      water: 16
      villagers: 32
      flying-monsters: 32
    
    tick-inactive-villagers: false   # villagers fuera del rango = sin tick
    
    merge-radius:             # fusiona drops de items cercanos
      item: 3.5
      exp: 6.0
      
    item-despawn-rate: 6000   # items en suelo: 5 min (vanilla: 6000, OK)
    
    arrow-despawn-rate: 1200  # flechas: 1 min
    
    nerf-spawner-mobs: true   # mobs de spawners no tienen IA fuera del rango

📄 Paso 4: Configurar paper.yml (El Más Importante)

Paper tiene el sistema de configuración más avanzado. Estos ajustes son los que más TPS recuperan:

paper-world-defaults.yml (Paper 1.19+):

chunks:
  max-auto-save-chunks-per-tick: 6   # limita chunks que se guardan por tick
  prevent-moving-into-unloaded-chunks: true
  
entities:
  spawning:
    all-chunks-are-slime-chunks: false
    count-all-mobs-for-spawning: false
    
  behavior:
    allow-spider-world-border-climbing: false
    door-breaking-difficulty:
      husk: []
      vindicator: []
      zombie: []
    zombies-target-turtle-eggs: false    # evita que zombies busquen huevos de tortuga

misc:
  fix-climbing-bypassing-cramming-rule: true
  
hopper:
  cooldown-when-full: true   # hoppers llenas no gastan tick
  disable-move-event: true   # GRAN mejora si tienes muchas hoppers

max-growth-per-random-tick: 1  # plantas no crecen varias veces en un tick

🌍 Paso 5: View Distance y Simulation Distance

La view distance es la causa #1 de lag en servidores con muchos jugadores. Cada chunk a la vista = trabajo para el servidor.

👥

1-20 jugadores

view-distance: 8-10
simulation-distance: 6
Sin problemas con hardware decente.

👥

20-50 jugadores

view-distance: 6
simulation-distance: 4
Empieza a notarse la diferencia.

👥

50+ jugadores

view-distance: 4-5
simulation-distance: 3-4
Imprescindible reducir aquí.

Instala el plugin View Distance Tweaks para ajustar la view distance automáticamente según la carga del servidor: sube cuando hay pocos jugadores, baja cuando hay muchos. Totalmente transparente para los jugadores.

🐾 Paso 6: Limitar Mobs y Animales

Los mobs son el mayor consumidor de CPU en servidores survival. Controla cuántos pueden existir y en qué condiciones:

En paper-world-defaults.yml:

entities:
  spawning:
    per-player-mob-spawns: true  # distribuye los mob caps por jugador (MUY RECOMENDADO)
    spawn-limits:
      monster: 35   # Paper default 70 — 35 suele ser suficiente
      creature: 8
      ambient: 1
      axolotls: 3
      underground_water_creature: 3
      water_creature: 3
      water_ambient: 5

Añade el plugin ClearLag o usa el comando integrado de Paper /paper mobcaps para ver en tiempo real cuántos mobs hay activos en cada mundo.

🔌 Paso 7: Auditar Plugins

Un solo plugin mal programado puede consumir 30% de tu CPU. Usa Spark para identificarlo:

Ejecuta /spark profiler start --timeout 60
Abre el reporte y mira la sección "Server thread"
Expande los nodos con mayor porcentaje de tiempo
Si ves PluginName → EventHandler → onEntitySpawn con 15%+, ese plugin es el culpable

⚠️ Plugins que típicamente causan lag:

Plugins de partículas masivas: generan miles de paquetes por tick
anti-cheat mal configurados: revisan demasiados eventos por jugador
Plugins de economía con queries SQL síncronas: bloquean el thread principal
WorldGuard con regiones muy complejas: revisión de cada bloque costosa
Plugins de chat con funciones de placeholder lentas: llaman APIs externas sin caché

💾 Paso 8: Optimizar el Almacenamiento (Chunks y Mundo)

El I/O de disco puede generar lag de TPS si el disco es lento o hay demasiada actividad de chunks:

Usa SSD NVMe si tienes control del hardware. La diferencia vs HDD en lectura de chunks es brutal.
Pre-genera el mundo con Chunky: /chunky start genera un radio de 3000 bloques en background sin lag perceptible. Evita que jugadores exploren chunks nuevos (I/O intensivo) en peak hours.
Activa la compresión de red en server.properties: network-compression-threshold=256 (el valor por defecto 256 es razonable; reducirlo comprime más pero gasta CPU).

🔧 Paso 9: server.properties — Opciones Clave

# server.properties
view-distance=6
simulation-distance=4
network-compression-threshold=256
max-tick-time=60000      # evita que el watchdog mate el servidor en picos cortos
online-mode=true         # no cambies esto sin razón
max-players=50           # ajusta a tu capacidad real
entity-broadcast-range-percentage=75  # reduce paquetes enviados a clientes

📊 Monitorización Continua

Instala un stack de monitorización para saber ANTES de que los jugadores se quejen:

Spark (mencionado): profiling bajo demanda
Plan (plugin): dashboard web con TPS histórico, jugadores por hora, etc.
Timings: integrado en Paper — /timings report genera análisis detallado

✅ Checklist de Optimización Completa

✅ JVM flags de Aikar con -Xms = -Xmx
✅ view-distance ≤ 6 (ajustar según jugadores)
✅ simulation-distance ≤ 4
✅ per-player-mob-spawns: true
✅ spawn-limits reducidos a la mitad del vanilla
✅ tick-inactive-villagers: false
✅ hopper cooldown-when-full: true
✅ Mundo pre-generado con Chunky
✅ SSD en el servidor (no HDD)
✅ Spark instalado y revisado
✅ Plugins auditados — sin plugins que hagan queries SQL síncronas
✅ ClearLag o mob cap monitoring activo

🚀 ¿Quieres un servidor ya optimizado desde el día 1?

OliveerF Hosting entrega servidores Paper 1.21.11 con todos estos ajustes preconfigurados. Sin lag, sin configuración manual, listo en 2 minutos.

🎮 Ver planes de Hosting → 📄 Paper vs Spigot: ¿cuál usar?