Minecraft Server CPU-Optimierung: Server-seitigen Lag durch rechenintensive Prozesse reduzieren

# Minecraft Server CPU-Optimierung: Server-seitigen Lag durch rechenintensive Prozesse reduzieren

Dein Server hat genug RAM. Die Disk-I/O ist sauber. Trotzdem brichst du während der Stoßzeiten TPS ein. In vielen Fällen ist der eigentliche Schuldige CPU-Sättigung — der Haupt-Thread des Servers erledigt schlicht zu viel Arbeit pro Tick.

Dieser Guide zeigt dir, wo die CPU-Zeit verloren geht, wie du das präzise misst und welche Konfigurationsänderungen den größten Unterschied machen.

Warum Minecraft so CPU-intensiv ist

Minecrafts Serversoftware ist bekannt dafür, im Kern Single-Threaded zu sein. Nahezu alles — Entity-KI, Blockupdates, Spieleraktionen, Chunk-Logik — läuft auf einem einzigen Haupt-Thread, der einen vollständigen Game-Tick in unter 50 Millisekunden abschließen muss, um 20 TPS zu halten.

Wenn die Berechnungen innerhalb eines einzelnen Ticks 50ms überschreiten, sinken die TPS. Mehr Spieler, mehr Entities, komplexere Plugins und mehr geladene Chunks konkurrieren alle um dieselbe Zeitscheibe.

Der entscheidende Punkt: Du kannst Vanilla-Minecraft-Lag nicht einfach mit mehr CPU-Kernen lösen. Du musst reduzieren, *was der Haupt-Thread pro Tick tut*.

Schritt 1: CPU-Hotspots identifizieren

Bevor du irgendeine Konfiguration änderst, erstelle ein Profil deines Servers. Raten kostet Zeit.

Mit Spark:

/spark profiler --timeout 120

Nach zwei Minuten generiert Spark ein Flame-Graph. Schau dir die breitesten Balken an — das sind deine schwersten CPU-Verbraucher. Häufige Übeltäter:

• EntityBrain / GoalSelector (Mob-KI)
• BlockEntityTicker (Trichter, Öfen, Truhen)
• ChunkMap (Chunk-Lade-Logik)
• Methoden von Drittanbieter-Plugins

Nimm dir hier Zeit. Das Optimieren der *falschen* Dinge bringt nichts.

Schritt 2: Mob-KI und Pathfinding tunen

Mob-KI gehört konsistent zu den größten CPU-Verbrauchern auf aktiven Servern. Pathfinding ist besonders teuer — jeder Mob berechnet standardmäßig mehrmals pro Sekunde seine Route neu.

In paper-world.yml (pro Welt oder global):

entities:
  behavior:
    baby-zombie-movement-modifier: 0.5
mobs:
  villagers:
    lobotomize:
      enabled: true
      check-interval: 100

Das Lobotomisieren von Dorfbewohnern, die sich nicht in der Nähe von Spielern befinden, ist eine der effektivsten einzelnen Änderungen — Dorfbewohner führen ständig komplexe KI aus.

In spigot.yml:

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

Durch Reduzierung von entity-activation-range führen Mobs weiter entfernt von Spielern eine vereinfachte KI aus — das reduziert die Berechnung pro Tick drastisch ohne spürbaren Gameplay-Einfluss.

Schritt 3: Trichter und Block-Entity-Verarbeitung optimieren

Trichter sind bekannt dafür, teuer zu sein. Jeder aktive Trichter prüft standardmäßig alle 8 Game-Ticks auf zu übertragende Items. Auf Servern mit komplexen Item-Sortiersystemen summiert sich das schnell.

In spigot.yml:

world-settings:
  default:
    hopper-amount: 1
    hopper-check: 8

In paper-world.yml:

hopper:
  cooldown-when-full: true
  disable-move-event: false
  ignore-occluding-blocks: true

cooldown-when-full: true verhindert, dass Trichter CPU-Zyklen verschwenden, wenn das Zielinventar bereits voll ist — ein enormer Gewinn in automatisierten Farmen.

In bukkit.yml:

tick-per:
  hopper-transfer: 8
  hopper-check: 1

Das Erhöhen von hopper-transfer auf 16 oder sogar 24 reduziert die Übertragungsfrequenz — Spieler bemerken den Unterschied im Durchsatz kaum, aber die CPU-Entlastung ist erheblich.

Schritt 4: Unnötige Chunk-Updates und Lichtberechnungen reduzieren

Lichtberechnungen gehören zu den rechenintensivsten Operationen in Minecraft. Massenhafte Blockplatzierungen (WorldEdit-Operationen, Schematic-Pastes, große Explosionen) können die CPU für Sekunden in die Höhe treiben.

In paper-world.yml:

environment:
  optimize-explosions: true
