Mit resmon, Profiler und einem Messprotokoll findest du die drei größten Bremsen, behebst sie gezielt und prüfst den Effekt. Hardware erst danach,...
Wer die FiveM Server Performance verbessern will, fängt nicht bei der Hardware an, sondern beim Messen: Erst resmon und der eingebaute Profiler zeigen, welche Ressource wirklich Zeit auf dem Tick fressen. Danach folgt die Kontrolle von server.cfg und OneSync, dann die Bereinigung von Scripts, Datenbankzugriffen und Streaming‑Assets. Ein Hosting‑Upgrade lohnt sich erst, wenn das Profiling eine echte Sättigung des Single‑Core‑Takts zeigt, nicht vorher.
Kurz gesagt:
- Die Serverleistung hängt vor allem vom Profiling und der Analyse der Ressourcenauslastung ab, nicht von der Hardware.
- Eine Optimierung der server.cfg und die Kontrolle von Scripts und Datenbanken sind oft wirksamer als ein schnelleres Hosting.
- Nur wenn Profiling zeigt, dass der Single‑Core deutlich ausgelastet ist, lohnt sich ein Hardware-Upgrade.
- Das Akkreditieren der Performance sollte durch Messungen in Idle‑ und Lastzuständen sowie durch Profiler‑Screenshots erfolgen.
- Ungenutzte oder fehlerhafte Scripts sowie große Streaming-Assets sind häufig die Hauptursachen für Performance‑Probleme.
Bevor du auch nur eine Zeile Code änderst, brauchst du Daten. resmon ist dafür euer erster Anlaufpunkt: Der Befehl resmon true in der Client‑Konsole zeigt pro Ressource Server‑ und Client‑Millisekunden, und genau hier fallen die üblichen Verdächtigen sofort auf, wie ein einschlägiger Forum‑Thread zur Serverleistung beschreibt. Dauerschleifen ohne Wartezeit, aufgeblähte Streaming‑Pakete und ungebremste Datenbankabfragen tauchen dort fast immer oben in der Liste auf.
So gehst du praktisch vor:
Sammle dabei Screenshots von resmon im Idle‑ und Lastzustand, den Profiler‑Spike und die txAdmin‑Grafik. Diese drei Artefakte sind dein Belegordner für jede spätere Entscheidung.
Profi-Tipp: Speichere die resmon‑Werte jeder Ressource in einer einfachen Tabelle. Nach jedem Content‑Update vergleichst du neu, denn ein frisch installiertes Fahrzeugpaket kann euren gesamten Fortschritt wieder zunichtemachen.
Viele Performance‑Probleme stecken nicht im Code, sondern in einer schlecht sortierten server.cfg. Die Ladereihenfolge entscheidet, ob Abhängigkeiten überhaupt zur richtigen Zeit verfügbar sind.
ox_lib, danach das Framework und erst am Ende alle übrigen Ressourcen.sv_maxclients etwa 10 bis 20 % über eurem tatsächlichen Spitzenwert, nicht willkürlich hoch, denn jeder freie Slot kostet potenziell Entity‑Budget.Doppelte ensure‑Einträge sind ein Klassiker: Sie kosten Ladezeit und verschleiern, welche Ressource tatsächlich aktiv ist.
Der häufigste Performance‑Killer heißt Citizen.Wait(0). Eine Schleife ohne echte Wartezeit läuft in jedem einzelnen Tick, egal ob gerade etwas passiert oder nicht, was auch praxisnahe Optimierungsguides als Hauptursache für Server‑Lag benennen. Dasselbe gilt für TriggerClientEvent an alle Clients (-1), wenn eigentlich nur eine Handvoll Spieler betroffen wäre.
Die Alternative ist meist simpel: adaptive Wartezeiten, die sich je nach Zustand verlängern, oder ein kompletter Umbau auf Event‑Handler statt Polling. Statt fünf Ressourcen, die denselben Spielerzustand alle paar hundert Millisekunden abfragen, reicht oft ein zentraler Statebag, der Änderungen einmal verteilt.
So läuft der Fixprozess in der Praxis:
Als Zielwert gilt: Sehr geringe Millisekunden pro Ressource im Idle‑Zustand sind unauffällig, alles deutlich darüber verdient eine genauere Untersuchung. Diese Faustregel lässt sich gut mit dem Ressourcen‑Budget aus dem FiveM Server Optimization Guide kombinieren, der eine Obergrenze von rund 150 Ressourcen als groben Richtwert nennt.
Profi-Tipp: Fixe nie mehr als drei Ressourcen zwischen zwei Messungen. Sonst weißt du am Ende nicht, welche Änderung tatsächlich etwas gebracht hat.
Datenbankzugriffe sind ein unterschätzter Bremsklotz, weil sie sich oft als scheinbar zufällige Verzögerung tarnen. Ein Spieler wartet zwei Sekunden, bis sein Inventar lädt, und niemand denkt zuerst an SQL.
oxmysql statt blockierender Sync‑Abfragen, denn asynchrone Zugriffe halten die Tick‑Schleife frei.identifier, citizenid oder plate an, das beschleunigt Lookups teils dramatisch.Lange asynchrone Wartezeiten oder blockierte Events sind fast immer ein Symptom fehlender Indizes, nicht eines zu schwachen Servers.
Clientseitige FPS‑Einbrüche haben selten mit dem Server selbst zu tun, sondern mit dem, was er an jeden Client streamt. MLOs, Fahrzeugpakete und Texturen summieren sich schnell zu einem Downloadvolumen, das beim Verbinden lange Ladezeiten und danach spürbare Ruckler erzeugt.
Ein Effekt wird oft unterschätzt: Streaming‑Optimierung bringt häufig einen größeren Fortschritt als ein teureres Hosting‑Paket, weil sie das eigentliche Problem, nämlich clientseitige Ruckler statt Server‑Lag, direkt angeht. FiveVault beschreibt genau diesen Zusammenhang zwischen Assetgröße und FPS‑Drops ausführlich. Lange Join‑Zeiten und wiederholte Reconnect‑Wellen sind meist das erste sichtbare Symptom eines überladenen Streaming‑Ordners.
Sobald Profiling und Scripts saubere Werte liefern, aber die CPU trotzdem am Limit hängt, wird Hardware relevant. Hier passiert der klassische Fehlkauf: Viele Anbieter bewerben mehr Kerne, obwohl FiveM den Tick größtenteils auf einem einzelnen Kern verarbeitet.
Die Entscheidungsregel bleibt einfach: Zeigt das Profiling eine dauerhafte Sättigung des einzelnen Kerns, ist ein Upgrade gerechtfertigt. Zeigt es das nicht, bringt neue Hardware wenig, wie auch der FiveM Server Optimization Guide betont.
Ein einmaliger Fix reicht nicht, weil sich Server‑Zustände über Stunden hinweg verändern, etwa durch Speicherlecks in einzelnen Ressourcen. Geplante Neustarts, etwa zwei‑ bis viermal täglich je nach Spielerzahl, sind eine pragmatische Zwischenlösung, bis die eigentliche Ursache gefunden ist.
Profi-Tipp: Notiere bei jedem Fix Datum, Ressource und Messwert davor/danach in einer gemeinsamen Tabelle. Nach ein paar Monaten erkennst du Muster, die euch sonst entgehen würden.
Die meisten Performance‑Probleme, die ich in Audits sehe, haben denselben Ursprung: ungeprüfte Scripts direkt aus Foren, fehlende Indizes und ein Streaming‑Ordner, der über Monate gewachsen ist, ohne dass jemand aufgeräumt hat. Die gute Nachricht dabei: Wer nach resmon konsequent die drei teuersten Ressourcen fixt, löst in der Regel den Großteil der Beschwerden, ganz ohne neue Hardware. Nexthosting wird dort sinnvoll, wo das Profiling tatsächlich Single‑Core‑Sättigung zeigt und zusätzlich verlässlicher DDoS‑Schutz gefragt ist, nicht als erster Reflex bei jedem Ruckler.
— Erik
Wenn euer Profiling zeigt, dass der Server tatsächlich an der Single‑Core‑Grenze hängt und nicht an einem schlampigen Script, lohnt sich der Blick auf die Infrastruktur selbst. Nexthosting bietet FiveM‑Hosting mit NVMe‑Speicher, DDoS‑Schutz und Plänen, die auf Single‑Core‑Leistung statt auf reine Kernanzahl ausgelegt sind, genau der Faktor, der bei FiveM den Ausschlag gibt. Statt bei jedem Ruckler direkt umzusteigen, gilt die Reihenfolge aus diesem Beitrag: erst resmon und Profiler, dann server.cfg und OneSync, erst danach die Hardware. Wer nach dem Audit tatsächlich mehr Leistung braucht, findet auf der FiveM-Hosting-Seite von Nexthosting die passenden Konfigurationen und kann direkt prüfen, welcher Plan zur eigenen Spielerzahl passt.
Für tiefere Messanleitungen lohnt sich der Forum‑Thread zur Serverleistung ebenso wie die offizielle FiveM-Seite für Referenzen zu Convars und Artefakten. Wer konkrete Checklisten sucht, findet beim FiveM Server Optimization Guide und bei FiveVault praxisnahe Tutorials zu Profiler und txAdmin.
FiveM belastet serverseitig fast ausschließlich die CPU, insbesondere den Single‑Core‑Takt, während die GPU‑Last hauptsächlich beim Client für Grafik und Streaming‑Assets anfällt.
Für die meisten mittelgroßen Roleplay‑Server reichen 32 GB RAM aus, solange Streaming‑Assets und Datenbankgröße im Rahmen bleiben; bei sehr großen Asset‑Paketen oder hoher Spielerzahl kann mehr nötig werden.
Miss zuerst mit resmon und dem Profiler, behebe die drei teuersten Ressourcen und prüfe danach server.cfg und OneSync, bevor du überhaupt über ein Hardware‑Upgrade nachdenkst.
Der RAM‑Bedarf richtet sich weniger nach der Slot‑Zahl als nach Umfang der Streaming‑Assets und Datenbankgröße; ein Server mit wenigen Spielern, aber großem Asset‑Ordner, kann trotzdem viel Speicher beanspruchen.