Mit dem richtigen Modell anfangen
Wenn Admins sagen „der Server laggt“, werden oft mehrere Probleme vermischt:
- niedrige TPS
- hohe MSPT
- Chunk-Generierungs-Spikes
- langsame Plugins
- Netzwerkprobleme, die sich nur wie Lag anfühlen
Der wichtige Kern ist:
- der Server versucht mit 20 Ticks pro Sekunde zu laufen
- dafür hat er im Durchschnitt 50 ms pro Tick
Wenn die durchschnittliche Tick-Zeit darüber liegt, sinken die TPS und Meldungen wie Can't keep up! tauchen in der Konsole auf.
Was TPS und MSPT wirklich aussagen
TPS
TPS bedeutet Ticks per second. Im Zielzustand steht der Server bei 20 TPS.
MSPT
MSPT bedeutet Millisekunden pro Tick. Das ist meist der direkt nützlichere Wert, weil du daran siehst, wie viel Zeit die Serverlogik für einen Tick braucht.
Praktisch gilt:
- um oder unter 50 ms durchschnittlicher Tick-Zeit kann der Server 20 TPS halten
- oberhalb davon fällt er zurück
Die ersten Checks vor jeder Änderung
Gehe in dieser Reihenfolge vor:
- bestätigen, dass das Problem gerade wirklich auftritt
- messen statt raten
- immer nur eine sinnvolle Änderung auf einmal machen
Auf Paper 1.21 und neuer startest du am besten mit Spark, weil es gebündelt mitkommt und als bevorzugter Profiler dokumentiert ist:
/spark tps
/spark profiler start --timeout 600
Wenn du noch gar nicht auf Paper bist, lies zuerst Paper vs Vanilla vs Fabric vs Forge, bevor du anfängst, am falschen Stack herumzuoptimieren.
Die häufigsten Ursachen von Lag
1. CPU-limitierte Ticks
Minecraft-Server reagieren weiterhin stark auf Single-Core-Leistung. Wenn eine Tick-Phase zu lange dauert, rettet dich zusätzlicher RAM nicht.
2. Chunk-Generierung und Exploration
Schnelle Erkundung erzeugt Last durch Chunk-Generierung. Das zeigt sich oft eher als Spike als als dauerhaft niedrige TPS.
3. Zu viel Simulation
Paper dokumentiert simulation-distance getrennt von view-distance.
Das ist entscheidend, weil aktive Spiel-Logik und das, was Spieler sehen können, nicht dasselbe sind.
4. Plugin- oder Mod-Verhalten
Ein laggender Server ist oft nicht „Minecraft eben“, sondern ein einzelnes Plugin, ein Task oder eine Funktion, die schlecht skaliert.
5. Entity-lastige Farmen und Dörfer
Große Mob-Farmen, dichte Villager-Hallen und ständige Hopper-Aktivität können Tick-Zeit massiv dominieren.
Sinnvolle Reihenfolge für Fixes
Starte nicht mit beliebigen Config-Paketen. Sicherer ist:
- mit Spark messen
- unterscheiden, ob das Problem dauerhaft oder spiky ist
- zuerst die teuerste Ursache angehen
- erst dann Paper-Distanzen gezielt anpassen
So vermeidest du blindes Tuning nach Schema F.
Sichere erste Stellschrauben
simulation-distancezuerst senken, bevor du alles andere blind zusammenstreichstview-distancerealistisch zu Spielerzahl und Hardware wählen- Änderungen immer unter realer Last testen, nicht nur auf leerem Server
Für konkrete Startwerte geht es weiter mit View Distance und Simulation Distance in Paper: sichere Startwerte.
Häufige Fehler
| Fehler | Warum er schadet | Bessere Entscheidung |
|---|---|---|
| Erst mehr RAM geben | CPU- oder Tick-Probleme bleiben | MSPT messen und profilen |
| Tuning ohne aktives Lag-Fenster | Du optimierst den falschen Moment | Während des Problems Daten erfassen |
| Fünf Settings gleichzeitig ändern | Ursache-Wirkung geht verloren | Eine Änderung nach der anderen |
| Server-Softwarewahl ignorieren | Vanilla gibt dir weniger Diagnose- und Performance-Werkzeuge | Paper als Basis prüfen |
FAQ
Ist „Can’t keep up“ immer sofort kritisch?
Nein. Ein einzelner Spike kann bei Chunk-Generierung oder Startup normal sein. Das Muster ist wichtiger als eine einzelne Log-Zeile.
Sollte ich sofort beide Distanzen senken?
Nicht automatisch. Erst klären, ob Sichtweite, aktive Simulation, Entities oder ein Plugin die Last treiben.
Nächste Schritte
- Die eigentliche Ursache findest du mit Spark Profiler in Paper und Docker.
- Sichere Chunk- und Simulationswerte findest du in View Distance vs Simulation Distance.
- Wenn du noch auf dem falschen Stack sitzt, lies Paper vs Vanilla vs Fabric vs Forge.