Wenn du dich fragst, warum dein Minecraft-Server laggt, liegt es in 90 % der Fälle an einem von sechs Dingen: zu wenig RAM und Garbage Collection, ein schwacher CPU-Kern, schwere Plugins, Mobs und Farmen, eine langsame Festplatte oder eine zu hohe view-distance. Die gute Nachricht: Fast alles davon lässt sich mit ein paar Befehlen diagnostizieren und beheben, ohne die Welt neu aufzusetzen. Gehen wir Schritt für Schritt durch: wie du den Lag misst, den Schuldigen findest und ihn loswirst.

Kläre zuerst: Server-Lag oder Client-Lag?

Bevor du irgendetwas reparierst, musst du wissen, wo das Problem wirklich liegt. „Lag“ ist ein zu weiter Begriff, und Spieler verwechseln oft drei verschiedene Dinge.

  • Server-Lag — die TPS sinken. Die Welt verlangsamt sich für alle gleichzeitig: Mobs ruckeln, Treffer werden nicht registriert, Blöcke brechen verzögert. Genau das kannst du als Admin beheben.
  • Client-Ruckler (niedrige FPS) — das Bild ruckelt nur bei einem Spieler. Schuld sind sein PC, seine Grafikkarte oder Shader, nicht der Server.
  • Ping (Netzwerk-Lag) — die Verzögerung zwischen Spieler und Server. Der Spieler spürt „Rubber-Banding“, aber die TPS auf dem Server stehen weiter bei 20.0. Abhilfe schafft ein näherer Standort.

Ein einfacher Test: Tritt dem Server bei und gib /tps ein. Steht dort konstant 20.0 und jemand beschwert sich über Lag, liegt das Problem bei ihm (PC oder Internet), nicht bei dir. Sind die TPS gesunken — willkommen an Bord, der Rest dieses Artikels betrifft dich.

TPS und MSPT: zwei Zahlen, die du verstehen musst

Ein Minecraft-Server arbeitet in Ticks — das sind die „Frames“ der Spiellogik. Pro Sekunde sollen genau 20 Ticks vergehen, und jeder Tick muss in 50 Millisekunden oder weniger verarbeitet werden (1000 ms / 20 = 50). Daraus ergeben sich zwei zentrale Kennzahlen.

KennzahlWas sie bedeutetZielWann es schlecht ist
TPS (Ticks pro Sekunde)Wie viele Ticks der Server pro Sekunde schafft20.0Unter 18 spürbar, unter 15 schmerzhaft
MSPT (Millisekunden pro Tick)Wie viele Millisekunden ein einzelner Tick dauert< 50 msÜber 50 ms — die TPS beginnen zu sinken

MSPT ist die ehrlichere und empfindlichere Kennzahl. Die TPS können 20 nicht überschreiten, deshalb zeigen sie auf einem „gesunden“ Server immer 20.0 und sagen nichts über deine Reserve. Die MSPT zeigen die Wahrheit: Dauert ein Tick 45 ms, liegen die TPS zwar noch bei 20, aber fast ohne Spielraum — eine Spitze, und der Server gerät ins Stocken. Behalte also vor allem die MSPT im Blick: Je niedriger und stabiler, desto mehr Luft hast du für mehr Spieler.

Lag messen: spark, /tps und /mspt

Die Ursache von Lags zu erraten führt in eine Sackgasse. Du musst messen. Auf Server-Software der Paper-Familie (einschließlich Purpur) gibt es eingebaute Befehle und einen Profiler.

Schnellcheck

/tps     # durchschnittliche TPS über 5s / 1m / 5m / 15m
/mspt    # durchschnittliche, minimale und maximale MSPT der letzten Ticks

/tps zeigt vier Zahlen — den Momentanwert und die Durchschnitte über die einzelnen Zeiträume. Ist der letzte Wert (15 Min.) niedrig, ist der Lag chronisch. Sinkt nur der Momentanwert, hast du kurze Spitzen statt eines dauerhaften Einbruchs und solltest nach einem einmaligen Ereignis suchen (ein Creeper sprengt eine Redstone-Anlage, ein neuer Spieler lädt Chunks).

Der spark-Profiler — dein wichtigstes Werkzeug

