Ein FiveM-Server, der bei voller Spielerzahl ruckelt, frustriert alle auf dem Server. Die gute Nachricht: Die meisten Performance-Probleme lassen sich systematisch eingrenzen und beheben — ohne raten zu müssen. Dieser Leitfaden zeigt dir die wichtigsten Stellschrauben: OneSync, aktuelle Artefakte, den Resource-Monitor, txAdmin und die typischen Lag-Ursachen. Er richtet sich an Einsteiger, die ihren Server selbst in den Griff bekommen wollen.
Zuerst verstehen: CPU-Singlethread ist der Flaschenhals
FiveM verteilt die Server-Last nicht gleichmäßig auf alle CPU-Kerne. Der Kern der Server-Logik läuft im Wesentlichen auf einem Thread. Das heißt konkret: Ein Prozessor mit vielen Kernen, aber schwacher Einzelkern-Leistung bringt dir bei FiveM weniger als einer mit hoher Single-Core-Performance. Wenn du Tarife vergleichst, achte also nicht nur auf die Anzahl der vCores, sondern auf die Leistung pro Kern.
Praktische Folge: Wenn dein Server bei 40 Spielern einbricht, liegt das selten an zu wenig RAM, sondern fast immer an einem überlasteten Haupt-Thread — meist verursacht durch ineffiziente Ressourcen (Scripts). Genau die spürst du mit dem Resource-Monitor auf.
OneSync: Pflicht für alles über 32 Spieler
OneSync ist die serverseitige Synchronisation, die höhere Spielerzahlen überhaupt erst möglich macht. Ohne OneSync bist du auf das klassische Limit beschränkt. Mit OneSync sind je nach Modus deutlich mehr Slots drin, und die Server-Seite übernimmt mehr Kontrolle über die Spielwelt (State Awareness), was Cheating erschwert und die Synchronisation stabiler macht.
Aktiviert wird OneSync über eine Zeile in deiner server.cfg:
set onesync on— aktiviert OneSync inklusive der großen Spielerzahl.sv_maxclients 48— setzt das Slot-Limit passend zu deinem Tarif.
Wichtig: OneSync verschiebt Last auf den Server. Schlecht programmierte Ressourcen fallen damit stärker ins Gewicht, nicht weniger. OneSync ersetzt also kein sauberes Ressourcen-Management — es macht es eher noch wichtiger.
Artefakte aktuell halten
Die FiveM-Server-Artefakte (die FXServer-Builds) werden laufend weiterentwickelt. Veraltete Artefakte sind eine häufige, oft übersehene Lag- und Stabilitätsquelle: Bugfixes, Performance-Verbesserungen und Sicherheits-Patches stecken in neueren Builds. Ein Server, der monatelang auf einem alten Build läuft, verschenkt Stabilität.
Halte dich an die als stabil markierten recommended-Builds, nicht zwingend an den allerneuesten Stand — die neuesten latest-Builds können experimentell sein. Vorgehen in Kurzform:
- Server sauber stoppen.
- Backup der aktuellen Server-Dateien ziehen (per SFTP), damit du zurück kannst.
- Neue Artefakte einspielen und Server starten.
- Nach dem Update Konsole und Resource-Monitor prüfen, ob alles läuft.
Plane Updates außerhalb der Stoßzeiten ein und teste danach kurz, ob deine Ressourcen weiterhin sauber starten.
Der Resource-Monitor: Lag-Verursacher finden
Das wichtigste Werkzeug gegen Ruckler ist der eingebaute Resource-Monitor. Er zeigt dir pro Ressource, wie viel Zeit sie pro Tick verbraucht. So findest du die Scripts, die deinen Haupt-Thread blockieren.
Aufrufen kannst du ihn in der Server-Konsole bzw. über die F8-Konsole im Client mit:
resmon— öffnet die Live-Übersicht aller Ressourcen.resmon 1— detailliertere Ansicht mit mehr Messwerten.
Faustregel: Werte um 0.01 ms sind unkritisch. Eine Ressource, die dauerhaft mehrere Millisekunden zieht, ist ein klarer Kandidat. Achte besonders auf Scripts, die im Leerlauf Last erzeugen — gut geschriebene Ressourcen verbrauchen nur etwas, wenn sie wirklich arbeiten. Wenn du den Verursacher identifiziert hast, aktualisiere ihn, ersetze ihn durch eine schlankere Alternative oder deaktiviere ihn testweise und beobachte den Unterschied.
Häufige Lag-Ursachen auf einen Blick
- Zu viele oder schlecht optimierte Scripts: Jede zusätzliche Ressource kostet Tick-Zeit. Weniger, dafür saubere Ressourcen sind besser als ein voll gestopfter Server.
- Endlosschleifen ohne Wartezeit: Scripts mit zu kurzen oder fehlenden
Wait-Intervallen fressen CPU. Das ist oft die Ursache für einen einzelnen Ausreißer im Resource-Monitor. - Veraltete Artefakte: siehe oben.
- Datenbank-Engpass: Viele Frameworks schreiben ständig in eine MySQL-Datenbank. Langsame oder unsaubere Abfragen bremsen den ganzen Server.
- Zu hohe Slot-Zahl für die Hardware: Mehr Spieler bedeuten mehr Synchronisation. Skaliere die Slots zur tatsächlichen Leistung.
txAdmin: Verwaltung, Monitoring und Restarts
txAdmin ist das Web-Verwaltungspanel, das bei FiveM standardmäßig mitkommt. Es ist weit mehr als nur ein Startknopf: Du siehst Live-Performance-Graphen, die Spielerliste, das Server-Log und kannst Ressourcen verwalten, ohne ständig in der Konsole zu hängen.
Zwei Funktionen, die der Performance direkt helfen:
- Geplante Neustarts: Ein automatischer Restart, z. B. nachts, räumt Speicher auf und glättet Probleme, die sich über Stunden ansammeln. Plane ihn außerhalb der aktiven Spielzeiten.
- Server-interne Backups: txAdmin kann Sicherungen deiner Server-Daten anlegen. Das ist deine eigene Backup-Strategie — kombiniere es mit regelmäßigen SFTP-Downloads, idealerweise auf einen separaten Speicher.
Behalte die txAdmin-Performance-Anzeige im Auge: Bricht die Server-Tickrate bei steigender Spielerzahl ein, hast du einen direkten Hinweis, dass eine Ressource oder die Slot-Zahl über dem liegt, was deine Hardware sauber trägt.
Mit Nytrix umsetzen
Wenn du einen FiveM-Server suchst, der diese Optimierungen mitmacht, bekommst du bei Nytrix einen slot-basierten FiveM-Gameserver ab 2,40 EUR. DDoS-Schutz (Voxility-Filterung) und eine eigene IP sind bei allen Tarifen inklusive, der Standort der Gameserver ist Eygelshoven (NL). Über die Live-Web-Konsole startest du den Server, spielst Artefakte und Ressourcen per SFTP selbst ein und nutzt den Diagnosemodus zur Fehlersuche. Up- und Downgrade sowie Neu-Installieren gehen jederzeit über das Dashboard — praktisch, wenn du die Slot-Zahl an die tatsächliche Last anpassen willst.
Zur Einordnung beim Thema Sicherung: Es gibt keine automatischen Hoster-Backups für Gameserver. Deine Backups laufen spiel-intern über txAdmin und zusätzlich per SFTP-Download — optional auf den separaten FTP Storage (ab 2,99 EUR/TB), der sich gut als Backup-Ziel eignet. Frameworks mit Datenbank lassen sich an eine MySQL-Datenbank (0,50 EUR/mtl, MySQL 8.0 auf NVMe) auslagern. Abgerechnet wird per Prepaid: Guthaben aufladen, Tarif buchen, keine Mindestlaufzeit und keine Vertragsbindung. Weitere Praxis-Anleitungen findest du im Nytrix-Blog.