AEONHOST / WISSEN

Minecraft-Datapack-Funktionen und Command-Last untersuchen

Wenn ein Minecraft-Server bei einer bestimmten Aktion ruckelt, kann eine häufig aufgerufene Datapack-Funktion beteiligt sein. Prüfe zuerst, wann die Last auftritt, und nimm währenddessen ein kurzes Profil auf. So grenzt du den Auslöser ein, ohne Command-Grenzen oder Watchdog vorschnell abzuschalten.

Aktualisiert am 07.10.2026

Wenn ein Minecraft-Server bei einer bestimmten Aktion ruckelt, kann eine häufig aufgerufene Datapack-Funktion beteiligt sein. Prüfe zuerst, wann die Last auftritt, und nimm währenddessen ein kurzes Profil auf. So grenzt du den Auslöser ein, ohne Command-Grenzen oder Watchdog vorschnell abzuschalten.

Welche Datapack-Aufrufe besonders häufig laufen

Funktionen in der Tag-Gruppe minecraft:tick werden bei jedem Spieltick ausgeführt. Ein solcher Einstiegspunkt kann weitere Funktionen aufrufen oder viele Befehle ausführen. Achte deshalb auf Ketten mit mehreren function-Aufrufen und auf Befehle, die mit execute as @e viele Ausführungskontexte erzeugen. Das sind Prüfkandidaten, noch kein Beweis für die Ursache. Mojang beschreibt für Java 1.20.3 getrennte Grenzen für ausgeführte Operationen und erzeugte Kontexte. Dabei zählen auch Funktionsaufrufe und Schritte eines execute-Befehls, nicht nur Zeilen einer Datei. Die Versionsnotizen zu Java 1.20.3 führen maxCommandChainLength und die neue Regel maxCommandForkCount samt Beispiel für verschachtelte Entity-Auswahl auf.

Auch schedule function kann wiederkehrende Arbeit auslösen. Die Funktion wird mit einer Verzögerung in Spielticks eingeplant. Die Java-1.15-Entwicklung führte Mehrfachplanung sowie die Optionen append und replace ein; ohne explizite Option gilt replace. Prüfe daher, ob eine Funktion sich selbst erneut einplant, welche Termine entstehen und ob dabei append verwendet wird. Wiederholte Planung beweist allein keine unbegrenzt wachsende Warteschlange. Mojangs Hinweise zu Java 1.14 erklären die Verzögerung in Spielticks; der Snapshot 19w38b mit den Änderungen aus 19w38a belegt die Mehrfachplanung und die Notizen zu Buzzy Bees den Standardwert.

Last gezielt eingrenzen

  1. Notiere die genaue Java-Version, Server-Software, Welt, ungefähre Spielerzahl, Uhrzeit und Aktion, bei der das Ruckeln auftritt. Wiederhole später möglichst dieselbe Aktion. Ein Profil ohne das Problemfenster kann den Auslöser verfehlen.

  2. Prüfe die Tag-Datei zu minecraft:tick und folge ihren Funktionseinträgen. Die Tag-ID steht nicht zwangsläufig als Text in jeder aufgerufenen Funktionsdatei. Suche zusätzlich nach schedule function, append, execute as @e und aufgerufenen Funktionsnamen. Vergleiche die Kette mit dem Zeitpunkt des Problems und ändere beim Suchen keine Dateien.

  3. Wenn spark bereits verfügbar ist, starte die Aufnahme kurz vor der wiederholbaren Aktion:

    /spark profiler start --timeout 120

    Die 120 Sekunden sind ein begrenztes Beispiel, kein vorgeschriebener Messwert. Das Profil muss die fragliche Aktion enthalten. Paper bündelt spark ab Version 1.21; bei anderen Versionen oder Server-Software prüfst du zuerst, ob der Befehl vorhanden ist. Das Beispiel gilt im Spielchat mit der Berechtigung spark.profiler oder spark; in der Serverkonsole lässt du den führenden Schrägstrich weg. Prüfe mit spark profiler info in der Konsole, ob bereits eine Aufnahme läuft, bevor du eine weitere startest. Installiere für diese erste Diagnose kein zusätzliches Plugin auf einem laufenden Server. Die Paper-Anleitung zum Profilieren erklärt die Voraussetzung, das Problem während der Aufnahme zu reproduzieren; die spark-Befehlsreferenz bestätigt Statusabfrage, --timeout und Berechtigungen.

  4. Öffne das Profil und untersuche den Server-Thread während des notierten Zeitfensters. Wiederkehrende Funktions- oder Befehlsaufrufe sind ein Hinweis. spark zeigt Klassen und Methoden; ein Packname oder eine Funktions-ID muss dort nicht direkt erkennbar sein. Ordne die Aufrufkette deshalb den zuvor gelesenen Pack-Dateien zu. Ein einzelner hoher Eintrag beweist noch nicht, dass genau dieses Datapack die Ursache ist. Die spark-Viewer-Anleitung erklärt die Aussagekraft der Methodenansicht. Teile einen Profil-Link nur mit Personen, die ihn für die Diagnose benötigen.

  5. Wenn die Zuordnung offen bleibt, arbeite mit einer separaten Weltkopie. Sichere einen verwendbaren Stand, stoppe die Instanz vor dem Kopieren und vergleiche immer dieselbe Spielsituation. Deaktiviere auf der Kopie höchstens ein verdächtiges Pack pro Vergleich. Kehren Last und Profilbild mit dem Pack zurück, ist das ein stärkerer Hinweis als ein einzelner hoher Eintrag im Profil. Verändere nicht gleichzeitig Pack, Server-Version und weitere Einstellungen.

Was du bei einem Treffer änderst

Eine häufig laufende minecraft:tick-Funktion muss nicht automatisch falsch sein. Prüfe zuerst, ob ihre Arbeit bei jedem Tick nötig ist, ob eine Entity-Auswahl unnötig breit ist und ob eine Funktionskette denselben Schritt mehrfach erreicht. Bei einer verzögerten Funktion zählt, ob ihre Planung wiederholt wird und ob append oder replace zum beabsichtigten Ablauf passt. Ändere nur die nachgewiesene Stelle und vergleiche danach dasselbe Zeitfenster erneut.

Erhöhe Command-Grenzen nicht blind und schalte den Watchdog nicht als Lag-Lösung ab. Die oben genannten Gamerule-Namen gehören zum Java-1.20.3-Beleg. Seit Java 1.21.11 heissen sie minecraft:max_command_sequence_length und minecraft:max_command_forks. Prüfe die Namen und zulässigen Werte deiner laufenden Version. Wenn eine Grenze greift, reduziere zuerst unnötige Aufrufe und Ausführungskontexte; ein höheres Limit macht die Arbeit nicht schneller.

Wenn das Profil keine Funktionslast zeigt, prüfe andere Serverursachen mit der Anleitung zu Minecraft-Server-Lag. Für Ablage, Aktivierung und Versionskompatibilität eines Packs dient der separate Guide Datapacks installieren und prüfen. Die einzelnen spark-Ansichten erklärt Minecraft mit spark gezielt untersuchen.

Quellen