Früher nutzte man zur Diagnose /timings, aber im modernen Paper ist Timings deaktiviert und durch spark ersetzt — das empfehlen die Paper-Entwickler selbst. Spark erstellt ein Sampling-Profil des Hauptthreads und zeigt dir genau, welcher Code die Tick-Zeit frisst.

/spark profiler start
# ... 3-5 Minuten unter normaler Last warten ...
/spark profiler stop      # liefert dir einen Link zum Bericht

# für seltene Spitzen — nur die schweren Ticks profilieren:
/spark profiler start --only-ticks-over 60

Im Bericht siehst du einen Aufrufbaum: zum Beispiel, dass 40 % der Zeit auf EntityLiving.tick (Mobs) oder auf ein bestimmtes Plugin entfallen. Das ist dein Schuldiger. Zusätzlich zeigt /spark health CPU-Auslastung und Speicherverbrauch. Du weißt nicht, wie man einen Flame Graph liest? Fang mit den „dicksten“ Ästen oben an — sie fressen die meiste Zeit.

Tipp

Profiliere den Server unter echter Last — wenn die Spielerzahl ihren Höhepunkt erreicht und die Farmen laufen. Ein Profil eines leeren Servers in der Nacht zeigt ein perfektes Bild und sagt dir nichts.

Ursache 1. Zu wenig RAM und Garbage Collection (GC)

Die häufigste — und tückischste — Lag-Ursache ist nicht der Speichermangel an sich, sondern die Pausen des Garbage Collectors. Wenn dem Server Heap fehlt, startet die JVM ständig die Garbage Collection, um Platz zu schaffen. Jede dieser Sammlungen ist ein Mikro-Freeze: Der Hauptthread hält an, der Tick zieht sich in die Länge, die TPS sinken. Von außen sieht das wie rhythmische Lag-Spitzen alle paar Sekunden aus.

Das Paradoxe: Zu viel RAM schadet auch — je größer der Heap, desto länger dauert eine einzelne große Garbage Collection. Ziel ist also, „genau richtig“ für dein Pack und deine Spielerzahl zuzuweisen. Für Vanilla und Paper mit 5–10 Spielern reichen meist 4–6 GB; ein mittleres Modpack verlangt 8–12 GB, schwere Packs mehr. Die genaue Berechnung nach Version, Loader und Spielerzahl haben wir in unserem Guide ausgearbeitet, wie viel RAM ein Minecraft-Server braucht.

Der Schlüssel zur Zähmung der GC sind die richtigen JVM-Flags. Aikar's Flags stimmen den G1GC-Collector so ab, dass die Pausen kurz und vorhersehbar bleiben (Ziel ist MaxGCPauseMillis=200) und Speicher vorausschauend freigegeben wird statt im Moment der Spitzenlast. Ein kostenloser Stabilitätsschub — füge die Flags einfach deiner Startzeile hinzu.

Ursache 2. Ein schwacher CPU-Kern

Merk dir das Wichtigste über Minecraft: Es ist fast vollständig single-threaded. Die gesamte zentrale Spiellogik — Mobs, Redstone, Generierung, Block-Ticks — läuft in einem einzigen Thread. Dem Server sind „viele Kerne“ also egal, für ihn zählen Geschwindigkeit und Stärke eines Kerns. Ein Achtkerner mit schwachen Kernen verliert gegen einen Vierkerner mit hohem Takt.

Deshalb kann ein Server mit Unmengen freiem RAM laggen: Ihn bremst nicht der Speicher, sondern die Grenze eines einzelnen Kerns. Die MSPT steigen, weil der Kern einen Tick physisch nicht in 50 ms verarbeiten kann. Besonders hart trifft das billiges VPS-Hosting, wo alte Serverprozessoren mit niedrigem Takt verbaut sind — und obendrein unter einem Dutzend Kunden aufgeteilt werden.

So erkennst du, dass die CPU limitiert

In /spark health oder im Profiler-Bericht liegt die Last eines Threads nahe 100 %, die MSPT sind hoch, und trotzdem ist RAM frei. Wenn mehr Speicher nicht hilft, ist fast sicher ein schwacher Kern schuld.

Ursache 3. Schwere Plugins und Mods