disable-thunder: false
disable-ice-and-snow: false
chunks:
  delay-chunk-unloads-by: 10s
  entity-per-chunk-save-limit:
    experience_orb: 16
    arrow: 16
    fireball: 8
    small_fireball: 8
    dragon_fireball: 3
    egg: 8
    ender_pearl: 8
    area_effect_cloud: 8
    llama_spit: 3
    shulker_bullet: 8
    snowball: 8
    spectral_arrow: 16
    experience_bottle: 3
    trident: 16
    wither_skull: 4
    fishing_bobber: 8

optimize-explosions ersetzt den teuren Vanilla-Explosions-Raycast-Algorithmus durch eine gecachte Version — besonders wichtig auf PvP- oder Survival-Servern mit häufigem TNT-Einsatz.

Schritt 5: Pufferfish und Purpur für KI-Optimierungen nutzen

Wenn du Pufferfish (ein Paper-Fork) verwendest, erhältst du Zugang zu Dynamic Activation of Brain (DAB), das die Mob-KI-Frequenz intelligent basierend auf der Distanz zu Spielern skaliert:

In pufferfish.yml:

dab:
  enabled: true
  start-distance: 12
  max-tick-freq: 20
  activation-dist-mod: 8

Das allein kann die Mob-KI-CPU-Kosten auf Servern mit hoher Entity-Anzahl um 30–60 % reduzieren.

Purpur bietet zusätzliche Steuerungsmöglichkeiten in purpur.yml:

world-settings:
  default:
    mobs:
      zombie:
        aggressive-towards-villager-when-lagging: false
      pillager:
        aggressive-towards-player: true
    ridable-in-water: false

Kleine Verhaltens-Toggles summieren sich bei größerer Last zu bedeutsamen CPU-Einsparungen.

Schritt 6: Arbeit mit Async-fähigen Plugins auslagern

Manche Operationen müssen *nicht* auf dem Haupt-Thread laufen. Moderne Plugins unterstützen zunehmend asynchrone Ausführung:

• AsyncWorldEdit — fügt Schematics außerhalb des Haupt-Threads ein
• FastAsyncWorldEdit (FAWE) — dasselbe, mit besserer Performance
• Chunky — Welt-Vorgenerierung vollständig asynchron
• LuckPerms — Permission-Abfragen sind von Haus aus async

Ersetze synchrone Weltbearbeitungs- oder Datenabruf-Plugins durch asynchrone Alternativen. Jede Millisekunde, die du vom Haupt-Thread wegbekommst, ist eine Millisekunde zurückgewonnenes Tick-Budget.

Schritt 7: Kontinuierlich überwachen, nicht nur bei Vorfällen

Einmaliges Profiling deckt akute Probleme auf. Aber schleichende CPU-Erhöhung — bei der die Auslastung langsam steigt, wenn dein Server wächst — erfordert kontinuierliche Sichtbarkeit. Das Verfolgen der durchschnittlichen CPU-Last pro Tick über Tage und Wochen hilft dir, Degradierung zu erkennen, bevor Spieler Lag bemerken.

[PulseNode](https://pulsenode.tech) bietet dir Echtzeit- und historisches CPU-Monitoring für deinen Minecraft-Server, damit du TPS-Einbrüche mit bestimmten Zeitfenstern, Spieleranzahlen oder Plugin-Updates korrelieren kannst — und genau weißt, wann du handeln musst.

Schnellübersicht: Die wirkungsvollsten CPU-Optimierungen

| Änderung | Konfigurationsdatei | Wirkung |

|---|---|---|

| Inaktive Dorfbewohner lobotomisieren | paper-world.yml | Sehr hoch |

| Entity-Aktivierungsreichweite reduzieren | spigot.yml | Hoch |

| Explosionsoptimierung aktivieren | paper-world.yml | Hoch |

| Trichter-Cooldown bei vollem Inventar | paper-world.yml | Mittel–Hoch |

| DAB aktivieren (Pufferfish) | pufferfish.yml | Sehr hoch |

| Asynchrones WorldEdit verwenden | Plugin-Austausch | Hoch |

Fazit

CPU-Optimierung auf einem Minecraft-Server bedeutet, zu reduzieren, was der Haupt-Thread pro Tick berechnen muss — nicht einfach die Hardware aufzurüsten. Erstelle zuerst ein Profil mit Spark, ziele auf deine schwersten Systeme (Mob-KI, Trichter, Explosionen) und wende Konfigurationsänderungen methodisch an, damit du die Wirkung jeder einzelnen messen kannst.

Für Server, die kontinuierliche Überwachung benötigen, bietet [PulseNode](https://pulsenode.tech) KI-gestütztes Performance-Monitoring, das CPU-Trends im Zeitverlauf verfolgt und dir hilft, Lag zu erkennen, bevor deine Spieler ihn spüren.