Minecraft Server Performance Master-Guide 2025: Vom Laggy-Server zur Hochleistungsmaschine

Du kämpfst mit TPS-Einbrüchen, Spieler-Laggs oder unerklärlichen Performance-Problemen? Dieser ultimative Guide zeigt dir jeden Schritt – von der Diagnose bis zur fortgeschrittenen Optimierung – um deinen Minecraft-Server in eine Hochleistungsmaschine zu verwandeln. Basierend auf jahrelanger Erfahrung mit tausenden Servern.

📊 KAPITEL 1: Diagnose – Wo genau liegt das Problem?

Bevor du optimierst, musst du genau wissen, WAS laggt. Minecraft hat drei Haupt-Lag-Arten:

1.1 TPS-Lag (Server-Lag)

mc

/tps
# Idealer Output: "20.0, 20.0, 20.0"
# Kritisch: "15.2, 14.8, 13.5"

Interpretation:

• 20.0: Perfekt

• 18.0-19.9: Leichte Probleme

• 15.0-17.9: Spürbare Laggs

• <15.0: Unspielbar

1.2 MSPT (Milliseconds Per Tick)

mc

/mspt
# Idealer Wert: <50ms
# Kritisch: >100ms

Das bedeutet:

• <20ms: Exzellent

• 20-50ms: Gut

• 50-100ms: Probleme

• >100ms: Kritisch (max 10 TPS möglich!)

1.3 Professionelle Profiling Tools 2025

a) Spark (Essential für Paper)

mc

/spark sampler --interval 30s
/spark heapdump
/spark gcmonitor

→ Zeigt dir genaue CPU-Auslastung pro Plugin/Entity

b) timings v2 (Bukkit/Paper)

mc

/timings paste

→ Detaillierte Analyse aller Tick-Aktivitäten

c) Chunky (Chunk-Analyse)

mc

/chunky info
/chunky cancel

→ Findet korrupte oder laggy Chunks

⚙️ KAPITEL 2: Java-Optimierung 2025 (Der größte Hebel!)

2.1 Java-Version wählen (2025 Update)

• Java 17: Stabilste für Paper 1.20+

• Java 21: 5-10% Performance-Boost, aber weniger getestet

• Java 8: NUR für alte Modpacks (<1.12.2)

2.2 Optimierte JVM-Flags für verschiedene Szenarien

A) Paper/Spigot Server (1.20+) – Standard-Optimierung

bash

java -Xms10G -Xmx10G -XX:+UseG1GC -XX:+ParallelRefProcEnabled \
-XX:MaxGCPauseMillis=200 -XX:+UnlockExperimentalVMOptions \
-XX:+DisableExplicitGC -XX:+AlwaysPreTouch -XX:G1HeapRegionSize=8M \
-XX:G1NewSizePercent=30 -XX:G1MaxNewSizePercent=40 \
-XX:G1HeapWastePercent=5 -XX:G1MixedGCCountTarget=4 \
-XX:InitiatingHeapOccupancyPercent=15 \
-XX:G1MixedGCLiveThresholdPercent=90 \
-XX:G1RSetUpdatingPauseTimePercent=5 -XX:SurvivorRatio=32 \
-XX:+PerfDisableSharedMem -XX:MaxTenuringThreshold=1 \
-XX:TargetSurvivorRatio=90 -XX:+UseStringDeduplication \
-XX:+UseCompressedOops -XX:+UseCompressedClassPointers \
-XX:CompressedClassSpaceSize=1G -XX:+UseFastUnorderedTimeStamps \
-XX:+UseAES -XX:+UseAESIntrinsics -XX:UseSSE=4 \
-XX:AllocatePrefetchStyle=1 -XX:+UseLoopPredicate \
-XX:+RangeCheckElimination -XX:+EliminateLocks \
-XX:+DoEscapeAnalysis -XX:+UseTypeSpeculation \
-XX:+UseNUMA -XX:+UseFPUForSpilling \
-XX:+UseVectorCmov -XX:+UseXMMForArrayCopy \
-XX:+UseTransparentHugePages -XX:LargePageSizeInBytes=2M \
-XX:+UseLargePages -Dfile.encoding=UTF-8 \
-jar paper-1.20.4.jar nogui

B) Modpack Server (Forge/Fabric) – Alternative Flags

bash

java -Xms8G -Xmx8G -XX:+UseG1GC -XX:+UnlockExperimentalVMOptions \
-XX:MaxGCPauseMillis=100 -XX:+DisableExplicitGC \
-XX:TargetSurvivorRatio=90 -XX:G1NewSizePercent=50 \
-XX:G1MaxNewSizePercent=80 -XX:G1MixedGCLiveThresholdPercent=35 \
-XX:+AlwaysPreTouch -XX:+ParallelRefProcEnabled \
-XX:+UseStringDeduplication -Dfml.readTimeout=180 \
-jar forge-1.20.1.jar nogui

2.3 Die Xms/Xmx-Falle verstehen

bash

# FALSCH (verursacht GC-Laggs):
java -Xms2G -Xmx10G ...

# RICHTIG (keine dynamische Allokation):
java -Xms10G -Xmx10G ...

