Gaming 7 Min Lesezeit

Minecraft Plugin-Server optimieren 2026 – Paper & Spigot Tuning

Warum Plugin-Server 2026 mehr Leistung brauchen als je zuvor

Ein Vanilla-Server läuft heute auf fast jeder Hardware. Ein Plugin-Server mit 40 bis 120 aktiven Spielern, WorldEdit, LuckPerms, Citizens, MythicMobs, Vault, Economy- und Shop-Plugins ist ein völlig anderes Kaliber. Jedes Plugin hängt sich in den Tick-Loop, jedes Event feuert bei jedem Chunk-Load, und jeder falsch konfigurierte Scheduler-Task kostet dich TPS.

Die Realität 2026: Minecraft 1.21.x mit Paper 1.21.4+ ist deutlich effizienter als noch 1.16, aber die Plugin-Landschaft ist gleichzeitig komplexer geworden. Moderne Plugins nutzen DataComponents, Adventure-APIs und PacketEvents – das kostet mehr CPU pro Event, nicht weniger.

Dieser Guide zeigt dir konkret, welche Werte du in paper-global.yml, paper-world-defaults.yml, spigot.yml und bukkit.yml setzen musst, welche JVM-Flags 2026 noch Sinn ergeben und wo du mit 8 GB RAM noch 60 Spieler sauber hostest – und wo du auf 16 GB aufrüsten musst.

Paper vs. Spigot vs. Purpur vs. Folia – der richtige Fork

Spigot ist 2026 praktisch tot als Server-Software. Es ist der Referenz-Fork für die Bukkit-API, aber die Performance-Patches von Paper sind seit Jahren überlegen. Wer heute Spigot produktiv einsetzt, verschenkt 30 bis 50 % Tick-Performance.

Paper ist der Standard. Es bietet Async-Chunk-Loading, optimierte Entity-Tracking-Ranges, Redstone-Implementierungen (Alternate Current, EigenCraft), Anti-Xray und ein umfangreiches Config-System. Für 95 % aller Plugin-Server ist Paper die richtige Wahl.

Purpur ist ein Paper-Fork mit zusätzlichen Gameplay-Features (konfigurierbare Mob-AI, anpassbare Villager-Trades, Ridable-Mobs). Performance-seitig identisch zu Paper, plus einige Extra-Optimierungen. Wenn du Purpur-Features nicht brauchst, bleib bei Paper – weniger Angriffsfläche für Update-Bugs.

Folia ist Papers regionisierter Multi-Threading-Fork. Es kann auf 16-Kern-CPUs enorme Spielerzahlen stemmen, aber die Plugin-Kompatibilität ist 2026 immer noch eingeschränkt. Plugins müssen explizit Folia-kompatibel sein (Schedule-API, keine globalen Bukkit-API-Calls). Für ein normales Plugin-Setup ist Folia zu riskant.

Fork	Performance	Plugin-Kompatibilität	Empfehlung
Spigot	Basis	100 %	Nein
Paper	+35–50 %	~99 %	Standard
Purpur	+35–50 %	~98 %	Bei Bedarf
Folia	+200 % (Multi-Core)	~40 %	Nur Spezialfälle

Hardware: RAM, CPU und NVMe richtig dimensionieren

Die Faustregel „1 GB RAM pro 10 Spieler" ist 2026 überholt. Entscheidend ist die Plugin-Last, nicht die Spielerzahl. Ein Skyblock-Server mit 30 Spielern und 200 geladenen Chunks braucht mehr RAM als ein Minigame-Netzwerk mit 80 Spielern auf 8 kleinen Arenen.

Realistische Richtwerte für Paper 1.21.x mit 15–25 Plugins:

4 GB RAM – bis 15 Spieler, kleine SMP, 6–8 View Distance
8 GB RAM – 20–45 Spieler, Standardserver, 8 View Distance
12 GB RAM – 45–75 Spieler, mit MythicMobs/Citizens, 8–10 View Distance
16 GB RAM – 75–120 Spieler oder große Skyblock-/RPG-Welten
32 GB+ – Netzwerke mit Velocity-Proxy und mehreren Backend-Servern

Bei der CPU zählt Single-Core-Leistung. Minecrafts Haupt-Tick-Loop ist single-threaded. Ein Ryzen 9 7950X (5,7 GHz Boost) schlägt einen 32-Kern-Xeon mit 2,4 GHz in jeder Minecraft-Metrik. Achte auf CPUs mit hohem Boost-Takt und großem L3-Cache (X3D-Modelle sind ideal, weil Chunk-Daten und Entity-Listen im Cache bleiben).