Jedes Plugin und jede Mod führt Code im selben Hauptthread aus. Ein einziges schlecht geschriebenes Plugin (besonders mit häufigen Regionsprüfungen, Inventar-Scans oder synchronen Datenbankabfragen) kann die TPS ganz allein in den Keller ziehen. Mods sind gefährlicher als Plugins: Ein schweres Technik-Modpack fügt Tausende neuer Entities, Maschinen und Welt-Ticks hinzu.

Auch hier hilft spark: Im Bericht erscheinen Plugins und Mods mit Namen und ihrem Anteil an der Tick-Zeit. Das Vorgehen ist einfach:

  1. Erstelle ein Profil und finde im Aufrufbaum den Namen des Plugins oder der Mod, die Ressourcen frisst.
  2. Deaktiviere es, starte neu und vergleiche die MSPT.
  3. Wenn es spürbar besser wurde, such einen Ersatz, aktualisiere auf eine neue Version oder stell die Intervalle seiner Aufgaben ein.

Bei Modpacks sind Hardware und Speicher besonders wichtig — warum, erklären wir in unserem Überblick zum Hosting für Modpacks. Und es spielt keine Rolle, ob du Forge oder Fabric nutzt: Für beide Loader gibt es Optimierungs-Mods, und sie bringen einen enormen Gewinn (mehr dazu unten).

Ursache 4. Mobs, Farmen und Redstone

Entities sind der klassische TPS-Killer. Jeder Mob, jedes Item auf dem Boden, jeder Rahmen und jede Lore tickt in jedem Spieltick. Wenn sich auf einem Server Hunderte Mobs, riesige Mob-Farmen und Dutzende aktive Trichter ansammeln, kommt der Hauptthread schlicht nicht hinterher.

  • Trichter-Lag. Trichter gehören zu den teuersten Block-Ticks. Sortieranlagen mit Hunderten Trichtern verbrennen MSPT. Halte die Zahl aktiver Trichter klein und nutze Filter und Wasserströme statt langer Ketten.
  • Mob-Farmen. Riesige Farmen mit Tausenden geladenen Mobs verursachen häufig Spitzen. Begrenze die Höhe und töte die Mobs per Timer.
  • Redstone-Schaltungen. Taktgeber und große automatische Anlagen ticken ununterbrochen. Ein vergessener Taktgeber in einer Ecke der Karte kann monatelang still die TPS fressen.
  • Angehäufte Items. Fallengelassene Items, die niemand aufhebt, sammeln sich zu Tausenden an. Richte eine automatische Bereinigung ein (merge-radius, Item-Limits).

Auf Paper/Purpur gibt es in spigot.yml und paper-world-defaults.yml fein einstellbare Limits: mob-spawn-range, Mob-Limits pro Chunk, Entity-Ticking. Senke sie, und die MSPT durch Mobs gehen spürbar zurück.

Ursache 5. Chunk-Generierung und die Festplatte

Wenn ein Spieler in unerforschtes Land aufbricht, generiert der Server neue Chunks in Echtzeit — eine schwere Operation für CPU und Festplatte. Und jedes Speichern der Welt schreibt Daten auf den Datenträger. Nutzt der Hoster langsame HDDs, werden Lesen und Schreiben von Chunks zum Flaschenhals: Du bekommst Lag-Spitzen, wenn sich Spieler bewegen und während des Auto-Saves.

Auf NVMe-Laufwerken (besonders Gen4 mit Lesegeschwindigkeiten um 7 GB/s) verschwindet dieses Problem praktisch: Chunks laden sofort, und das Speichern der Welt bemerkst du gar nicht. Fallen die Lags genau mit dem Erkunden neuer Gebiete oder mit dem Auto-Save zusammen, schau dir die Festplatte des Hosters genauer an.

Generiere deine Chunks vor

Generiere die Welt im benötigten Radius vorab mit einem Plugin (Chunky und ähnliche). Dann laufen die Spieler über fertige Chunks, und der Server muss sie nicht unter Last in Echtzeit erzeugen. Ein riesiger Unterschied bei Bewegungsspitzen.

Ursache 6. Zu hohe view-distance und simulation-distance

Zwei Einstellungen in server.properties vervielfachen die Last direkt:

view-distance=10          # wie viele Chunks ein Spieler sieht
simulation-distance=10    # in wie vielen Chunks die Logik tickt