Warum gleich? Dynamische RAM-Allokation verursacht Garbage Collection Spikes!

2.4 Garbage Collector Vergleich 2025

GC-Type	Für Server-Typ	Vorteile	Nachteile
G1GC	Paper/Modpacks	Balanciert, wenig Pausen	Komplexe Konfig
ZGC	>32GB RAM	Ultra-low Pausen	Nur Java 15+, experimentell
Shenandoah	Modpacks	Gute Pausenzeit	Etwas langsamer
Parallel	Vanilla	Einfach	Lange Pausen

🏗️ KAPITEL 3: Paper/Spigot Konfiguration (YML-Optimierung)

3.1 paper.yml – Kritische Sektionen

Chunk-System (Reduziert Chunk-Loading-Laggs)

yaml

chunks:
  max-auto-save-chunks-per-tick: 6
  fixed-chunk-inhabited-time: -1
  delay-chunk-unloads-by: 10s
  enable-frustum-chunk-priority: true
  global-max-chunk-load-rate: 500.0
  player-max-chunk-load-rate: 100.0
  max-concurrent-chunk-loads: 20
  chunk-load-override: none

Entity-Aktivierung (Massiver Performance-Boost)

yaml

entity:
  per-player-mob-spawns: true
  entities:
    spawning:
      spawn-limits:
        ambient: 15
        axolotls: 10
        water_ambient: 20
        water_underground_creature: 5
        creature: 30
        monster: 70
        water_creature: 15

Redstone-Optimierung (Verhindert Redstone-Laggs)

yaml

hopper:
  disable-move-event: false
  cooldown-when-full: true
  transfer-tick-rate: 8
  
redstone:
  disable-op-bucket: true
  piston-entity-collision: false

3.2 spigot.yml – World-Spezifische Einstellungen

yaml

world-settings:
  default:
    entity-activation-range:
      animals: 16
      monsters: 24
      raiders: 48
      misc: 8
      water: 8
      villagers: 16
      flying-monsters: 48
      tick-inactive-villagers: false
    
    mob-spawn-range: 4
    entity-tracking-range:
      players: 48
      animals: 48
      monsters: 48
      misc: 32
      other: 64

3.3 bukkit.yml – View-Distance Management

yaml

settings:
  allow-end: true
  warn-on-overload: true
  permissions-file: permissions.yml
  update-folder: update
  plugin-profiling: false
  connection-throttle: -1
  query-plugins: true
  deprecated-verbose: default
  shutdown-message: Server closed
  
spawn-limits:
  monsters: 70
  animals: 15
  water-animals: 5
  water-ambient: 20
  ambient: 15
  
chunk-gc:
  period-in-ticks: 600

🧩 KAPITEL 4: Plugin-Optimierung & Auswahl

4.1 Performance-Killer Plugins erkennen

Mit Spark analysieren:

mc

/spark sampler --thread * --interval 30s
# Suche nach:
# - "com.sk89q.worldguard" (oft langsam)
# - "Vault" (Economy-Plugins)
# - "Essentials" (bei vielen Commands)

4.2 Essential Performance-Plugins 2025

Plugin	Zweck	Performance-Impact
Spark	Profiling & Monitoring	Negligible
ClearLag	Entity/Item Cleaning	Positiv
Chunky	Chunk Loading Control	Positiv
ViaVersion	Cross-Version Support	Mittel
Plan	Analytics & Monitoring	Sehr gering
CoreProtect	Block Logging	Mittel (je nach Nutzung)

4.3 Plugin-Konfiguration optimieren

ClearLag Beispiel (aggressiv optimiert):

yaml

Clearlag:
  remove-ground-items: true
  ground-item-remove-time: 300
  check-time-in-seconds: 60
  remove-minecarts: true
  remove-boats: true
  remove-animals: false
  kill-mounted-mobs: true
  mob-removal-interval: 600

🗺️ KAPITEL 5: Welt-Optimierung & Chunk-Management

5.1 Chunk-Loading Strategien

Pre-generiere deine Welt:

mc

# Mit Chunky Plugin
/chunky start world 3000
# Erzeugt 3000x3000 Blöcke vor

Alternativ mit WorldBorder:

mc

/wb world set 3000
/wb fill 200

5.2 Laggy Chunks finden & reparieren

ChunkAnalyzer nutzen:

mc

/chunk analyze --threshold 50
# Findet Chunks mit >50 Entities

Korrupte Chunks reparieren:

1. Backup der Welt erstellen

2. MCA Selector (externes Tool) nutzen

3. Nur korrupte Chunks löschen

4. Mit Chunky neu generieren

5.3 Redstone-Laggs eliminieren

Problemquellen:

• Quarries (automatische Minen)

• Redstone-Clocks (schnelle Ticker)

• Mob-Farms mit vielen Entities

• Item-Sorters mit vielen Hopper

Lösungen:

yaml

# In paper.yml
redstone:
  disable-piston-griefing: false
  piston-push-limit: 12

💾 KAPITEL 6: RAM-Management & Allokation

6.1 Die perfekte RAM-Menge finden