Storage: NVMe ist Pflicht. Chunk-Loading und Welt-Saves sind I/O-intensiv. Eine SATA-SSD liefert ~550 MB/s, eine NVMe Gen4 ~7.000 MB/s. Bei 100 gleichzeitigen Chunk-Loads merkst du das sofort in den Tick-Zeiten. Shared-Hosting auf HDD oder SATA-SSD ist 2026 ein No-Go für Plugin-Server.

JVM-Tuning: Aikar-Flags und Garbage Collector

Die Aikar-Flags sind seit Jahren der De-facto-Standard für Minecraft-Server. Sie konfigurieren den G1GC so, dass GC-Pausen unter 200 ms bleiben und keine langen Stop-the-World-Phasen entstehen.

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

Wichtig: -Xms und -Xmx immer gleich setzen. Sonst muss die JVM den Heap zur Laufzeit vergrößern, was zu Page-Faults und Rucklern führt. -XX:+AlwaysPreTouch reserviert den Speicher sofort beim Start – der Server braucht 10–20 Sekunden länger zum Booten, läuft danach aber deutlich stabiler.

Für Server mit mehr als 16 GB Heap kann ZGC (-XX:+UseZGC -XX:+ZGenerational) in Java 21+ interessant sein: Pausenzeiten unter 1 ms, aber höherer CPU-Overhead. Bei unter 16 GB Heap bleibt G1GC mit Aikar-Flags die bessere Wahl.

Setze außerdem -Dfile.encoding=UTF-8 und -Djava.net.preferIPv4Stack=true, um Encoding-Probleme mit Plugin-Nachrichten und IPv6-DNS-Latenzen zu vermeiden.

Paper-Konfiguration: paper-global.yml und paper-world-defaults.yml

Seit Paper 1.19 sind die Configs aufgeteilt. Die wichtigsten Optimierungen findest du in config/paper-world-defaults.yml:

chunks:
  max-auto-save-chunks-per-tick: 24
  entity-per-chunk-save-limit:
    experience_orb: 32
    item: 32
    arrow: 32
entities:
  spawning:
    mob-spawn-range: 6
    despawn-ranges:
      monster:
        hard: 96
        soft: 32
    per-player-mob-spawns: true
  behavior:
    max-entity-collisions: 2
    disable-chest-cat-detection: true
collisions:
  enable-player-collisions: false
misc:
  redstone-implementation: ALTERNATE_CURRENT

mob-spawn-range: 6 statt der Standard-8 reduziert die Anzahl gleichzeitig geladener Mobs um etwa 40 %. max-entity-collisions: 2 verhindert, dass 50 Kühe in einem Stall die Tick-Zeit auffressen. per-player-mob-spawns: true sorgt dafür, dass jeder Spieler seine eigene Mob-Kappe hat – wichtig für Server mit ungleich verteilten Spielern.

redstone-implementation: ALTERNATE_CURRENT (oder EIGENCRAFT in Paper 1.21.4+) beschleunigt Redstone-Berechnungen um bis zu 50 % bei identischem Verhalten. Bei sehr komplexen Redstone-Maschinen kann VANILLA nötig sein, aber für 99 % der Server ist Alternate Current korrekt.

In paper-global.yml lohnt sich chunk-loading.auto-config-send-distance: true und chunk-loading.target-player-chunk-send-rate: 50.0, damit der Chunk-Versand nicht den Tick-Loop blockiert.

Spigot.yml und bukkit.yml: die wichtigsten Werte

Auch wenn Paper viele Spigot-Werte überschreibt, bleiben einige Einstellungen relevant. In spigot.yml:

world-settings:
  default:
    view-distance: 8
    simulation-distance: 6
    entity-activation-range:
      animals: 24
      monsters: 28
      misc: 8
      water: 8
    merge-radius:
      item: 4.0
      exp: 6.0
    item-despawn-rate: 3000
    ticks-per:
      hopper-transfer: 8
      hopper-check: 8

entity-activation-range ist der größte Performance-Hebel überhaupt. Standard sind 32 Blöcke für Monster. Bei 28 statt 32 sinkt die Zahl aktiv tickender Entities um rund 25 %. merge-radius für Items auf 4.0 sorgt dafür, dass gedroppte Items verschmelzen – bei Farmen mit hunderten Drops essenziell.

In bukkit.yml setzt du:

spawn-limits:
  monsters: 50
  animals: 8
  water-animals: 4
  ambient: 4
chunk-gc:
  period-in-ticks: 400
ticks-per:
  animal-spawns: 400
  monster-spawns: 1
  autosave: 6000

chunk-gc.period-in-ticks: 400 (20 Sekunden) entlädt ungenutzte Chunks aggressiver. Bei Servern mit vielen AFK-Spielern in entfernten Regionen spart das mehrere GB RAM. autosave: 6000 (5 Minuten) reduziert die Save-Lags gegenüber dem Standard von 900 Ticks deutlich.

Chunk-Pre-Generation mit Chunky

