Minecraft-Server laggt: Ursache finden mit spark

„Es laggt“ sagen Spieler so, wie Patienten „es tut weh“ sagen: wahr, dringend und noch keine Diagnose. Diese Anleitung macht aus der Beschwerde eine Zahl und aus der Zahl eine gezielte Änderung.

Kurz gesagt

Minecraft-Server laggt aus einem von vier Gründen: Ticks dauern zu lange, es gibt seltene Lagspitzen, der Netzwerkweg ist schlecht oder der Client ist schwach. Nur die ersten beiden gehen den Server etwas an, und eine Zahl trennt sie vom Rest: MSPT, die Millisekunden, die der Server für einen Tick braucht. Der Server peilt 20 Ticks pro Sekunde an, das lässt 50 ms je Tick [1][2]. Passen deine Ticks in dieses Budget, liegt die Ursache woanders. Passen sie nicht, zeigt dir spark, der Profiler, den Paper seit Version 1.21 mitliefert [7], welcher Teil des Ticks die Zeit frisst. Behebe zuerst den größten Brocken, miss erneut und denk erst zuletzt über einen größeren Server nach. Unsere Einschätzung: Mehr RAM verkürzt keinen Tick, der auf den Prozessor wartet, und ein spark-Bericht zeigt dir, ob das bei dir der Fall ist [13][18][20].

So funktioniert’s

1. Ticks, TPS und MSPT. Minecraft läuft in einer Schleife, jeder Durchlauf heißt Tick. In einem Tick verarbeitet der Server Spielerpakete, bewegt Entitäten, lässt Mobs spawnen und handeln, rechnet Redstone und schickt Updates an die Spieler [1]. Er will genau 20 Ticks pro Sekunde schaffen, einen alle 50 Millisekunden. Ist ein Tick früher fertig, schläft der Server die restliche Zeit der 50 ms. Läuft ein Tick länger, beginnt der nächste verspätet, denn Ticks laufen nicht parallel, und das ganze Spiel wird langsamer [1]. TPS (Ticks pro Sekunde) zählt, wie viele Ticks in einer Sekunde fertig wurden. MSPT (Millisekunden pro Tick) sagt, wie lange ein Tick dauerte. Für 20 TPS muss der Durchschnitt bei höchstens 50 ms bleiben [2]. spark zeigt außerdem Minimum, Median, 95. Perzentil und Maximum und färbt Werte grün, gelb oder rot [2]. MSPT ist unserer Ansicht nach die bessere Vorwarnung: TPS bleibt bei 20, solange der Durchschnitt ins Budget passt, und fällt erst, wenn die Reserve aufgebraucht ist [2][20].
2. Zahlen lesen. /spark tps gibt die TPS-Rate und die CPU-Auslastung aus, und die spark-Anleitung erklärt TPS und MSPT zusammen [2][3]. Papers eigenes /tps zeigt die letzten 1, 5 und 15 Minuten, /mspt Durchschnitt, Minimum und Maximum der letzten 5, 10 und 60 Sekunden, aber die Paper-Dokumentation nennt beide durch spark abgelöst [8]. Auf einem Vanilla-Server gibt /tick query (seit 1.20.3, Berechtigungsstufe 3) den Tick-Status, die durchschnittliche Zeit pro Tick und Perzentile aus [17]. In der Server-Konsole tippst du Befehle ohne den führenden Schrägstrich [21]. Im Spiel musst du Operator sein oder die Berechtigung spark besitzen [6].
3. Reserve. In einem spark-Profil steht die Tick-Schleife weit oben, und die Zeit, die der Server schläft, ist deine Reserve. Die spark-Anleitung nennt einen hohen Schlafanteil gesund, sagt, dass der Server unter 20 Prozent Schlaf hart arbeitet und unter 5 Prozent wahrscheinlich laggt, ohne freie Kapazität, und erinnert daran, dass all diese Werte Durchschnitte sind [1].
4. Profilieren, während es laggt. Die Paper-Dokumentation betont, dass das Problem gerade auftreten muss, sonst zeigt das Profil einen gesunden Server [7]. Starte /spark profiler start --timeout 600. Nach zehn Minuten liefert spark einen Link zum Bericht [7]. /spark profiler info zeigt den Status, open öffnet ein laufendes Profil, stop beendet es sofort, und cancel verwirft es ohne Upload [3]. Den Link des Viewers darf man frei weitergeben [5], behandle ihn also als öffentlich. Willst du die Daten lieber behalten, speichert /spark profiler stop --save-to-file das Profil im Konfigurationsordner, statt es hochzuladen [3]. Paper ab 1.21 bringt spark mit. Bei älteren Versionen installierst du die Plugin-Jar, und eine neuere eigenständige Jar ersetzt die mitgelieferte, wenn du -Dpaper.preferSparkPlugin=true an die Startargumente hängst [6][7]. Papers Timings-Profiler ist veraltet und seit 1.21 standardmäßig aus [7].
5. Bericht lesen. Öffne zuerst den „Server thread“, den Hauptthread, der das Spiel ausführt [5]. Jede Zeile zeigt den Zeitanteil des Threads. Klappe den größten Kindeintrag auf, dann dessen größten, und „folge den Zahlen“ [5]. Der Viewer bietet außerdem eine flache Ansicht mit den 250 langsamsten Methodenaufrufen, eine Quellen-Ansicht mit einem Baum je Plugin oder Mod und einen Flame Graph, in dem die Breite die Zeit zeigt [5]. Weil die Methodennamen des Spiels verschleiert sind, wendet der Viewer Entschleierungs-Zuordnungen (Mappings) automatisch an und lässt dich sie von Hand wählen, falls das scheitert [5]. Nach unserer Lesart verdienen drei Namensfamilien den ersten Blick: Entitäten, Chunk-Laden und Plugin-Namen.
6. Spitzen brauchen ein anderes Werkzeug. Ein gemitteltes Profil versteckt seltene lange Ticks, weil die normalen Ticks die Spitze ausgleichen [4]. Starte zuerst /spark tickmonitor. Es meldet Ticks, die deutlich länger als der Durchschnitt dauerten (standardmäßig doppelt so lang), und --threshold-tick 50 meldet jeden Tick über 50 ms [3][4]. Profiliere danach nur die langen Ticks mit /spark profiler start --only-ticks-over 100. spark empfiehlt einen Schwellwert zwischen 50 und 100, der unter der Länge der beobachteten Lagticks bleibt [3][4]. Ordne jede tickmonitor-Meldung dem zu, was im Spiel in diesem Moment passierte [4].

