Die simulation-distance zu senken ist nicht dasselbe, wie die view-distance zu senken. Das eine ändert den spielerzentrierten Bereich, den der Server simuliert; das andere steuert, wie viele Geländedaten er an die Spieler sendet. Eine ferne Landschaft kann sichtbar bleiben, obwohl sich eine Farm dort nicht mehr so verhält, wie ihr Besitzer es erwartet.
Diese Unterscheidung ist wichtiger, als eine als „optimiert“ bezeichnete Konfiguration zu finden. Ein ruhigerer Server ist kaum eine Verbesserung, wenn Dorfbewohner nicht mehr auffüllen oder eine etablierte AFK-Stelle nicht mehr funktioniert. Ziel ist es, Arbeit zu entfernen, auf die Ihre Community verzichten kann, und dann zu prüfen, ob das gewünschte Gameplay weiterhin funktioniert.
Dieses Tutorial behandelt moderne Minecraft-Java-Edition-Server. Die Distanzeinstellungen gelten für Vanilla, Spigot und Paper; Plugin-Befehle und YAML-Einstellungen sind gesondert gekennzeichnet. Es ist kein universelles Rezept für Bedrock, Modpacks oder Folia. Prüfen Sie die Dokumentation anhand Ihrer genauen Serverversion: Aktuelle Referenzen können neuere Versionen beschreiben, und weder Standardwerte noch Dateistrukturen bleiben für immer gleich.
1. Das Problem messen, während es auftritt
Notieren Sie Ihre Minecraft-Version, die Server-Software und den Build, die Spielerzahl und was die Spieler tun, wenn die Verlangsamung auftritt. Eine belebte Handelshalle und eine Gruppe, die neues Gelände erkundet, sind unterschiedliche Lasten. Das Profiling eines leeren Servers erklärt keines von beiden; die Dokumentation von Paper verlangt ausdrücklich, dass das Problem während der Datenerfassung auftritt.
Bei Paper ist spark seit Version 1.21 mitgeliefert. Installieren Sie bei Spigot zuerst ein kompatibles eigenständiges spark-Plugin; die folgenden Befehle sind in einem unveränderten Vanilla-Server nicht enthalten.
Führen Sie diese im Spiel mit den erforderlichen Berechtigungen aus:
/spark tps
/spark profiler start --timeout 600
Der Profiler-Befehl zeichnet zehn Minuten lang auf und liefert eine Report-URL zurück. Speichern Sie diesen Report zusammen mit Ihrer Konfiguration und Ihren Notizen zur Auslastung.
Bei der normalen Tick-Rate zielt Minecraft auf 20 TPS und lässt damit 50 Millisekunden pro Tick. MSPT beschreibt, wie lange Ticks dauern, und zeigt daher Belastung, die ein TPS-Wert allein verbergen kann. Vergleichen Sie den Median und das 95. Perzentil des MSPT: Letzteres hilft, wiederkehrende langsame Ticks aufzudecken, kann aber seltene Spitzen übersehen. Prüfen Sie auch das Maximum, statt ein gesundes Perzentil als Beweis zu werten, dass nichts gehangen hat.
Bei sporadischen Problemen kann der Tick-Monitor von spark Ticks markieren, die dieses Budget überschreiten:
/spark tickmonitor --threshold-tick 50
Notieren Sie, was im selben Moment passiert ist. Wenn die Tick-Zeiten während der Beschwerde gesund bleiben, untersuchen Sie die Bildrate des Clients oder die Netzwerkbedingungen, bevor Sie Server-Gameplay opfern.
2. Sichern und feststellen, welche Einstellungen tatsächlich gelten
Stoppen Sie den Server vor dem Bearbeiten sauber und sichern Sie Welten, Konfigurationsdateien und Plugin-Daten. Bewahren Sie das Backup außerhalb des laufenden Serververzeichnisses auf und prüfen Sie, ob Sie es wiederherstellen können. Eine Kopie der Konfiguration erleichtert das Zurücksetzen; ein Welt-Backup schützt die Arbeit dahinter.
Verwenden Sie einen Texteditor, behalten Sie die YAML-Einrückung bei und ändern Sie pro Experiment nur eine Sache. Starten Sie den Server danach normal und prüfen Sie das Startprotokoll auf Konfigurationsfehler. Verwenden Sie nicht /reload oder einen Plugin-Hot-Loader als Abkürzung; das Neuladen von Plugins kann Abhängigkeiten und Zustand inkonsistent zurücklassen.
Beginnen Sie bei Vanilla mit server.properties. Prüfen Sie bei Spigot und Paper zusätzlich spigot.yml: Distanzeinstellungen pro Welt können die Properties-Datei überschreiben.
Dieses Fragment zeigt Vererbung, keine Performance-Voreinstellung:
world-settings:
default:
view-distance: default
simulation-distance: default
Hier weist default diese Optionen an, server.properties zu verwenden. Führen Sie die Schlüssel in den bestehenden Abschnitt ein; ersetzen Sie nicht die gesamte Datei und fügen Sie keinen zweiten world-settings-Block hinzu. Prüfen Sie auch Abschnitte benannter Welten, denn ein weltspezifischer Wert kann die gemeinsame Einstellung überschreiben.
Wenn Sie numerische Überschreibungen durch Vererbung ersetzen, behandeln Sie das als separate Änderung und erfassen Sie eine neue Baseline. Sonst ändern Sie womöglich mehrere wirksame Distanzen, bevor Ihr erster kontrollierter Test läuft.
3. Geländesichtbarkeit von Simulation trennen
Beide Distanzen werden in Chunks um den Spieler gemessen, nicht in Blöcken oder als Durchmesser.
- view-distance steuert die Menge an Weltdaten, die an den Client gesendet wird. Wenn Sie sie senken, tauschen Sie Sichtbarkeit fernen Geländes gegen weniger Arbeit, die damit verbunden ist, diese Sicht verfügbar zu halten.
- simulation-distance steuert den spielerzentrierten Tick-Bereich. Eine Reduzierung kann die Simulationsarbeit verringern, ändert aber auch den Bereich, in dem nahe Farmen und Entities funktionieren.
Die View-Distance ist nicht kostenlos, nur weil manches Gelände außerhalb der Simulationsdistanz liegt. Ebenso ersetzt ihre Reduzierung nicht die Behebung eines kostspieligen Plugins. Wählen Sie das erste Experiment anhand des Profils und des Gameplay-Kompromisses, den Sie akzeptieren können.
Eine Distanzänderung ausprobieren
Angenommen, Ihre bestehende server.properties enthält:
view-distance=10
simulation-distance=10
Wenn das Profil auf Tick-Arbeit in geladenen Bereichen hindeutet, besteht ein Experiment darin, die View-Distance unverändert zu lassen und die Simulationsdistanz etwas zu senken:
view-distance=10
simulation-distance=8
Diese Zahlen sind Beispiele, keine universellen Standardwerte und keine getestete SharpHeberg-Voreinstellung. Wenn Ihre bestehende View-Distance abweicht, lassen Sie Ihren eigenen Wert unangetastet. Starten Sie sauber neu, reproduzieren Sie die ursprüngliche Auslastung und erfassen Sie einen weiteren Report, bevor Sie weiter reduzieren.
Wenn das Profil stattdessen nahelegt, dass die Pflege oder das Senden fernen Geländes das Problem ist, testen Sie die View-Distance separat. Senken Sie nicht beide Einstellungen zusammen, um dann zu raten, was geholfen hat.
Die Simulationsdistanz ist kein vollständiges Regelwerk für Farmen. Chunk-Tickets, die Chunks aus bestimmten Gründen geladen halten, und Näheanforderungen an Spieler unterscheiden sich je nach Mechanik und Version. „Geladen“ garantiert nicht, dass Spawning, Pflanzenwachstum, Entities und Block-Entities sich alle gleich verhalten. Prüfen Sie die Anforderungen Ihrer konkreten Farm, statt anzunehmen, dass eine einzelne Distanz den Betrieb garantiert.
Auch natürliches Spawnen und Despawnen haben eigene Distanzregeln; Spigots mob-spawn-range und die Despawn-Einstellungen von Paper bieten weitere Stellschrauben. Wenn eine Farm nach dem Experiment nicht mehr funktioniert, stellen Sie zuerst die vorherige Distanz wieder her. Gleichen Sie das nicht sofort durch Änderungen an mehreren Spawn-Einstellungen aus.
4. Bei Spigot oder Paper die Entity-Arbeit prüfen, bevor Reichweiten gekürzt werden
Wenn das Profil auf die Entity-Verarbeitung hindeutet, untersuchen Sie den betroffenen Bereich. Achten Sie auf sich ansammelnde fallengelassene Items, überfüllte Gehege oder eine Handelshalle, die unnötige Arbeit verrichtet. Stimmen Sie sich mit den Besitzern ab, bevor Sie Bauten ändern. Eine erkannte Quelle übermäßiger Arbeit zu reduzieren ist leichter zu bewerten, als das Entity-Verhalten überall abzuschwächen.
Zwei ähnlich benannte spigot.yml-Optionen erfüllen unterschiedliche Aufgaben:
| Einstellung | Einheit | Was sie steuert |
|---|---|---|
entity-activation-range |
Blöcke | Wie nah Entities an Spielern sein müssen, um normal zu ticken; das Verhalten außerhalb der Reichweite wird gedrosselt. |
entity-tracking-range |
Blöcke | Wie weit entfernte Entities an Spieler gesendet werden, was beeinflusst, wann sie sichtbar werden. |
Das sind Entity-Steuerungen, nicht die oben genannten Chunk-basierten Distanzen. Eine niedrigere Tracking-Reichweite kann Mobs abrupt erscheinen lassen; sie ist nicht gleichbedeutend mit einer geringeren KI-Last.
Änderungen an der Aktivierung erfordern besondere Vorsicht bei Eisenfarmen und Dorfbewohnern. Community-Leitfäden dokumentieren defekte Farmen und Probleme beim Auffüllen durch zu aggressive Aktivierungs- oder Inaktiv-Dorfbewohner-Änderungen. Lassen Sie diese Einstellungen unangetastet, sofern das Profiling den Kompromiss nicht rechtfertigt, und testen Sie dann die betroffene Entity-Kategorie, statt eine komplette Voreinstellung zu kopieren.
Dieselbe Vorsicht gilt für nerf-spawner-mobs, das Hopper-Timing und Änderungen am Item-Merging: Sie verändern das Verhalten, nicht nur den Ressourcenverbrauch. Nehmen Sie als erste Reaktion auf Lags keine pauschalen Kürzungen der Mob-Caps vor und installieren Sie keine zeitgesteuerte Entity-Löschung.
5. Paper-Einstellungen als versionsspezifische Steuerungen behandeln
Paper hat zusätzliche Konfigurationsebenen. Die dokumentierte Struktur umfasst config/paper-global.yml für globale Einstellungen und config/paper-world-defaults.yml für gemeinsame Welteinstellungen. Die paper-world.yml einer Welt kann diese Welt-Standardwerte überschreiben.
Finden Sie diese Überschreibungsdatei anhand der Dokumentation für Ihren Build. Verzeichnisstrukturen von Welten und Dimensionen variieren; ein Pfad aus einem älteren Tutorial kann Sie an die falsche Stelle führen. Kopieren Sie nur die Einstellungen, die Sie überschreiben möchten, nicht die gesamte Standarddatei.
Paper bietet Steuerungen für Spawning, Despawning, Kollisionen und Hopper-Verhalten. Das sind Optionen für ein erkanntes Problem, keine Checkliste zum Abarbeiten. Zum Beispiel kann das Deaktivieren des Hopper-Move-Events Schutz-Plugins brechen, die darauf angewiesen sind. Eine kleine Timing-Verbesserung rechtfertigt es nicht, stillschweigend eine Serverregel zu umgehen.
Die zitierte spigot.yml-Referenz wird von Paper gepflegt und enthält Paper-spezifisches Verhalten. Nehmen Sie nicht an, dass jede dort dokumentierte verschachtelte Option bei reinem Spigot existiert oder sich identisch verhält. Konsultieren Sie die generierte Konfiguration für Ihre Implementierung und Version, bevor Sie einen Schlüssel hinzufügen.
6. Dem Profil über Distanzeinstellungen hinaus folgen
Plugin-Arbeit untersuchen
Wenn der Report auf eine Plugin-Aufgabe verweist, speichern Sie den Report und prüfen Sie Konfiguration, Kompatibilität und Release Notes dieses Plugins. Paper empfiehlt ausdrücklich, bei der Untersuchung von Performance-Problemen einen relevanten spark-Report mit den Plugin-Entwicklern zu teilen.
Reproduzieren Sie das Problem nach Möglichkeit auf einer gesicherten Testkopie. Ändern Sie jeweils nur eine Funktion oder ein Plugin, unter Beachtung der Abhängigkeiten, und wiederholen Sie dann dieselbe Aktivität. Vermeiden Sie es, Schutz- oder Wirtschafts-Plugins auf dem Live-Server zu deaktivieren, nur um zu sehen, ob die TPS steigen.
Halten Sie auch Java- und Speicher-Tuning evidenzbasiert. Prüfen Sie das Garbage-Collection-Verhalten und die Java-Anforderungen Ihres genauen Server-Builds, bevor Sie Startoptionen ändern. Eine kopierte Sammlung von GC-Flags ist kein universeller Optimierungsschritt.
Nur dann vorgenerieren, wenn die Generierung das Problem ist
Wenn die Verlangsamung mit Erkundung zusammenfällt, vergleichen Sie Reisen durch vorhandenes Gelände mit Reisen in neues Gelände. Wenn das Profiling die Chunk-Generierung als Engpass stützt, verlagert Pregeneration diese Generierungsarbeit vor das normale Spielgeschehen. Chunky bietet dafür Werkzeuge.
Wählen Sie den gewünschten Bereich und die Dimensionen, prüfen Sie Speicherplatz und Backup-Kapazität und planen Sie die Arbeit außerhalb der Stoßzeiten. Testen Sie zuerst einen begrenzten Bereich. Pregeneration beseitigt nicht den Aufwand, vorhandene Chunks zu laden oder zu senden oder darin Farmen zu betreiben.
Community-Leitfäden sind sich uneinig, wie breit Pregeneration für moderne Server empfohlen werden sollte. Betrachten Sie sie als Reaktion auf gemessenen Generierungsdruck, nicht als Pflichtwartung für jede Paper-Installation.
7. Das Gameplay prüfen, bevor Sie die Änderung behalten
Wiederholen Sie die ursprüngliche Auslastung mit vergleichbarer Spielerzahl und -verteilung. Bewahren Sie die spark-Reports vorher und nachher, den Konfigurationsunterschied und die Notizen zusammen auf. Wiederholen Sie den Vergleich, wenn sich die Bedingungen erheblich geändert haben.
Testen Sie dann den Server so, wie die Spieler ihn nutzen:
- Betreiben Sie wichtige Farmen von ihren üblichen AFK-Positionen aus, einschließlich Einsammeln und Transport.
- Prüfen Sie Dorfbewohner-Handel und Auffüllen über einen normalen Arbeitszyklus.
- Lassen Sie Hopper-Sortierer und Uhren lange genug laufen, um verpasste Items oder verändertes Timing aufzudecken.
- Prüfen Sie Sichtbarkeit und Verhalten von Mobs während des Reisens und testen Sie jede betroffene Welt.
Behalten Sie eine Änderung nur, wenn die gemessene Verbesserung nützlich und der Gameplay-Kompromiss akzeptabel ist. Wenn der Nutzen unklar ist, stellen Sie den vorherigen Wert wieder her. Deaktivieren Sie niemals das Speichern, nur damit ein Performance-Diagramm besser aussieht.
Wenn der verbleibende Engpass offenbar die Hosting-Kapazität ist, nutzen Sie den Report als Grundlage für dieses Gespräch. Sie können das Minecraft-Hosting von SharpHeberg neben Ihrer Auslastung und Ihren Anforderungen prüfen. Hosting-Entscheidungen und Konfigurationsänderungen verdienen denselben Test: Läuft der Server besser und bleibt dabei die Spielweise Ihrer Community erhalten?
Weiterführende Lektüre: Die wahren Kosten eines Hochleistungs-Minecraft-Servers 2025. Betrachten Sie sämtliche Preise in diesem älteren Artikel als historisch, nicht als aktuelle Tarife.
Quellen
Minecraft optimization — Community-Leitfaden