Ein Paper-Server kann reichlich RAM haben und trotzdem mit 14 TPS laufen, wenn sich 25 Spieler verteilen, Farmen geladen bleiben und jeder Trichter gleichzeitig zu ticken beginnt. Die besten Paper-Server-Einstellungen sind kein zufälliges „Anti-Lag“-Preset. Sie sind eine Reihe von Entscheidungen, die zu deiner Welt, Spielerzahl, deinen Plugins und Gameplay-Regeln passen, ohne still und leise Redstone oder Mob-Farmen kaputt zu machen.
Paper verbessert die Vanilla-Leistung bereits, aber seine Standardwerte sind so ausgelegt, dass sie für eine breite Palette von Servern sicher sind. Ein privater SMP mit 10 Freunden kann Einstellungen fahren, die sich auf einem öffentlichen Survival-Netzwerk einschränkend anfühlen würden. Fang mit den Änderungen an, die unnötige Arbeit pro Tick reduzieren, und teste sie dann unter echter Spielerlast.
Fang mit deinen Distanzen an
View-distance und simulation-distance sind die größten Leistungsregler, die die meisten Admins ändern können, ohne fortgeschrittene Config-Dateien anzufassen. Sie beeinflussen zwei verschiedene Dinge.
View-distance legt fest, wie weit Chunks an einen Spieler gesendet werden. Höhere Werte sehen besser aus, verbrauchen beim Erkunden aber mehr Bandbreite, Speicher und CPU. Simulation-distance legt fest, wie weit Chunks aktiv Spiellogik verarbeiten, darunter Mobs, Redstone, Pflanzen, Flüssigkeiten und viele Farm-Mechaniken. Oft ist das die Einstellung, die entscheidet, ob die TPS auf einem vollen SMP stabil bleiben.
Für die meisten Survival-Server fängst du in server.properties mit diesen Werten an:
view-distance=8
simulation-distance=5
Acht Chunks view-distance fühlen sich für normales Survival-Spiel weiterhin gut an, besonders wenn Spieler zusammen bauen, abbauen oder erkunden. Eine simulation-distance von fünf erhält einen praktischen lokalen Spielbereich und verhindert, dass entfernte Chunks Tick-Zeit verbrauchen.
Ist dein Server eine kleine, entspannte Whitelist-Welt auf starker Hardware, versuch view-distance 10 und simulation-distance 6. Ist es ein öffentlicher Server, auf dem Spieler ständig in verschiedene Richtungen reisen, sind 6 bis 8 view-distance und 4 bis 5 simulation-distance meist der sicherere Bereich. Dreh nicht beides auf 12, nur weil der Server erfolgreich startet. Der echte Test ist ein Samstagabend, an dem Spieler neues Gelände laden.
Generier die Welt vor, bevor du sie öffnest
Chunk-Generierung ist eine der teuersten Aufgaben in Minecraft. Keine Paper-Einstellung kann voll ausgleichen, dass 20 Spieler in entgegengesetzte Richtungen fliegen und gleichzeitig frische Chunks generieren.
Generier Oberwelt, Nether und End vor dem Start vor, besonders bei öffentlichen SMPs und Communities von Content-Creatorn. Setz eine vernünftige Weltgrenze und generier dann den Spielbereich, solange der Server sonst leer ist. Die Spieler bekommen schnelleres Chunk-Laden, die Speicheraktivität bleibt berechenbarer, und deine CPU hat mehr Raum für Mobs und Plugins — der vollständige Ansatz steht in unserem Guide zum Reduzieren der Chunk-Ladelast.
Das zählt selbst auf schneller Ryzen- oder EPYC-Hardware mit NVMe-Gen4-Speicher. Großartige Hardware verkürzt den Schmerz, aber die Last zu verhindern, ist besser, als darauf zu reagieren. Wächst deine Community über die anfängliche Grenze hinaus, erweitere sie und generier erneut vor, statt die Erkundung am Starttag zum TPS-Stresstest werden zu lassen.
Stimm die Entity-Aktivierung ab, nicht nur Mob-Limits
Die Entity-Aktivierungsreichweite — eine Spigot-Einstellung, die Paper übernimmt — bestimmt, wann Entities in der Nähe ihre normale KI und ihr Tick-Verhalten ausführen. Einfach gesagt: Ein Zombie weit weg von jedem Spieler muss nicht jeden Spieltick über Wegfindung nachdenken.
Sie steht in spigot.yml, unter world-settings → default → entity-activation-range (nicht in den eigenen Config-Dateien von Paper). Ein ausgewogener Ausgangspunkt für einen Survival-Server ist:
world-settings:
default:
entity-activation-range:
animals: 24
monsters: 32
raiders: 48
misc: 16
water: 16
villagers: 24
Diese Werte reduzieren Hintergrundarbeit von Entities, ohne dass sich die Welt leer anfühlt. Monster bleiben nah an Spielern aktiv, während entfernte Mobs aufhören, ohne nützlichen Grund CPU zu verbrennen. Dorfbewohner verdienen besondere Aufmerksamkeit: Sie können wegen KI, Arbeitsplätzen, Betten, Klatsch und Wegfindung teuer sein. Halte ihre Aktivierungsreichweite moderat, es sei denn, dein Server stützt sich stark auf große Handelshallen.
Setz nicht jede Zahl extrem niedrig. Das kann Farmen unzuverlässig machen, Entities einfrieren, von denen Spieler normales Verhalten erwarten, und verwirrende Meldungen erzeugen wie „meine Dorfbewohner vermehren sich nicht mehr“. Bei der Paper-Optimierung geht es darum, Verschwendung zu reduzieren, nicht darum, Minecraft abzuschalten.
Für die Mob-Dichte nutzt du die Einstellungen spawn-limits und ticks-per-spawn in config/paper-world-defaults.yml mit Bedacht. Ein Server, der um Mob-Grinder gebaut ist, braucht womöglich höhere Limits als ein lockerer Towny-SMP. Beschweren sich Spieler, dass die Nächte leer wirken, erhöh die Limits in kleinen Schritten und beobachte die TPS. Fünf Leistungsvariablen auf einmal zu ändern, macht die Fehlersuche fast unmöglich.
Distanzen stehen in server.properties. Entity-Aktivierungsreichweite und Item-Merge-Radius stehen in spigot.yml. Trichter, Despawn-Reichweiten, Spawn-Limits und die Redstone-Implementierung stehen in config/paper-world-defaults.yml — und jede einzelne Welt kann sie in ihrer eigenen paper-world.yml im Welt-Ordner überschreiben. Wer die Datei kennt, bearbeitet keinen Schlüssel, der nichts bewirkt.
Mach Trichter und Redstone günstiger
Trichter sind eine klassische Quelle unsichtbaren Lags. Ein Trichter prüft wiederholt Inventare, was in Ordnung ist. Hunderte oder Tausende davon unter Sortiersystemen, Farmen und Lagerwänden sind eine andere Geschichte.
Nutz in config/paper-world-defaults.yml die Trichter-Optionen, um sinnlose Prüfungen zu reduzieren:
hopper:
cooldown-when-full: true
disable-move-event: true
ignore-occluding-blocks: true
cooldown-when-full ist meist ein einfacher Gewinn, weil ein voller Trichter nicht jeden Tick versuchen muss, Items zu bewegen. Bewegungsereignisse abzuschalten, kann erheblich helfen, hat aber einen Haken: Plugins, die auf Inventar-Bewegungsereignisse hören, können davon abhängen. Prüf deinen Plugin-Stack, bevor du es aktivierst, und teste dann gängige Systeme wie Shops, Claims und eigene Item-Sortierer. ignore-occluding-blocks lässt Trichter Behälter überspringen, die in festen Blöcken versteckt sind, was Prüfungen spart, aber das Verhalten einiger technischer Konstruktionen ändern kann.
Redstone lässt sich schwerer „optimieren“, ohne Spielerbauten zu beeinflussen. Paper's Alternate-Current-Implementierung (redstone-implementation) kann große Redstone-Netze verbessern, verhält sich in Randfällen aber womöglich anders als Vanilla. Nutz sie nur, wenn deine Community nicht auf technische Minecraft-Präzision angewiesen ist, oder teste sie zuerst auf einer Kopie der Welt. Für technische Server ist es meist ein bisschen zusätzliche CPU-Zeit wert, das erwartete Verhalten zu erhalten.
Nutz Despawn-Reichweiten, um vergessene Mobs aufzuräumen
Spieler lassen oft Mobs zurück: Tiere aus verlassenen Gehegen, Monster in Höhlen, fallengelassene Items nach PvP und Boote oder Loren in der Nähe alter Basen. Diese Entities summieren sich über Wochen.
Paper lässt dich Despawn-Reichweiten nach Mob-Kategorie konfigurieren. Halte die weichen Despawn-Reichweiten moderat, damit Entities weit weg von Spielern natürlich verschwinden, während harte Despawn-Reichweiten verhindern, dass riesige versteckte Haufen ewig geladen bleiben. Sei bei Tieren und Dorfbewohnern vorsichtig. Aggressives Despawnen kann legitimen Farmen schaden und Spielern das Gefühl geben, der Server lösche ihre Arbeit.
Für fallengelassene Items passt du den Merge-Radius in spigot.yml an, statt Hunderte einzelne Item-Entities auf dem Boden liegen zu lassen. Ein vernünftiger Merge-Radius reduziert die Entity-Zahl um Farmen und Mob-Grinder, während Spieler Beute weiterhin normal einsammeln können. Teste das mit eigenen Items und Plugins, die fallengelassenen Items Daten anhängen.
Kontrollier die Plugins, die den TPS wirklich schaden
Ein schlechtes Plugin kann jeden Gewinn aus der besten Paper-Konfiguration zunichtemachen. Häufige Störenfriede sind veraltete Anticheat-Tools, schlecht konfigurierte Karten-Renderer, übermäßige Scoreboard-Updates, Chat-Formatierung mit schweren Datenbankabfragen und Plugins, die nach Zeitplan jeden geladenen Chunk scannen.
Fallen die TPS, profiliere, bevor du blind Einstellungen änderst. Prüf, ob der Haupt-Thread Zeit mit Entities, Chunk-Laden, Redstone, geplanten Aufgaben oder einem bestimmten Plugin verbringt. Ein Plugin, das für jeden Online-Spieler in jedem Tick eine kleine Aufgabe erledigt, wird schnell teuer — lies, wie du Paper-Plugins installierst, ohne die TPS zu ruinieren, und unsere Liste der Anti-Lag-Plugins, die sich lohnen.
Halte deinen Paper-Build und deine Plugins aktuell, aber aktualisiere mit einem Plan zum Zurücksetzen. Sichere Welt und Plugin-Daten vor größeren Updates und teste neue Versionen außerhalb der Stoßzeiten. Automatische Backups sind nicht glamourös — bis ein inkompatibles Update eine Welt beschädigt oder Spielerinventare zurücksetzt.
JVM und Hardware zählen trotzdem
Paper-Einstellungen können keine langsame Single-Core-Leistung der CPU beheben. Die Haupt-Tick-Schleife von Minecraft stützt sich stark auf einen schnellen Kern, weshalb hochgetaktete Ryzen- und EPYC-Infrastruktur mehr zählt als eine riesige Kernzahl auf schwacher Hardware.
Gib dem Server genug RAM für seine Welt, Plugins und Spielerzahl, aber behandle RAM nicht als einzige Leistungskennzahl. Mehr Speicher löst keinen Engpass im Haupt-Thread. Für einen kleinen Paper-SMP können 4 GB reichen; ein Plugin-lastiger Community-Server oder eine große vorgenerierte Welt braucht womöglich 8 GB oder mehr. Beobachte den tatsächlichen Verbrauch, bevor du hochstufst — unsere Analyse, wie viel RAM ein Paper-Server braucht, liefert die Zahlen.
Nutz moderne JVM-Flags, die zu deiner Java-Version passen, und kopier keine uralten Start-Strings aus Forenbeiträgen. Bietet dein Hosting-Panel ein getestetes Paper-Preset, nimm es als Basis. Bei Managed-Minecraft-Hosting wie Elysium besteht die nützliche Arbeit darin, Server-Konfiguration, Backups, Speicher und CPU-Zuteilung verlässlich zu halten, damit du dich auf das konzentrieren kannst, was Spieler wirklich bemerken: stabile TPS und eine Welt, die morgen noch da ist.
Teste Änderungen wie ein Admin, nicht wie beim Raten
Ändere eine Kategorie nach der anderen, starte neu, wenn nötig, und teste mit realistischer Aktivität. Lass Spieler erkunden, Farmen laufen lassen, mit Dorfbewohnern handeln, Portale nutzen und die vollste Basis besuchen. Ein Server, der ohne Spieler online 20 TPS meldet, hat keinen Leistungstest bestanden.
Bewahr vor größeren Abstimmungen eine Kopie jeder funktionierenden Konfiguration auf. Verbessert eine Einstellung die TPS, macht aber eine wichtige Farm oder ein Plugin kaputt, setz sie zurück und nimm den kleineren Gewinn. Dein bestes Setup ist das, das flüssig bleibt und gleichzeitig die Art Minecraft erhält, für die deine Community gekommen ist. Brauchst du noch mehr Stellschrauben, baut Purpur auf Paper auf und bringt zusätzliche Gameplay- und Leistungsoptionen.
Elysium betreibt Paper-Server auf hochgetakteten Ryzen-CPUs mit NVMe Gen4, automatischen Backups und einem Pterodactyl-Panel, in dem server.properties, spigot.yml und Paper-Configs nur einen Klick entfernt sind. Sieh dir Paper-Hosting an, wähl einen Tarif auf der Bestellseite oder lass uns deinen aktuellen Server umziehen.