Nichts killt TPS so zuverlässig wie Spieler, die in ungenerierte Gebiete rennen. Jeder neue Chunk muss generiert, dekoriert und an alle Spieler in Reichweite gesendet werden. Bei einer 10k×10k-Welt sind das 100 Millionen Chunks – unmöglich live zu stemmen.

Nutze Chunky (Paper-Plugin) oder /chunky als Konsolen-Befehl:

chunky radius 5000
chunky shape square
chunky center 0 0
chunky spawn
chunky start
chunky progress

Rechne mit 30–60 Minuten pro 1.000 Chunks auf einer NVMe, abhängig von CPU und Weltgenerator. Eine 5.000er-Radius-Welt (10k×10k) bedeutet 100.000 Chunks – also 50 bis 100 Stunden Pre-Generation. Das klingt viel, aber danach läuft der Server dauerhaft lagfrei, weil keine Live-Generierung mehr stattfindet.

Setze chunky.continue-on-restart: true in der Config, damit die Generierung nach einem Neustart weiterläuft. Während der Pre-Gen solltest du den Server nicht öffentlich betreiben – die CPU ist voll ausgelastet.

Plugins analysieren mit Spark und Timings

Bevor du blind an Configs drehst: messe. Spark ist 2026 der Standard-Profiler und ersetzt das alte Timings-System.

/spark profiler start --timeout 60
/spark profiler stop
/spark tps
/spark health

Der Report zeigt dir die Top-Verbraucher im Tick-Loop. Typische Befunde auf Plugin-Servern:

Entity-Ticking – zu viele Mobs, siehe mob-spawn-range
Block-Entity-Ticking – Hunderte Hoppers, Öfen, Trichter
Plugin-Scheduler-Tasks – Plugins, die jeden Tick die ganze Welt iterieren
Chunk-Generierung – siehe Chunky
Netzwerk/Chunk-Send – zu hohe View Distance

Wenn ein einzelnes Plugin mehr als 15 % der Tick-Zeit frisst, ist es entweder falsch konfiguriert oder du brauchst eine Alternative. Bekannte Kandidaten: alte Anti-Cheat-Versionen, unoptimierte Shop-Plugins mit Datenbank-Queries im Tick-Loop und Custom-Mob-Plugins ohne Async-Spawning.

Nutze außerdem /spark healthreport für einen Überblick über TPS, MSPT (Milliseconds per Tick) und Speicherverbrauch. Zielwert: MSPT unter 40 ms bei 20 TPS. Über 50 ms fängt es an zu ruckeln.

Datenbanken: MySQL, MariaDB und Redis

Sobald du LuckPerms, ein Economy-Plugin und ein Statistik-Plugin laufen hast, ist die Standard-H2/SQLite-Datei ein Flaschenhals. Jede Query blockiert den Tick, wenn sie synchron läuft.

Wechsle auf MariaDB 11.x oder MySQL 8.4 auf demselben Host oder einem zweiten Server. Konfiguration für einen dedizierten Datenbank-Server:

innodb_buffer_pool_size = 2G
innodb_flush_log_at_trx_commit = 2
innodb_log_file_size = 512M
max_connections = 200
query_cache_type = 0

innodb_flush_log_at_trx_commit = 2 opfert maximal 1 Sekunde Daten bei einem Crash, bringt aber 3- bis 5-fach schnellere Writes. Für LuckPerms und Economy-Daten völlig akzeptabel.

Für Session-Daten, Leaderboards oder Cache-Layer lohnt sich Redis 7.x. Plugins wie Plan, LiteBans oder Custom-Skripte können darüber asynchron schreiben, ohne den Tick-Loop zu berühren. Redis läuft mit 256 MB RAM bereits flüssig.

Hosting-Preise und Anbietervergleich 2026

Ein 8-GB-Paper-Server auf Ryzen 9 7950X kostet 2026 zwischen 12 und 20 €/Monat bei deutschen Anbietern (Nitrado, Zap-Hosting, HostUnlimited, Hetzner-Cloud). 16 GB liegen bei 25 bis 35 €. Wichtig: Nicht nur RAM vergleichen, sondern CPU-Modell und Storage-Typ.

Paket	RAM	CPU	Storage	Preis/Monat
Einsteiger	4 GB	Ryzen 5 3600	SATA-SSD	6–9 €
Standard	8 GB	Ryzen 9 7950X	NVMe	12–20 €
Pro	16 GB	Ryzen 9 7950X3D	NVMe Gen4	25–35 €
Dedicated	64 GB	Ryzen 9 9950X	2× NVMe	70–110 €

Achte auf DDoS-Schutz (Layer 4 und 7), unmetred Traffic und Backup-Optionen. Ein Anbieter ohne automatische Backups ist für einen Community-Server mit 50+ Spielern unverantwortlich.

