Serveraktivität mit Spark aufzeichnen
Paper dokumentiert Spark als bevorzugten Profiler und bündelt ihn ab 1.21 direkt mit.
Ein Profil zeigt, wofür der Server Rechenzeit benötigt. Du kannst den Bericht bei der Fehlersuche auch 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
Prüfe:
- allgemeine Tick-Gesundheit
- die teuersten Bereiche oder Aufgaben
- Konzentration auf ein Plugin, ein Gebiet oder ein Subsystem
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
Wähle die Änderung anhand des Profils und wiederhole die Messung unter derselben Last.
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 | Kleine Kosten lenken vom größten Engpass ab | Zuerst dominante Verbraucher suchen |