Welche Art Lag hast du?

Diese Tabelle ist unsere Einschätzung auf Basis der Quellen oben.

Steht TPS bei 20, bleibt MSPT deutlich unter 50 und ist der Schlafanteil hoch, hör auf, am Server zu drehen. Der Tick ist nicht das Problem.

Was du ändern solltest, in dieser Reihenfolge

Ändere nur eine Sache auf einmal und miss unter ähnlicher Last erneut. Die Reihenfolge ist unser Urteil, von billig und sicher bis eingreifend, und keine gemessene Rangliste.

1. Chunk-Erzeugung. Erkunden Spieler Neuland, muss der Server Gelände auf der Stelle erzeugen, und das zeigt sich als Spitzen. Chunky erzeugt das Gebiet vorab. Die dokumentierten Befehle lauten chunky world NAME, chunky center X Z oder chunky spawn, chunky radius 5000, chunky start und danach chunky progress, chunky pause und chunky continue [14]. chunky worldborder übernimmt die Vanilla-Weltgrenze, und das Vanilla-/worldborder set nimmt die volle Breite, eine Grenze von 10000 passt also zu einem Chunky-Radius von 5000 [14][21]. Der Weltname hängt von deinem Aufbau ab, etwa world oder overworld für die Oberwelt [15]. Hangar nennt Chunky 1.5.3 für 26.1 bis 26.3 [16]. Starte es bei leerem Server, denn die Vorerzeugung ist dieselbe schwere Arbeit, die Spieler auslösen, nur alles auf einmal [21]. Sie kostet Speicherplatz und Backup-Zeit, beginne also mit einem mäßigen Radius [21].
2. Distanzen. simulation-distance ist der Radius in Chunks, in dem der Server lebende Entitäten aktualisiert. view-distance bestimmt, wie viele Weltdaten an die Clients gehen. Beide stehen standardmäßig auf 10, erlaubt sind 3 bis 32 [9]. Eine kleinere Simulationsdistanz senkt die Arbeit, die der Server in jedem Tick erledigt, und sie ist die Einstellung, die wir zuerst probieren würden [20]. Senke sie um ein bis zwei Stufen, nicht bis zum Anschlag. Einen offiziellen Richtwert haben wir nicht gefunden, behandle also jede Zahl aus Foren oder Drittanleitungen als Testwert.
3. Entitäten. /paper entity list listet die aktuell tickenden Entitäten, und du kannst nach Typ filtern, etwa minecraft:pig [8]. Spawn-Limits stehen in der bukkit.yml (Monster standardmäßig 70) und lassen sich je Welt überschreiben [11]. per-player-mob-spawns verteilt das Mob-Limit pro Spieler [10]. In der spigot.yml legt entity-activation-range fest, bis zu welchem Abstand vom Spieler Entitäten normal ticken: standardmäßig 32 Blöcke für Tiere und Monster, 64 für Plünderer, 16 für sonstige Entitäten [12]. Vorsicht: Paper weist darauf hin, dass eine kleine Reichweite für sonstige Entitäten Gegenstände in Wasserströmen ruckeln oder rückwärts laufen lassen kann [12]. Drittanleitungen nennen große Mob-Farmen, dichte Dorfhallen und ständige Trichter-Aktivität als häufige Kandidaten [20], und dein Profil zeigt, ob deine dazugehören.
4. Plugins. Die Quellen-Ansicht zeigt den Zeitanteil je Plugin [5]. Aktualisiere es, ändere seine Konfiguration, ersetze es oder lass es weg.
5. Autosave. Papers max-auto-save-chunks-per-tick steht standardmäßig auf 24 [10]. Kommen deine Spitzen in regelmäßigem Takt, sieh dir die tickmonitor-Zeitstempel und das Profil dieser Ticks an, bevor du daran drehst. Diese Einstellung haben wir nicht getestet.
6. Speicher und Garbage Collection. Java gibt ungenutzten Speicher in Durchläufen frei, die Garbage Collection (GC) heißen, und ein langer Durchlauf lässt einen Tick einfrieren. /spark gc gibt den GC-Verlauf aus, /spark gcmonitor meldet GC-Aktivität, während sie passiert, und /spark health show --memory ergänzt JVM-Speicherdetails [3]. Papers Seite zu den Startflags empfiehlt mindestens 6 bis 10 GB, rät dazu, den Heap etwa 1000 bis 1500 MB unter dem Speicher zu setzen, den dein Host dir gibt, und warnt, dass mehr Speicher ab einem Punkt nichts mehr bringt [13]. Andere Quellen nennen für kleine Server kleinere Werte, gleiche [18] also mit deinem eigenen Bericht ab. Alle sind sich einig, dass mehr nicht automatisch besser ist.

