FiveM-Server-Lag beheben: von OneSync bis schwere Scripts

Nichts zerstört einen Roleplay-Abend so schnell wie ein stotternder Server: Autos, die teleportieren, ein Inventar, das Sekunden zum Öffnen braucht, NPCs, die auf dem Gehweg einfrieren. Die gute Nachricht: FiveM-Lag hat fast immer eine klar benennbare Ursache. Die schlechte: Diese Ursache sitzt selten dort, wo du zuerst suchst.

Eine Unterscheidung vorab spart dir Stunden Sucharbeit. Niedrige FPS bei Spielern sind ein Client-Problem: schwere Maps, zu viele Props, mittelmäßige PCs. Rubberbanding, träge Events und Aktionen, die erst nach Sekunden ankommen, sind meist server-seitig — und das ist der Teil, den du als Admin selbst in der Hand hast.

Erst messen, dann raten

Der größte Fehler ist, sofort Resources abzuschalten, weil jemand im Discord gerufen hat, Script X sei schwer. Fang bei den Zahlen an. txAdmin, das Standard-Panel von FiveM, zeigt auf dem Dashboard einen Performance-Graphen: wie lange dein Server pro Tick braucht. Bleibt dieser Graph sauber im Grünen, ist der Serverprozess gesund und das Problem liegt eher bei Clients oder Netzwerk. Siehst du Spitzen, die mit den Beschwerden deiner Spieler zusammenfallen, weißt du sicher, dass du server-seitig suchen musst.

Schau außerdem in die Serverkonsole. FiveM meldet selbst, wenn ein Tick zu lange dauert — mit sogenannten Hitch Warnings, inklusive der Millisekunden, die der Tick gekostet hat. Ein einzelner Hitch beim Start ist normal; eine Konsole voller Hitch Warnings zur Stoßzeit ist eine konkrete Spur.

Notiere zuletzt, wánn der Lag auftritt. Nur abends mit vielen Spielern online? Dann skaliert etwas schlecht mit den Spielerzahlen — etwa Events, die pro Spieler feuern, oder Datenbank-Queries, die sich stapeln. Auch mit fünf Leuten spürbar? Dann ist eine Resource oder Query strukturell langsam — und das ist eigentlich eine gute Nachricht: Die findest du schneller.

OneSync: mehr Spieler, mehr Serverarbeit

OneSync verlagert das Synchronisieren von Entitäten — Fahrzeuge, NPCs, Objekte — von den Clients auf den Server. Dadurch kommst du deutlich über das klassische Slot-Limit hinaus und der Server bekommt die Kontrolle darüber, was jeder Spieler sieht: Entitäten weit außer Reichweite werden geculled und nicht mehr synchronisiert.

Das ist größtenteils ein Gewinn, aber sei dir bewusst, was du dafür eintauschst. All diese Synchronisationsarbeit landet auf dem Prozessor deines Servers und wächst mit jedem zusätzlichen Spieler. Ein Server, der mit dreißig Leuten flüssig läuft, kann mit sechzig an seine Decke stoßen, ohne dass sich ein einziges Script geändert hat. Außerdem verhalten sich manche uralten Scripts aus der Prä-OneSync-Zeit seltsam: Sie gehen davon aus, dass jede Entität für alle existiert, und das stimmt mit Culling nicht mehr.

OneSync abzuschalten ist also kein ernsthafter Anti-Lag-Trick, egal was manche Foren behaupten. Es gilt aber: Je höher deine Slot-Zahl, desto stärker fallen Single-Core-Leistung und sauber geschriebene Scripts ins Gewicht.

Schwere Scripts aufspüren

Der weitaus meiste server-seitige Lag kommt aus schlecht geschriebenen Resources. So findest du die Übeltäter:

• resmon: öffne in der F8-Konsole den Befehl resmon. Du siehst pro Resource, wie viele Millisekunden sie pro Frame kostet. Alles, was dauerhaft hoch liegt, obwohl nichts passiert, verdient einen kritischen Blick.
• Der Profiler: für die Serverseite hat FiveM einen eingebauten Profiler. Mit profiler record 500 nimmst du fünfhundert Ticks auf und mit profiler view siehst du pro Resource und pro Funktion, wo die Zeit hängen bleibt.
• Die Halbierungsmethode: keine Lust auf Profiler? Schalte auf einem Testserver die Hälfte deiner Resources ab und schau, ob der Lag verschwindet. Wiederhole das mit der verdächtigen Hälfte. In ein paar Runden hast du den Täter.