Für Netzwerke mit mehreren Servern (Lobby, Survival, Skyblock, Minigames) lohnt sich ein Velocity-Proxy auf einem kleinen VPS (2 GB RAM, ~5 €/Monat). Velocity ist deutlich performanter als BungeeCord und unterstützt moderne Forwarding-Modi.

Monitoring und Langzeit-Stabilität

Ein optimierter Server bleibt nicht automatisch optimiert. Welten wachsen, Spieler bauen mehr Redstone, Plugins werden geupdated. Richte daher Monitoring ein:

Spark für Ad-hoc-Analysen
Plan für TPS-Historie, Spielerzahlen und Performance-Graphen
Prometheus + Grafana mit dem Paper-Exporter für MSPT, RAM, CPU
systemd mit Restart=on-failure und MemoryMax

Ein systemd-Service für den Server sieht so aus:

[Unit]
Description=Minecraft Paper Server
After=network.target

[Service]
User=minecraft
WorkingDirectory=/opt/minecraft
ExecStart=/usr/bin/java @aikar-flags.txt -jar paper.jar nogui
Restart=on-failure
RestartSec=10
MemoryMax=12G

[Install]
WantedBy=multi-user.target

Lege die JVM-Flags in eine separate Datei aikar-flags.txt (eine Zeile pro Argument), dann bleibt der Service-Eintrag übersichtlich und du kannst Flags ändern, ohne die Unit anzufassen.

Plane außerdem wöchentliche Neustarts – nicht wegen Memory-Leaks in Paper, sondern wegen Plugins. Viele ältere Plugins leaken über Tage hinweg Listener oder Scheduler-Tasks. Ein Neustart um 4:00 Uhr morgens mit Restart=always und einem /say-Countdown ist Standardpraxis.

Checkliste: die 12 wichtigsten Optimierungen

Paper statt Spigot verwenden
Aikar-Flags mit -Xms = -Xmx setzen
mob-spawn-range auf 6 reduzieren
max-entity-collisions auf 2 setzen
entity-activation-range auf 24/28/8 senken
merge-radius für Items auf 4.0 erhöhen
redstone-implementation auf ALTERNATE_CURRENT
view-distance auf 8, simulation-distance auf 6
Welt mit Chunky pre-generieren
MariaDB statt SQLite für Plugin-Daten
Spark-Profiling monatlich durchführen
NVMe-Storage und Single-Core-starke CPU nutzen

Mit diesen zwölf Maßnahmen holst du aus einem 8-GB-Server problemlos 40 bis 60 stabile Spieler bei 20 TPS heraus. Ohne sie kämpfst du schon bei 20 Spielern mit TPS-Einbrüchen.

FAQ

Wie viel RAM braucht ein Minecraft Plugin-Server 2026 wirklich?

Für 20–45 Spieler mit 15–25 Plugins reichen 8 GB Heap. Entscheidend ist nicht die Spielerzahl, sondern die Zahl geladener Chunks und aktiver Entities. Bei großen Skyblock- oder RPG-Welten mit vielen Custom-Mobs solltest du auf 12–16 GB gehen. Setze -Xms und -Xmx immer identisch.

Bringen Aikar-Flags 2026 noch etwas?

Ja. Die Flags sind für G1GC in Java 21 weiterhin optimal und reduzieren GC-Pausen auf unter 200 ms. Bei Heaps über 16 GB kann ZGC mit -XX:+UseZGC -XX:+ZGenerational bessere Pausenzeiten liefern, kostet aber mehr CPU. Für die meisten Server bleiben Aikar-Flags die erste Wahl.

Ist Folia 2026 eine Alternative zu Paper?

Nur für Spezialfälle. Folia skaliert über mehrere Kerne, aber die Plugin-Kompatibilität liegt bei etwa 40 %. Die meisten Economy-, Shop- und Region-Plugins funktionieren nicht. Für klassische Plugin-Server bleibt Paper die sichere Wahl.

Wie lange dauert die Chunk-Pre-Generation mit Chunky?

Rechne mit 30–60 Minuten pro 1.000 Chunks auf NVMe. Eine 10k×10k-Welt (100.000 Chunks) braucht 50–100 Stunden. Das ist einmaliger Aufwand, danach läuft der Server dauerhaft ohne Live-Chunk-Generierung und damit deutlich stabiler.

Warum ruckelt mein Server trotz 20 TPS?

TPS sagt nur, ob der Server die 50-ms-Ticks einhält. Ruckler entstehen oft durch hohe MSPT-Spitzen (Chunk-Sends, Autosave, GC) oder Netzwerk-Latenz. Prüfe mit /spark healthreport die MSPT-Verteilung und reduziere view-distance sowie autosave-Frequenz. Auch Client-seitige Render-Distanz spielt eine Rolle.