Running a FiveM server that feels smooth and responsive is one of the biggest challenges server owners face. Between poorly optimized scripts, database bottlenecks, and misconfigured network settings, there are dozens of reasons your players might be experiencing rubber-banding, desync, or outright crashes. In this guide, we break down exactly how to optimize FiveM server performance and eliminate FiveM server lag at its source.
Understanding FiveM Server Performance
Before you start tweaking settings, you need to understand what "performance" actually means in the context of a FiveM server. Two metrics matter most: tick rate and server frame time (measured in milliseconds per frame).
FiveM servers target a tick rate of roughly 64 ticks per second, which translates to about 15.6ms per frame. When your server frame time exceeds this threshold, the tick rate drops, and players start to feel lag. You can monitor frame time in real time using the resmon command in your server console. If your server consistently sits above 16ms, you have a performance problem that needs attention.
The CPU Bottleneck: Single-Threaded Reality
The single most misunderstood aspect of FiveM server hosting is that FiveM is primarily single-threaded. This means throwing more CPU cores at the problem does not help. What matters is single-core clock speed and IPC (instructions per cycle). A 4-core processor running at 4.8GHz with high IPC will outperform a 16-core server chip running at 2.4GHz every single time.
This is why consumer-grade processors like the AMD Ryzen 7 7800X3D or Intel i9-13900K often make better FiveM hosts than traditional Xeon server CPUs. When choosing hardware, prioritize single-thread benchmark scores above all else.
Script Optimization: The Biggest Performance Win
Scripts are the number one cause of FiveM server lag. Every resource running on your server consumes frame time, and poorly written scripts can eat up several milliseconds each. Here is how to get your scripts under control.
Remove Unused Resources
Start by auditing every resource in your server.cfg. If a resource is not actively used by players, stop it. Many server owners accumulate dozens of scripts they tested once and forgot about. Each one takes up frame time even if no player is interacting with it.
Use the Built-In Profiler
Run the profiler record 100 command in your server console to capture a performance snapshot. After it finishes, use profiler view to see exactly which resources are consuming the most time per tick. Target anything above 1ms per frame for optimization or replacement.
Common Script Anti-Patterns to Fix
- Tick loops without waits: Any
Citizen.CreateThreadloop that does not include aCitizen.Wait()call will consume an entire CPU core and destroy performance. Always include a wait, even if it is justWait(0). - Excessive native calls: Calls like
GetEntityCoordsorGetPlayerPedinside tight loops add up fast. Cache values and reduce call frequency where possible. - Global player loops every tick: Iterating over all players every frame is expensive. Use event-driven patterns or increase the wait interval to 500-1000ms for non-critical checks.
- Unoptimized ESX/QBCore callbacks: Heavy server callbacks that query the database on every call create cascading delays. Cache results when data does not change frequently.
Database Optimization
Your database is the second most common source of performance issues. Every time a script queries the database, it blocks execution until the result returns. Slow queries compound quickly with 64+ players online.
MySQL Tuning Essentials
- Set
innodb_buffer_pool_sizeto 50-70% of your available RAM dedicated to MySQL. - Enable
innodb_flush_log_at_trx_commit = 2for significantly faster writes with minimal durability risk. - Use
innodb_log_file_size = 256Mor higher for write-heavy workloads. - Add indexes to columns you frequently query, especially player identifiers like
citizenidoridentifier.
oxmysql vs mysql-async
If you are still using mysql-async, switch to oxmysql. It uses a connection pool model, supports prepared statements, and handles concurrent queries far more efficiently. The migration is straightforward and the performance improvement is measurable, especially on servers with 50+ players.
Use oxmysql's built-in query profiling by setting mysql_debug to true in your server config. This logs slow queries so you can identify and index the worst offenders.
Network Optimization
Network configuration directly impacts how smooth the experience feels for players, especially those connecting from further distances.
Bandwidth and Player Limits
Each connected player uses approximately 50-100 Kbps of bandwidth under normal conditions, spiking higher during asset streaming or heavy entity synchronization. For a 128-player server, plan for at least 100 Mbps of dedicated bandwidth with headroom for bursts.
Set your sv_maxclients realistically. Running 128 slots when your hardware can only handle 64 players smoothly guarantees a poor experience for everyone. Scale player counts to what your server frame time can sustain below 16ms.
Connection Convars
sv_lan false- Ensure your server is properly configured for WAN connections.sv_forceIndirectListing true- Can improve connection reliability for players behind strict NATs.- Set
sv_endpointPrivacy trueif you want to hide your server's IP from player clients.
OneSync Configuration
OneSync is the backbone of modern FiveM server performance, handling entity synchronization across all connected players. Proper configuration is essential to optimize FiveM server performance at scale.
Enable OneSync in your server.cfg with set onesync on. For most servers, the default OneSync mode is sufficient. If you are running a high-population server (100+ players), consider using onesync_population to let the server handle population management instead of individual clients.
OneSync Infinity supports up to 2048 players but requires scripts specifically written for high player counts. Most publicly available scripts are not optimized for this and will cause severe lag beyond 128 players.
Key OneSync-related convars to tune:
set onesync_distanceCullVehicles true- Reduces vehicle entity overhead by culling distant vehicles.set onesync_workaround763185 true- Fixes a known entity creation issue.set sv_entityLockdown strict- Prevents clients from creating unauthorized entities, which both improves security and reduces server-side entity processing.
Asset Streaming Optimization
Custom vehicles, MLOs (Map Load Objects), clothing, and other streamed assets are a major contributor to both client-side and server-side lag.
Reducing MLO and Asset Sizes
- Compress textures: Many custom MLOs ship with uncompressed or oversized textures. Use tools like OpenIV to recompress YTD files to DXT5 format, targeting 1024x1024 or lower for most textures.
- Remove LOD overkill: Some MLOs include unnecessarily detailed LOD models. Simplify or remove excessive LOD levels to reduce streaming load.
- Limit custom vehicles: Each custom vehicle add-on increases the streaming pool. Keep your vehicle count under 200 if possible and ensure all vehicles use properly optimized geometry and textures.
- Use server-side texture streaming: Configure
set adhesive_cdnKeyand use a CDN orfileserver_addto offload asset delivery from your game server process.
Large MLO interiors (casinos, malls, custom maps) with unoptimized textures can consume 500MB+ of streaming memory per client. Always test new MLOs on a staging server before deploying to production.
Monitoring Tools: Know Your Numbers
You cannot fix what you cannot measure. Use these tools to continuously monitor your server and catch problems early.
resmon Command
Type resmon 1 in your client F8 console while connected to your server as an admin. This overlays a real-time resource monitor showing the millisecond cost of every running resource. Sort by server frame time and target anything consistently above 1ms.
txAdmin Performance Tab
If you are using txAdmin (and you should be), the performance tab provides historical charts of server frame time, player count, and tick rate. Use this data to correlate lag spikes with specific events, such as player count thresholds, scheduled jobs, or specific times of day.
External Monitoring
For production servers, consider setting up Prometheus + Grafana dashboards using FiveM's built-in metrics endpoint. This lets you track performance trends over days and weeks, making it easier to spot gradual degradation from newly added scripts or growing database tables.
When to Upgrade Your Hardware
If you have optimized your scripts, tuned your database, configured OneSync properly, and your server frame time still exceeds 16ms during peak hours, it is time to look at your hardware. Signs that you have outgrown your current setup include:
- Server frame time consistently above 12-14ms even with moderate player counts.
- Database queries taking longer than 50ms despite proper indexing.
- Asset streaming causing hitches for players despite CDN offloading.
- You are running on a shared VPS where noisy neighbors affect your single-thread performance.
For serious FiveM communities, a dedicated server or high-end VDS with a high-clock-speed CPU makes a significant difference. At GoodLeaf, our VDS plans run on AMD Ryzen processors with strong single-thread performance, which is exactly what FiveM demands. Paired with NVMe storage for fast database access, the right hardware eliminates the bottlenecks that no amount of software tuning can fix.
When evaluating hosting for a FiveM server, always ask about the CPU model and clock speed. Avoid providers that only list core counts without specifying the processor. Single-thread performance is everything for FiveM.
Putting It All Together
Optimizing FiveM server performance is not a one-time task. It is an ongoing process of monitoring, identifying bottlenecks, and making targeted improvements. Here is a prioritized action plan:
- Measure first: Run
resmonand the profiler to establish your baseline frame time and identify the worst offenders. - Cut the fat: Remove unused resources and replace poorly optimized scripts with lighter alternatives.
- Tune your database: Switch to oxmysql, add proper indexes, and configure MySQL buffer settings.
- Configure OneSync: Enable entity culling and strict lockdown to reduce synchronization overhead.
- Optimize assets: Compress textures, limit custom vehicles, and use a CDN for streaming.
- Monitor continuously: Set up txAdmin performance tracking and review it weekly.
- Upgrade hardware when needed: Move to a high-performance VDS with a fast single-threaded CPU if software optimizations hit their ceiling.
Follow these steps systematically, and you will see a measurable reduction in FiveM server lag and a noticeably smoother experience for your players.
Frequently Asked Questions
How much RAM does a FiveM server need?+
A baseline FiveM server needs around 4GB of RAM, but most roleplay servers with custom scripts, MLOs, and databases should have 8-16GB. RAM is rarely the bottleneck; CPU single-thread performance and script optimization have a far greater impact on reducing FiveM server lag.
Why does my FiveM server lag with only 30 players?+
Player count alone does not cause lag. The most common culprit is poorly optimized scripts running expensive operations every tick. Use the resmon command to identify which resources are consuming the most frame time. A well-optimized server can handle 100+ players, while a poorly optimized one will lag with 20.
Is a dedicated server better than a VPS for FiveM?+
It depends on the VPS type. A standard shared VPS on an older Xeon processor will underperform compared to a dedicated server. However, a high-end VDS running on AMD Ryzen hardware with dedicated CPU cores can match or exceed dedicated server performance for FiveM, often at a lower price point. The key factor is guaranteed single-thread CPU performance, not whether the server is virtual or bare metal.