Fixing FiveM server lag: from OneSync to heavy scripts

Nothing wrecks a roleplay evening as quickly as a stuttering server: cars teleporting, an inventory that takes seconds to open, NPCs freezing on the sidewalk. The good news is that FiveM lag almost always has an identifiable cause. The bad news: that cause is rarely where you look first.

One distinction up front will save you hours of searching. Low FPS for players is a client problem: heavy maps, too many props, mediocre PCs. Rubberbanding, slow events and actions that only come through after seconds are usually server-side — and that's the part you as an admin actually control.

Measure first, guess later

The biggest mistake you can make is disabling resources right away because someone on Discord shouted that script X is heavy. Start with the numbers. txAdmin, FiveM's standard panel, shows a performance graph on the dashboard: how long your server needs per tick. If that graph stays nicely in the green, the server process is healthy and the problem is more likely with clients or the network. If you see spikes that coincide with your players' complaints, you know for sure you need to look server-side.

Also check the server console. FiveM itself reports when a tick takes too long with so-called hitch warnings, including the number of milliseconds the tick took. One stray hitch during startup is normal; a console full of hitch warnings during peak hours is a concrete lead.

Finally, note when the lag occurs. Only in the evening with lots of players online? Then something scales badly with player counts — think events firing per player or database queries piling up. Also noticeable with five people? Then one resource or query is structurally slow, and that's actually good news: it's easier to find.

OneSync: more players, more server work

OneSync moves the synchronization of entities — vehicles, NPCs, objects — from the clients to the server. That lets you go well beyond the classic slot limit and gives the server control over what each player sees: entities far out of range are culled and no longer synchronized.

That's largely a win, but be aware of the trade. All that synchronization work lands on your server's processor and grows with every extra player. A server that runs smoothly with thirty people can hit its ceiling with sixty without a single script having changed. On top of that, some ancient scripts from the pre-OneSync era behave strangely: they assume every entity exists for everyone, and with culling that's no longer true.

So disabling OneSync is not a serious anti-lag trick, whatever some forums claim. What does hold: the higher your slot count, the more single-core performance and well-written scripts start to matter.

Tracking down heavy scripts

By far most server-side lag comes from badly written resources. Here's how to find the culprits:

• resmon: open the resmon command in the F8 console. You'll see per resource how many milliseconds it costs per frame. Anything that scores structurally high while nothing is happening deserves a critical look.
• The profiler: for the server side, FiveM has a built-in profiler. With profiler record 500 you record five hundred ticks and with profiler view you see per resource and per function where the time gets stuck.
• The halving method: not in the mood for profilers? On a test server, disable half of your resources and see if the lag disappears. Repeat with the suspect half. In a few rounds you'll have caught the culprit.

With resmon, do watch what you're measuring: on the client you mainly see what a resource costs your own game, while the profiler on the server shows what the server process has to endure. A script can look innocent client-side and still clog the tick server-side — or vice versa. So measure on both sides before drawing conclusions.

Classic offenders: loops that run every frame without a wait, scripts that continuously iterate over all players or entities, and events sent to all clients on every minor action. Popular paid scripts aren't immune to this either — judge by measurements, not by reputation or price.

Important to be honest about: sometimes the fix isn't fun. A beloved script that demonstrably wrecks your tick rate has to be updated, replaced or rewritten. There is no server variable that compensates for badly written code.

The database as a silent brake

Almost every roleplay server hangs off a MySQL database via a connector like oxmysql. If opening inventories or saving players is slow while your performance graph stays green, look here.

• Slow queries: enable MySQL's slow query log and see which queries stand out. Often an index is simply missing on a column that's constantly searched, such as the player identifier.
• Too many queries: some scripts save the complete character or the entire inventory on every minor change. With ten players you won't notice; with fifty you will.
• Distance: if your database runs in a different location than your game server, you pay network latency on every query. Keep them close together, preferably on the same machine or network, and on fast storage like NVMe.
• Blocking scripts: some older scripts wait blocking on a database response before continuing. Every slow query then immediately stalls part of your server. Newer connectors and scripts handle this more gracefully, so updating outdated resources pays off twice.

Hardware: single-core speed wins

The heavy synchronization and script work of a FiveM server largely runs on one thread. A processor with a high clock speed and strong single-core performance therefore does more for your tick rate than a pile of extra cores. Memory mainly determines how many resources and players you can hold, and fast storage helps with your database and loading times.

At MC-Node, FiveM servers run on our own hardware with NVMe storage and DDoS protection in the Previder data center in Hengelo — meaning low ping for Dutch and Belgian players. All plans can be cancelled monthly, so you can start small and only scale up when your measurements call for it:

Fair is fair: a heavier plan doesn't fix badly written scripts. But if a cleaned-up server is still structurally hitting its ceiling, upgrading is the logical step. Compare the options in the MC-Node FiveM plans and move up a size — thanks to monthly cancellation, you're not tied to anything.

Your action plan in short

1. Confirm with the txAdmin graph and hitch warnings that the problem is really server-side.
2. Run resmon and the profiler during peak hours, not at three in the morning on an empty server.
3. Tackle the heaviest resource: update, replace or rewrite.
4. Check the database for slow queries and missing indexes.
5. Scripts and database in order and still hitting the wall? Only then is hardware the answer.

Work in this order and you'll fix most lag within an evening — and you'll know for sure that any upgrade isn't an expensive band-aid, but a targeted choice.