Achte bei resmon aber darauf, was du misst: Auf dem Client siehst du vor allem, was eine Resource dein eigenes Spiel kostet, während der Profiler auf dem Server zeigt, was der Serverprozess abbekommt. Ein Script kann client-seitig harmlos wirken und server-seitig trotzdem den Tick verstopfen — oder umgekehrt. Miss also auf beiden Seiten, bevor du Schlüsse ziehst.

Klassische Sünder: Loops, die jeden Frame ohne Wartezeit laufen, Scripts, die ständig über álle Spieler oder Entitäten iterieren, und Events, die bei jeder kleinen Aktion an alle Clients geschickt werden. Auch populäre bezahlte Scripts sind dagegen nicht immun — urteile nach Messungen, nicht nach Ruf oder Preis.

Wichtig ist Ehrlichkeit: Manchmal ist die Lösung nicht schön. Ein beliebtes Script, das nachweislich deine Tickrate ruiniert, musst du updaten, ersetzen oder umschreiben lassen. Es gibt keine Servervariable, die schlecht geschriebenen Code kompensiert.

Die Datenbank als stille Bremse

Fast jeder Roleplay-Server hängt an einer MySQL-Datenbank über einen Connector wie oxmysql. Öffnen sich Inventare langsam oder dauert das Speichern von Spielern lange, während dein Performance-Graph grün bleibt, such hier.

• Langsame Queries: aktiviere das Slow Query Log von MySQL und schau, welche Queries herausstechen. Oft fehlt schlicht ein Index auf einer Spalte, in der ständig gesucht wird, etwa dem Spieler-Identifier.
• Zu viele Queries: manche Scripts speichern bei jeder kleinen Änderung den kompletten Charakter oder das ganze Inventar. Mit zehn Spielern merkst du davon nichts, mit fünfzig schon.
• Distanz: läuft deine Datenbank an einem anderen Standort als dein Gameserver, zahlst du bei jeder Query Netzwerklatenz. Halte sie nah beieinander, am besten auf derselben Maschine oder im selben Netzwerk, und auf schnellem Speicher wie NVMe.
• Wartende Scripts: manche älteren Scripts warten blockierend auf eine Antwort der Datenbank, bevor sie weitermachen. Jede langsame Query legt dann sofort einen Teil deines Servers lahm. Neuere Connectoren und Scripts machen das sauberer — veraltete Resources zu aktualisieren lohnt sich also doppelt.

Hardware: Single-Core-Geschwindigkeit gewinnt

Die schwere Synchronisations- und Script-Arbeit eines FiveM-Servers läuft größtenteils auf einem einzigen Thread. Ein Prozessor mit hohem Takt und starker Single-Core-Leistung bringt deiner Tickrate deshalb mehr als ein Berg zusätzlicher Kerne. Arbeitsspeicher bestimmt vor allem, wie viele Resources und Spieler du unterbringst, und schneller Speicher hilft bei Datenbank und Ladezeiten.

Bei MC-Node laufen FiveM-Server auf eigener Hardware mit NVMe-Speicher und DDoS-Schutz im Previder-Rechenzentrum in Hengelo — niedriger Ping für Spieler aus den Niederlanden, Belgien und Westdeutschland. Alle Pakete sind monatlich kündbar, sodass du klein anfangen und erst hochskalieren kannst, wenn deine Messungen es verlangen:

Ehrlich ist ehrlich: Ein größeres Paket repariert keine schlecht geschriebenen Scripts. Aber stößt du mit einem aufgeräumten Server trotzdem dauerhaft an deine Decke, ist ein Upgrade der logische Schritt. Vergleiche die Optionen bei den FiveM-Paketen von MC-Node und geh eine Nummer höher — dank der monatlichen Kündbarkeit bindest du dich an nichts.

Dein Fahrplan in Kürze

1. Bestätige mit dem txAdmin-Graphen und Hitch Warnings, dass das Problem wirklich server-seitig liegt.
2. Lass resmon und den Profiler zur Stoßzeit laufen, nicht um drei Uhr nachts auf einem leeren Server.
3. Pack die schwerste Resource an: updaten, ersetzen oder umschreiben.
4. Prüfe die Datenbank auf langsame Queries und fehlende Indexe.
5. Sind Scripts und Datenbank in Ordnung und du läufst trotzdem an die Grenze? Dann erst ist Hardware die Antwort.

Wer in dieser Reihenfolge arbeitet, löst den meisten Lag an einem Abend — und weiß außerdem sicher, dass ein eventuelles Upgrade kein teures Pflaster ist, sondern eine gezielte Entscheidung.