Wie behebe ich FiveM-Serverlag und die 'server thread hitch warning'?

Siehst du in der Konsole deines FiveM-Servers immer wieder server thread hitch warning: timer interval of XXX milliseconds, während sich Spieler über Lag oder Rubberbanding beschweren? Dann kommt der Server-Thread nicht mehr hinterher. Hier erfährst du, was die Meldung bedeutet, wie du mit resmon die schweren Resources aufspürst und wie du die vier größten Übeltäter gezielt behebst.

Was bedeutet 'server thread hitch warning'?

FXServer führt den Kern deines Servers — Spielersynchronisation, Events und den Großteil deiner Script-Logik — auf einem einzigen Hauptthread (svMain) aus. Dieser Thread arbeitet in kurzen Ticks. Dauert ein Tick deutlich länger als geplant, etwa 250 Millisekunden statt weniger, loggt der Server eine Hitch Warning mit der gemessenen Zeit. Während so eines Aussetzers steht alles gleichzeitig still: Spieler springen auf ihre vorherige Position zurück, Fahrzeuge frieren ein und Events kommen zu spät an.

Weil all diese Arbeit auf einem Thread passiert, ist die Single-Thread-Leistung der CPU entscheidend — nicht die Anzahl der Kerne und nicht die Menge an RAM. In der Praxis ist die Ursache aber meist keine langsame Maschine, sondern eine einzelne Resource, die den Thread blockiert. Dieser Artikel bezieht sich speziell auf FiveM; Lag auf einem Minecraft-Server funktioniert ganz anders und hat einen eigenen Optimierungsartikel.

Schritt 1: Spüre schwere Resources mit resmon auf

1. Verbinde dich mit deinem Server, öffne die Client-Konsole mit F8 und tippe resmon 1. Das Resource-Monitor-Fenster erscheint.
2. Achte auf die Spalte CPU msec: Sie zeigt, wie viele Millisekunden eine Resource pro Frame kostet. Lass das Fenster eine Weile offen, während du spielst.
3. Interpretiere die Werte: Eine saubere Resource bleibt unter 0,10 ms. Liegt ein Script dauerhaft über 1,00 ms, ist es schwer; Ausreißer von mehreren Millisekunden zeigen direkt auf den Übeltäter.
4. Resmon misst deinen Client. Den Server-Thread selbst profilst du über den Tab Console im MC-Node-Panel: Tippe profiler record 500, warte, bis die Aufnahme fertig ist, und tippe profiler view. Über den angezeigten Link siehst du pro Resource, welche Funktionen den Tick aufhalten; in txAdmin zeigen die Dashboard-Graphen die Tick-Zeiten ebenfalls.
5. Kein klarer Ausreißer? Stoppe verdächtige Resources vorübergehend mit stop resourcename in der Konsole und prüfe, ob die Warnings verschwinden. Indem du jedes Mal die Hälfte ausschließt, findest du den Verursacher auch ohne Profiler.

Schritt 2: Behebe die vier größten Übeltäter

1. Scripts mit Tight Loops — Eine Schleife wie while true do ... Citizen.Wait(0) end läuft jeden Tick erneut, auch wenn es nichts zu tun gibt. Erhöhe die Wartezeit zum Beispiel auf Citizen.Wait(1000) für Checks, die nicht ständig laufen müssen, und lass Code auf Events reagieren, statt zu pollen. Bleibt ein verschlüsseltes (Escrow) oder nicht mehr gepflegtes Script schwer, ist der Wechsel zu einer gepflegten Alternative fast immer die bessere Wahl.
2. Zu große Fahrzeugtexturen (YTD) — Addon-Autos mit 4K- oder 8K-Texturen fressen Streaming-Speicher: Spieler bekommen Ruckler, Texture Loss und lange Downloadzeiten. Verkleinere Texturen auf maximal 2K, entferne ungenutzte Livery-Varianten und sei kritisch bei Packs mit hunderten Megabyte. Wie du Fahrzeuge schlank und sauber installierst, liest du im Addon-Auto-Guide.
3. Blockierende Datenbank-Queries — Eine synchrone Query legt den Server-Thread lahm, bis die Datenbank antwortet. Nutze einen aktuellen Async-Wrapper wie oxmysql, ersetze veraltete mysql-async-Scripts und lege Indizes auf häufig genutzte Tabellen wie users und owned_vehicles an. Speichere Spielerdaten gebündelt statt bei jeder kleinen Änderung. Die Zugangsdaten deiner Datenbank findest du unter dem Tab Databases.
4. Zu viele Entities — Jedes gespawnte Auto, jedes Prop und jeder Ped muss in jedem Tick synchronisiert werden; tausende zurückgelassene Fahrzeuge machen das spürbar teurer. Lass ein Cleanup-Script laufen, das leere Fahrzeuge nach ein paar Minuten entfernt, begrenze Spawner-Scripts und achte auf Maps, die extrem viele Props platzieren — siehe auch den MLO- und Custom-Map-Guide.

Wann ist wirklich die Hardware der Flaschenhals?

Die klassische Falle ist, alles auf den Host zu schieben, während ein einziges Script 90 % der Frametime frisst — der Profiler zeigt das gnadenlos. Aber auch das Gegenteil gibt es. Ist resmon sauber, verteilt der Profiler die Tick-Zeit gleichmäßig auf viele kleine Aufgaben ohne klaren Ausreißer, und tauchen die Warnings erst bei hohen Spielerzahlen auf? Dann stößt du an das Single-Thread-Limit der CPU. Mehr RAM oder zusätzliche Slots lösen das nicht; dann hilft nur noch Hardware mit höherer Taktrate pro Kern.

Häufige Meldungen und Situationen

• Hitch Warnings beim Start — Bei einem (Neu-)Start lädt der Server alle Resources gleichzeitig; ein paar Warnings sind dann normal. Nur Meldungen, die während des Spielens immer wiederkommen, sind ein Problem.
• sync thread hitch warning oder network thread hitch warning — Diese Varianten deuten meist auf die Synchronisationsschicht hin: zu viele Entities oder Spieler. Räume Entities auf (Schritt 2, Punkt 4) und prüfe, ob OneSync Infinity aktiviert ist.
• Hitches zu festen Zeitpunkten — Kehrt der Ruckler exakt alle fünf oder zehn Minuten zurück, ist fast immer eine periodische Aufgabe schuld: eine Speicherschleife, die alle Spieler gleichzeitig wegschreibt, oder ein Backup zu Stoßzeiten. Verteile das Speichern in deinen Scripts und plane Backups über die Tabs Schedules und Backups in die Nachtstunden.
• Rubberbanding ohne Hitch Warnings in der Konsole — Dann liegt das Problem wahrscheinlich auf der Client-Seite oder am Netzwerk des Spielers. Bitte betroffene Spieler, ihre eigenen FPS und resmon zu prüfen; zu schwere YTDs sind hier oft die Ursache.
• Die Warnings bleiben nach allen Schritten — Erstelle direkt nach einem Ruckler eine Profiler-Aufnahme mit profiler record 500 und bewahre die Ausgabe auf; damit lässt sich die Ursache viel schneller eingrenzen.

Brauchst du Hilfe?

Mit resmon und dem Profiler findest du fast jeden Verursacher von Serverlag innerhalb weniger Minuten. Kommst du nicht weiter, eröffne ein Ticket über unsere Supportseite und nenne die genaue Meldung aus dem Tab Console sowie deine resmon- oder Profiler-Ergebnisse.