Hoe los ik FiveM-serverlag en 'server thread hitch warning' op?

Zie je in de console van je FiveM-server steeds server thread hitch warning: timer interval of XXX milliseconds voorbijkomen en klagen spelers over lag of rubber banding? Dan loopt de server-thread achter. Hier lees je wat de melding betekent, hoe je met resmon de zware resources opspoort en hoe je de vier grootste boosdoeners gericht oplost.

Wat betekent 'server thread hitch warning'?

FXServer draait de kern van je server — spelersynchronisatie, events en het grootste deel van je scriptlogica — op één hoofdthread (svMain). Die thread werkt in korte ticks. Duurt één tick veel langer dan gepland, bijvoorbeeld 250 milliseconden in plaats van een paar, dan logt de server een hitch warning met de gemeten tijd. Tijdens zo'n hapering staat alles tegelijk stil: spelers schieten terug naar hun vorige positie, voertuigen bevriezen en events komen te laat aan.

Omdat al dit werk op één thread gebeurt, is de single-thread-snelheid van de CPU beslissend — niet het aantal cores en niet de hoeveelheid RAM. Toch is de oorzaak in de praktijk meestal geen trage machine, maar één resource die de thread bezet houdt. Dit artikel gaat specifiek over FiveM; lag op een Minecraft-server werkt heel anders en heeft een eigen optimalisatie-artikel.

Stap 1: Spoor zware resources op met resmon

1. Verbind met je server, open de client-console met F8 en typ resmon 1. Het resource-monitorvenster verschijnt.
2. Kijk naar de kolom CPU msec: dit is hoeveel milliseconden een resource per frame kost. Laat het venster even openstaan terwijl je speelt.
3. Interpreteer de waarden: een nette resource blijft onder de 0,10 ms. Zit een script structureel boven de 1,00 ms, dan is het zwaar; uitschieters van meerdere milliseconden wijzen naar de boosdoener.
4. Resmon meet jouw client. De server-thread zelf profileer je via het tabblad Console in het MC-Node paneel: typ profiler record 500, wacht tot de opname klaar is en typ profiler view. Via de getoonde link zie je per resource welke functies de tick ophouden; in txAdmin tonen de dashboardgrafieken de tick-tijden ook.
5. Geen duidelijke uitschieter? Stop verdachte resources tijdelijk met stop resourcenaam in de console en kijk of de warnings verdwijnen. Door telkens de helft uit te sluiten vind je de veroorzaker ook zonder profiler.

Stap 2: Los de vier grootste boosdoeners op

1. Scripts met tight loops — Een lus als while true do ... Citizen.Wait(0) end draait elke tick opnieuw, ook als er niets te doen is. Verhoog de wachttijd naar bijvoorbeeld Citizen.Wait(1000) voor controles die niet continu hoeven, en laat code reageren op events in plaats van te pollen. Blijft een versleuteld (escrow) of niet meer onderhouden script zwaar, dan is vervangen door een onderhouden alternatief vrijwel altijd de betere keuze.
2. Te grote voertuigtextures (YTD) — Addon-auto's met 4K- of 8K-textures vreten streaminggeheugen: spelers krijgen haperingen, texture loss en lange downloadtijden. Verklein textures naar maximaal 2K, verwijder ongebruikte livery-varianten en wees kritisch op packs van honderden megabytes. Hoe je voertuigen licht en netjes installeert, lees je in de addon-auto-gids.
3. Blokkerende databasequeries — Een synchrone query legt de server-thread stil tot de database antwoordt. Gebruik een actuele async-wrapper zoals oxmysql, vervang verouderde mysql-async-scripts en zet indexen op veelgebruikte tabellen zoals users en owned_vehicles. Sla spelersdata gebundeld op in plaats van bij elke kleine wijziging. De inloggegevens van je database vind je onder het tabblad Databases.
4. Te veel entiteiten — Elke gespawnde auto, prop en ped moet elke tick gesynchroniseerd worden; duizenden achtergelaten voertuigen maken dat merkbaar duurder. Draai een cleanup-script dat lege voertuigen na een paar minuten opruimt, beperk spawner-scripts en let op maps die extreem veel props plaatsen — zie ook de MLO- en custom-map-gids.

Wanneer is de hardware wél de bottleneck?

De klassieke valkuil is alles op de host schuiven terwijl één script 90% van de frametime opeet — de profiler laat dat genadeloos zien. Maar het omgekeerde bestaat ook. Is resmon schoon, verdeelt de profiler de ticktijd netjes over veel kleine taken zonder duidelijke uitschieter, en verschijnen de warnings pas bij hoge spelersaantallen? Dan zit je tegen de single-thread-limiet van de CPU aan. Meer RAM of extra slots lossen dat niet op; alleen hardware met een hogere kloksnelheid per core helpt dan nog.

Veelvoorkomende meldingen en situaties

• Hitch warnings tijdens het opstarten — Bij een (her)start laadt de server alle resources tegelijk; een paar warnings zijn dan normaal. Alleen meldingen die tijdens het spelen terug blijven komen zijn een probleem.
• sync thread hitch warning of network thread hitch warning — Deze varianten wijzen meestal op de synchronisatielaag: te veel entiteiten of spelers. Ruim entiteiten op (stap 2, punt 4) en controleer of OneSync Infinity aanstaat.
• Hitches op vaste tijdstippen — Komt de hapering elke vijf of tien minuten exact terug, dan is vrijwel altijd een periodieke taak schuldig: een opslaglus die alle spelers tegelijk wegschrijft of een backup tijdens piekuren. Spreid het opslaan in je scripts en plan backups via de tabbladen Schedules en Backups in de nachtelijke uren.
• Rubber banding zonder hitch warnings in de console — Dan ligt het probleem waarschijnlijk aan de clientkant of bij het netwerk van de speler. Vraag getroffen spelers hun eigen fps en resmon te controleren; te zware YTD's zijn hier vaak de oorzaak.
• De warnings blijven na alle stappen — Maak direct na een hapering een profiler-opname met profiler record 500 en bewaar de uitvoer; daarmee is de oorzaak veel sneller te herleiden.

Hulp nodig?

Met resmon en de profiler vind je vrijwel elke veroorzaker van serverlag binnen een paar minuten. Kom je er niet uit, open dan een ticket via onze supportpagina en vermeld de exacte melding uit het tabblad Console plus je resmon- of profiler-bevindingen.