Warum Spark dein erster Schritt sein sollte
Profiling beendet das Raten. Paper dokumentiert Spark als bevorzugten Profiler und bündelt ihn ab 1.21 direkt mit.
Das verändert den üblichen Admin-Workflow:
- du musst nicht sofort an zig Configs drehen
- du kannst Belege direkt vom Live-Server erfassen
- du kannst im Zweifel einen echten Report an einen Plugin-Autor weitergeben
Vor dem Start
Profile nur dann, wenn das Problem gerade wirklich auftritt. Ein Profil ohne auftretenden Lag zeigt die gesuchte Ursache möglicherweise nicht.
Schritt 1: Das Lag-Signal bestätigen
Starte mit:
/spark tps
Damit bekommst du den schnellen Gesundheitscheck und siehst, ob es sich um dauerhaft niedrige TPS, Spikes oder eher normale Werte handelt.
Wenn dir dafür noch der RCON-Zugang fehlt, richte zuerst RCON und Konsole in Docker ein.
Schritt 2: Ein zeitgesteuertes Profil starten
Paper verwendet selbst dieses Beispiel:
/spark profiler start --timeout 600
Das nimmt zehn Minuten lang auf und liefert danach eine Report-URL.
Zehn Minuten reichen in der Praxis oft, um Folgendes einzufangen:
- wiederkehrende geplante Aufgaben
- intensive Chunk-Exploration
- Farmen unter echter Spielerlast
- längere GC-Muster
Schritt 3: Das eigentliche Problem reproduzieren
Während das Profil läuft, solltest du den Server nicht leer stehen lassen, wenn Leere gar nicht das Problem ist. Lass Spieler genau die Aktivität machen, die Lag verursacht:
- neue Gebiete erkunden
- Farmen benutzen
- eine dichte Basis betreten
- eine Minigame-Logik auslösen
Das Profil soll die teure Aktivität sehen, nicht nur die ruhige Phase danach.
Schritt 4: Den Report in der richtigen Reihenfolge lesen
Starre nicht auf jede Zahl gleichzeitig. Nutze diese Reihenfolge:
- allgemeine Tick-Gesundheit
- die teuersten Bereiche oder Aufgaben
- Konzentration auf ein Plugin, ein Gebiet oder ein Subsystem
Du suchst keine zufälligen Ausschläge, sondern dominante Verbraucher. Wenn ein Plugin, eine Aufgabe oder ein Bereich deutlich heraussticht, hast du deinen ersten Hinweis für weitere Messungen.
Schritt 5: Aus dem Profil genau eine Änderung ableiten
Gute erste Maßnahmen sind konkret:
simulation-distancesenken- eine Plugin-Funktion testweise abschalten
- eine Farm begrenzen
- vor Events Chunks vorgenerieren
Schlechte erste Maßnahmen sind unscharf:
- „mehr RAM geben“
- „einfach alles optimieren“
- „irgendein Config-Pack einfügen“
Docker-spezifischer Hinweis
Spark läuft im Paper-Prozess selbst, deshalb ändert Docker die Profiling-Methode kaum. Docker verändert aber, wie du an Konsole und Logs kommst.
Nützliche Befehle rund um eine Profiling-Session:
docker compose logs -f mc
docker exec mc rcon-cli "spark profiler start --timeout 600"
Häufige Fehler
| Fehler | Warum er schadet | Bessere Lösung |
|---|---|---|
| Einen leeren Server profilen | Der echte Flaschenhals fehlt im Report | Unter realer Last messen |
| Mehrere Fixes gleichzeitig umsetzen | Du lernst nicht, was wirklich geholfen hat | Erst eine starke Maßnahme testen |
| Chunk- und Entity-Kontext ignorieren | Die teuerste Stelle im Profil bleibt abstrakt | Report immer mit Ingame-Verhalten verknüpfen |
| Jede rote Zahl gleich gewichten | Du ertrinkst in Rauschen | Zuerst dominante Verbraucher suchen |
FAQ
Was, wenn Spark überwiegend normale Werte zeigt, Spieler aber trotzdem klagen?
Dann tritt das Problem vielleicht nur zeitweise auf, ist netzwerkbedingt oder liegt außerhalb des eigentlichen Server-Ticks. Miss in dem Zeitfenster erneut, in dem es wirklich schlecht läuft.
Sollte ich trotzdem noch Timings nutzen?
Paper dokumentiert Timings als veraltet zugunsten von Spark und weist darauf hin, dass Spark für Einsteiger leichter lesbar ist.
Nächste Schritte
- Für die Grundlagen zu TPS und MSPT lies Minecraft-Server-Lag verstehen.
- Wenn der Report auf Chunk- oder Simulationsdruck zeigt, gehe weiter zu View Distance und Simulation Distance.
- Wenn dir noch der Admin-Zugang fehlt, richte RCON und Konsole in Docker sauber ein.