Server-Typ	5-10 Spieler	20-30 Spieler	50+ Spieler
Vanilla	2-4 GB	4-6 GB	6-8 GB
Paper mit Plugins	4-6 GB	6-8 GB	8-12 GB
Modpacks (Light)	6-8 GB	8-10 GB	10-12 GB
Modpacks (Heavy)	8-10 GB	10-12 GB	12-16 GB

6.2 RAM-Überwachung & GC-Tuning

Garbage Collection überwachen:

bash

# JVM Flags für GC-Logging
-XX:+PrintGCDetails -XX:+PrintGCDateStamps \
-Xloggc:gc.log -XX:+UseGCLogFileRotation \
-XX:NumberOfGCLogFiles=5 -XX:GCLogFileSize=10M

GC-Logs analysieren:

bash

# Nach langen Pausen suchen
grep "Full GC" gc.log
# Idealer Wert: <200ms Pause

🔄 KAPITEL 7: Fortgeschrittene Techniken

7.1 Multi-World Performance

Problem: Jede zusätzliche Welt kostet Performance
Lösung:

yaml

# In paper.yml
world-settings:
  world_nether:
    environment: NETHER
    keep-spawn-loaded: false
  world_the_end:
    environment: THE_END
    keep-spawn-loaded: false

7.2 Network & Connection Optimierung

yaml

# server.properties
network-compression-threshold: 256
rate-limit: 0
max-tick-time: 60000

7.3 Automatische Performance-Skripte

Daily Maintenance Script:

bash

#!/bin/bash
# minecraft_maintenance.sh

SERVER_DIR="/opt/minecraft"
SCREEN_NAME="mcserver"

# 1. Save world
screen -S $SCREEN_NAME -X stuff "save-all\n"
sleep 5

# 2. Clear items
screen -S $SCREEN_NAME -X stuff "lag clear items\n"

# 3. Restart if TPS low
TPS=$(screen -S $SCREEN_NAME -X stuff "tps\n" && sleep 2)
if [[ $TPS < 15 ]]; then
    screen -S $SCREEN_NAME -X stuff "restart\n"
fi

# 4. Backup
tar -czf /backups/mc-$(date +%Y%m%d).tar.gz $SERVER_DIR/world

📈 KAPITEL 8: Monitoring & Alerting

8.1 Echtzeit-Monitoring mit Grafana + Prometheus

Setup:

1. mc-exporter auf Server installieren

2. Prometheus konfigurieren

3. Grafana Dashboard einrichten

Metriken überwachen:

• TPS (20 = Ideal)

• MSPT (<50ms = Ideal)

• Player Count

• Chunk Loads

• Entity Count

8.2 Discord Alerts einrichten

python

# discord_alert.py
import requests
import subprocess

WEBHOOK_URL = "your_webhook_here"

def check_tps():
    result = subprocess.run(['mc-tps-check'], capture_output=True)
    tps = float(result.stdout)
    if tps < 16:
        send_alert(f"⚠️ TPS Warning: {tps}")

def send_alert(message):
    requests.post(WEBHOOK_URL, json={"content": message})

🚀 KAPITEL 9: Wann ein Upgrade wirklich nötig ist

9.1 Upgrade-Checkliste

• TPS konstant < 16 trotz Optimierung

• RAM immer >90% Auslastung

• CPU konstant >80% Auslastung

• Spieler beschweren sich regelmäßig

• Alle oben genannten Optimierungen durchgeführt

9.2 Upgrade-Strategie

1. Mehr RAM zuerst (bis 12-16GB für Paper)

2. Bessere CPU (höhere Single-Core Performance)

3. NVMe SSD (für Chunk Loading)

4. Dedicated Server (bei >50 Spielern)

📋 KAPITEL 10: Quick-Start Performance Checklist

Jeden neuen Server durchgehen:

Basis-Check (10 Minuten)

• Java 17+ installiert

• Xms = Xmx gesetzt

• view-distance: 8

• simulation-distance: 6

• G1GC aktiviert

Erweiterte Optimierung (30 Minuten)

• paper.yml entity-limits gesetzt

• Spark installiert

• ClearLag konfiguriert

• Chunky pre-generierung gestartet

• Backup-System eingerichtet

Fortgeschritten (1 Stunde)

• GC-Logs aktiviert

• Monitoring eingerichtet

• Wartungs-Skripte erstellt

• Discord Alerts konfiguriert

🎯 ABSCHLUSS: Die Performance-Philosophie

Performance ist kein Zufall, sondern System. Die meisten Server benötigen kein Upgrade, sondern nur die richtige Konfiguration. Bevor du mehr Geld ausgibst:

1. Messen (TPS, MSPT, RAM)

2. Analysieren (Spark, Timings)

3. Optimieren (Java, YMLs, Plugins)

4. Monitorieren (Alerts, Logs)

Ein gut optimierter Server kann mit 50% weniger Ressourcen laufen als ein schlecht konfigurierter.

---

Du hast spezifische Performance-Probleme oder möchtest deine Konfiguration prüfen lassen? Unser Support-Team analysiert gerne deinen Server und gibt dir maßgeschneiderte Optimierungsvorschläge – kostenlos für unsere Kunden.