Wann ein größerer Server hilft

Eine stärkere Maschine ist die richtige Antwort, wenn der Bericht den Prozessor als Grenze zeigt, und nur dann. Die Anzeichen nach unserer Lesart: Der Server-Thread hat kaum Schlafzeit, und nach den Schritten oben fällt kein einzelnes Plugin, keine Entitätsgruppe und keine Chunk-Quelle mehr auf. Dann kauf auf Einzelkern-Tempo. Das Minecraft Wiki sagt, ein Server nutzt überwiegend einen Kern, und empfiehlt eine CPU mit hoher Single-Thread-Leistung [18]. Zusätzliche Kerne helfen Plugins und manchen Hintergrundaufgaben, aber die Kernmechanik wie das Ticken bleibt weitgehend auf einem Thread [19]. Bei RAM ist es anders: setupmc.com sagt es deutlich, mehr RAM verkürzt keine CPU-gebundene Tick-Arbeit [20]. Prüfe bei gemieteten Servern, ob CPU und RAM garantiert oder geteilt sind, denn das Wiki nennt es als Vergleichspunkt [18]. Unsere Guides zu Hosting-Kriterien, zum Minecraft-Server auf dem VPS und zum Server zu Hause behandeln die Kaufseite.

Ein Beispiel zum Üben (erfundene Werte zum Üben, keine Messung)

Sechs Freunde spielen auf einem Paper-Server, und jeden Abend sagt jemand „es laggt“. Während des Abends startest du:

/spark tps
/spark profiler start --timeout 600

Lesart A: MSPT liegt im Schnitt bei 22 ms, das 95. Perzentil bei 38 ms, der Schlafanteil im Profil ist hoch. Der Tick ist in Ordnung. Prüfe /spark ping, die Verbindungen und die Bildraten der Spieler, bevor du eine Einstellung anfasst.

Lesart B: MSPT liegt im Schnitt bei 58 ms, der Schlafanteil unter 5 Prozent, und 45 Prozent des Server-Threads stecken im Chunk-Laden, während zwei Freunde in verschiedene Richtungen fliegen. Erzeuge mit Chunky vor, begrenze das erkundete Gebiet mit einer Weltgrenze und miss erneut.

Lesart C: MSPT liegt im Schnitt bei 61 ms, Schlaf unter 5 Prozent, und nach den Schritten oben fällt nichts mehr auf. Der Server-Thread ist die Grenze. Jetzt ist ein Prozessor mit stärkerem Einzelkern-Tempo eine begründete Anschaffung, und kein RAM-Upgrade behebt das.

Lass nach jeder Änderung dasselbe Profil noch einmal laufen und schreib beide Ergebnisse nebeneinander. Eine Änderung, die die Zahl nicht bewegt, geht wieder zurück.

Prüfliste

• Miss /spark tps während des Lags und notiere MSPT, das 95. Perzentil und die CPU-Auslastung.
• Trenne Tick-Lag, Lagspitzen, Netzwerk und Client, bevor du etwas änderst.
• Starte /spark profiler start --timeout 600 während des Problems und öffne zuerst den Server thread.
• Prüfe den Schlafanteil: unter 20 Prozent arbeitet der Server hart, unter 5 Prozent hat er keine Reserve.
• Nutze /spark tickmonitor und --only-ticks-over für Spitzen statt gemittelter Profile.
• Erzeuge erkundetes Gelände mit Chunky bei leerem Server vor und setze vorher eine Weltgrenze.
• Senke simulation-distance vor view-distance und ändere jeweils nur einen Wert.
• Sieh in die Quellen-Ansicht, bevor du den Server beschuldigst, denn ein Plugin kann den Großteil des Ticks kosten.
• Vergleiche zwei Berichte unter ähnlicher Last und nimm eine Änderung zurück, die nichts brachte.
• Kauf einen schnelleren Einzelkern, nicht mehr RAM, nur wenn der Bericht den Prozessor als Grenze zeigt.