simulation-distance ist besonders teuer: Je höher sie ist, desto größer der Radius, in dem Mobs, Redstone und Farmen um jeden Spieler ticken. Sie von 10 auf 6–8 zu senken, bringt auf einem vollen Server oft einen spürbaren TPS-Gewinn bei kaum Einbußen im Gameplay. view-distance beeinflusst Netzwerk und Generierung — auch sie solltest du in einem vernünftigen Bereich von 8–10 halten. Eine vollständige Übersicht aller Einstellungen findest du in unserem Artikel zur Konfiguration von server.properties.

So behebst du es: eine Checkliste

Fassen wir zusammen. Wir gehen vom Einfachsten und Günstigsten zum Aufwendigeren:

  1. Setz Aikar's Flags ein. Der schnellste kostenlose Gewinn gegen GC-Spitzen — kopier die fertige Flag-Zeile in deinen Start.
  2. Wechsle zu Paper oder Purpur. Wenn du noch auf Vanilla oder Spigot bist, bringt der Wechsel Optimierungen für Entities, Redstone und Trichter plus Dutzende Limit-Einstellungen. Einen Vergleich findest du in unserem Guide Paper vs. Purpur vs. Vanilla.
  3. Installiere Optimierungs-Mods. Auf Fabric Lithium (Weltlogik); auf modernem Forge/NeoForge gibt es Portierungen und Entsprechungen. Sie schreiben die Engpässe neu, ohne das Gameplay zu ändern.
  4. Erstelle ein spark-Profil und entferne den konkreten Ressourcenfresser — ein Plugin, eine Mod oder eine Farm.
  5. Begrenze Mobs und Farmen: Limits in den Configs, automatische Item-Bereinigung, eine Prüfung deiner Redstone-Schaltungen.
  6. Senke simulation-distance auf 6–8 und generiere die Welt vorab.

Wann der Hoster schuld ist und nicht du

Manchmal hast du alles richtig gemacht — Plugins optimiert, Flags gesetzt, Farmen und view-distance reduziert — und die MSPT bleiben trotzdem hoch. Dann liegt es an der Hardware des Hosters. Drei klassische Anzeichen für schlechtes Hosting:

ProblemWoran du es merkst
Überbuchter RAMDir wurden 8 GB „verkauft“, physisch teilen sie sich aber mehrere Kunden. Unter Last wird dir Speicher weggenommen — ständige GC und Freezes.
Schwache / virtuelle CPUAlte Serverprozessoren mit niedrigem Takt, aufgeteilt auf ein Dutzend VPS. Ein Kern kommt nicht hinterher — hohe MSPT bei freiem RAM.
HDD statt NVMeSpitzen beim Laden von Chunks und beim Auto-Save, langsamer Serverstart, Trägheit bei großen Welten.

Genau an diesen Stellen spart billiges Hosting, und am Ende sitzt du die halbe Nacht über spark-Berichten und verstehst nicht, warum dein Minecraft-Server trotz perfekter Configs laggt.

Elysium-Hardware für Minecraft gebaut

Wir haben unsere Infrastruktur gezielt auf die Single-Thread-Natur von Minecraft ausgerichtet: AMD Ryzen 9 mit Boost bis 5,6 GHz (ein starker Einzelkern ist das, was für die TPS wirklich zählt), DDR5-Speicher und NVMe Gen4 mit Lesegeschwindigkeiten um 7 GB/s (Chunks und das Speichern der Welt bremsen den Tick nicht). Für Modpacks und volle Server ist das der Tarif Nexus (8 GB) und höher — stell einen Server zusammen oder vergleiche die Tarife. Du hast schon einen Server bei einem anderen Hoster? Ab dem Tarif Vector ziehen wir deine Welt, Plugins und Configs kostenlos um — Details auf der Seite zum Umzug.

Und denk daran: Lag ist fast immer ein lösbares Problem. Fang mit /mspt und spark an, finde den Schuldigen anhand der Zahlen statt nach Gefühl — und dein Server läuft wieder mit ehrlichen 20 TPS. Wenn du gerade erst anfängst, sieh dir den großen Guide an, wie du einen Minecraft-Server erstellst: Er erklärt alles von Grund auf, inklusive eines sauberen Starts ohne spätere Lags.