Ob bei einem Gameserver eher CPU oder RAM knapp wird, erkennst du nicht an einer einzelnen Auslastungszahl. Vergleiche CPU, Speicher, Protokolle und Spielverhalten während derselben belasteten Phase. Wiederkehrende Speicherfehler sprechen für ein Speicherproblem; verzögerte Serverberechnungen bei ausreichendem RAM deuten eher auf CPU- oder Engine-Last. Das sind Anhaltspunkte, keine Garantie: Spiel-Engine, Server-Software und Messmethode unterscheiden sich.
Zuerst denselben Zeitraum betrachten
Notiere, wann die Verzögerung auftritt und ob mehrere Mitspielende gleichzeitig betroffen sind. Tritt sie nur bei einer Person auf oder zeigt sich vor allem durch hohen Ping und Verbindungsabbrüche, kann auch der Client oder Netzwerkweg beteiligt sein. Bei Verzögerungen für alle sammle CPU- und Speicherwerte sowie Konsolenmeldungen aus genau diesem Zeitfenster.
Wenn dein Server oder Panel Messkurven anbietet, vergleiche eine ruhige Phase mit einer ähnlichen Spielsituation, in der das Problem wieder auftritt. Notiere dazu Spielerzahl und Aktivität, etwa Erkundung, grosse Kämpfe oder das Laden umfangreicher Spielbereiche. Anzeigen können den einzelnen Prozess, einen Container oder das ganze System abbilden. Vergleiche deshalb nur Werte mit derselben Bedeutung und Einheit; eine allgemeingültige Prozentgrenze für alle Gameserver gibt es nicht.
Hinweise auf ein CPU-Limit
Ein CPU-Engpass wird wahrscheinlicher, wenn Verzögerungen mit hoher CPU-Last zusammenfallen oder die Spiel-Engine lange Berechnungszeiten meldet, während der Speicher noch unter seiner Grenze liegt. Eine niedrige Gesamt-CPU-Anzeige schliesst einen Engpass nicht aus: Bei Paper kommt ein grosser Teil der Arbeit aus einer einzelnen Tick-Schleife, sodass ein Thread ausgelastet sein kann, obwohl die Anzeige über alle Kerne hinweg moderat wirkt. Diese Besonderheit gilt für Paper und lässt sich nicht pauschal auf jede Spiel-Engine übertragen. Siehe PaperMC: Low CPU usage.
Bei Paper ab Version 1.21 kannst du das integrierte spark nutzen. Starte während des Problems in der Serverkonsole spark profiler start --timeout 300. In der Konsole gibst du den Befehl ohne führenden Schrägstrich ein; im Spielchat braucht er den Schrägstrich und passende Berechtigungen. Paper empfiehlt Profiling während die Störung tatsächlich auftritt. Der Bericht hilft zu erkennen, welche Methoden Zeit beanspruchen; spark dokumentiert den Befehl und die gemessenen Werte in der Command-Usage-Anleitung und Paper erklärt den Einsatz im Profiling-Guide.
Ein spark-Bericht kann einen Link erzeugen. Teile ihn nur mit Personen, denen du die darin enthaltenen Serverdaten zeigen möchtest.
Hinweise auf Speicherdruck
Ein Speicherengpass wird wahrscheinlicher, wenn die Prozess- oder Container-Anzeige während der Störung wiederholt die zugewiesene Grenze erreicht, der Server wegen Speichermangels beendet wird oder das Protokoll einen OutOfMemoryError meldet. Lies bei Java den vollständigen Zusatztext: Java heap space bezeichnet ein Problem beim Bereitstellen von Heap-Speicher; Metaspace und Hinweise auf nativen Speicher beschreiben andere Bereiche. Oracles Java-Troubleshooting-Guide erläutert, dass selbst Java heap space mehrere Ursachen haben kann – zum Beispiel eine zu kleine Heap-Grenze oder längerfristig gehaltene Objekte.
Auch GC overhead limit exceeded ist ein klares Signal für starke Garbage-Collection-Last: Die JVM verbringt sehr viel Zeit mit dem Aufräumen und gewinnt dabei nur wenig Speicher zurück. Lies die genaue Meldung und prüfe Heap- und Prozesswerte, bevor du -Xmx erhöhst.
Hohe Java-RAM-Nutzung allein beweist dagegen keinen Engpass. Die Java-Anwendung kann mehr Prozess-RAM als den mit -Xmx begrenzten Heap nutzen. PaperMC weist ausserdem darauf hin, dass belegter Speicher nach einer Garbage Collection oft nicht an das Betriebssystem zurückgeht. Bei Paper mit spark kannst du mit spark health show --memory zusätzliche JVM-Speicherwerte ausgeben. Vergleiche den Heap mit der Prozess- oder Container-Anzeige, statt nur auf eine davon zu schauen.
Falls dein JVM-Bericht used, committed und max für den Heap getrennt ausweist, lies die Werte einzeln: used zeigt den aktuell genutzten, committed den der JVM zugesicherten Speicher und max die definierte Obergrenze. Sie entsprechen nicht automatisch dem Prozess- oder Container-RAM; Oracle beschreibt die Begriffe in der Java-SE-25-Referenz zu MemoryUsage.
Wenn beide Werte hoch sind oder keiner passt
CPU- und Speicherdruck können gleichzeitig auftreten. Häufige Garbage-Collection-Arbeit kann etwa mit verzögerten Ticks zusammenfallen; ein grösserer Heap löst aber nicht automatisch eine CPU-Last aus Plugins, Mods oder der Spielwelt. Ändere deshalb nicht zugleich Heap, Software und Spielregeln. Sichere die Ausgangswerte, ändere eine Variable und vergleiche denselben Spielablauf erneut. Wenn du Erweiterungen oder Weltdateien anfasst, erstelle vorher ein Backup.
Bleiben CPU und Speicher unauffällig, obwohl Spielende Verzögerungen melden, untersuche Netzwerk, Datenträger oder Client als getrennte mögliche Ursachen. Der Minecraft-Lag-Guide behandelt weitere Serverprüfungen; der Artikel zum Planen von Minecraft-Server-RAM erklärt, wie du Speicherwerte für eine konkrete Welt einordnest.
Quellen
- PaperMC: Basic troubleshooting – RAM-Anzeigen, Heap und Single-Thread-Hinweis für Paper.
- PaperMC: Profiling – spark-Verfügbarkeit und Profiling während eines aktiven Problems.
- spark: Command Usage – Profiling- und JVM-Health-Befehle.
- Oracle: Troubleshooting Guide (Java SE 25) – Einordnung von Java-Speicherfehlern.
- Oracle:
MemoryUsage(Java SE 25) – Bedeutung der JVM-Kennzahlenused,committedundmax.