How to Optimize FiveM Server Performance in 2026

Running a smooth FiveM server is harder than it looks. Unlike most game servers that distribute work across multiple cores, FiveM runs its main server thread on a single CPU core. That means every script, every database query, and every streamed asset competes for the same slice of time. When that slice runs out, every player feels it at once.

This guide walks through the full optimization pipeline — from diagnosing resource bottlenecks with resmon to tuning your database layer, optimizing streamed textures, scheduling restarts, enabling OneSync, and choosing the right VPS hardware. Apply these steps and your server thread FPS will thank you.

Understanding the Single-Thread Bottleneck

FiveM's server runtime processes game logic on one core. This is the server thread, and its throughput is measured in server thread FPS — visible in the server console. A healthy value is typically 64 FPS or close to it. When heavy resources pile up, that number drops, and players experience rubber-banding, delayed interactions, and synchronized hitches.

Hitch warnings in the console are your first red flag. A hitch means the thread was blocked for an abnormally long time — usually caused by a synchronous database call, an infinite loop in a tick handler, or a single resource doing far too much work per frame.

Using resmon to Find Heavy Resources

The built-in Resource Monitor is your primary diagnostic tool. Open the server console or connect with admin rights and type the command below.

# In the FiveM server console or F8 in-game (admin only)
resmon

# Look for resources with high ms values in the CPU column
# Target: each resource < 0.5–1.0 ms at idle
# Server thread FPS drops when total CPU time across all resources climbs

Sort the resmon list by CPU time. Any resource consistently above 1 ms at idle deserves a closer look. Resources above 2–3 ms are almost always doing something inefficient — polling every frame, running unindexed database queries in a tick, or streaming oversized assets.

Optimizing Per-Frame and Tick Work

Avoid Unnecessary Citizen.Wait(0) Loops

A common mistake is placing a `Citizen.Wait(0)` inside a loop that runs checks which do not need to execute 60+ times per second. For example, checking whether a player is inside a zone every frame is wasteful. Instead, use a higher wait value such as 500 ms or 1000 ms for non-critical logic, and only drop to 0 ms when the player is actively interacting with something.

Event-Driven Instead of Polling

Replace polling loops with event-driven logic wherever possible. Instead of checking a player's job every second in a tick, fire a server event when the job changes and update local state only then. This pattern dramatically reduces per-frame CPU cost.

Optimizing Streamed Assets

Custom vehicle, ped, and prop streaming adds bandwidth and GPU memory pressure. The most impactful rule for textures is to always use power-of-two dimensions (128, 256, 512, 1024, 2048). Non-power-of-two textures cannot be block-compressed properly by DXT formats and will use more VRAM and load slower for every client.

• Keep vehicle diffuse textures at 2048×2048 or smaller; specular and normal maps can often be 1024×1024.
• Use DXT1 for opaque textures and DXT5 for textures with alpha — both compress well and load fast.
• Avoid streaming hundreds of unique props with large textures in a single resource; split them into logical packs.
• Use CodeWalker's RPF Explorer to inspect embedded texture sizes before you ship a map add-on.
• Reduce YTD (texture dictionary) size by sharing textures across props that use the same materials.

Database and oxmysql Query Optimization

Database queries that run inside tick handlers are the single most common cause of hitch warnings. oxmysql is the standard async MySQL wrapper for FiveM and handles queries non-blockingly — but if you fire dozens of unindexed queries per second across all players, you will still saturate your database connection pool.

• Add indexes to columns you filter on frequently (player identifiers, job columns, property IDs).
• Batch multiple row updates together instead of firing one query per player per second.
• Use oxmysql's `oxmysql:execute` for fire-and-forget writes, and `oxmysql:single` when you only need one row.
• Monitor slow query logs in MySQL/MariaDB to catch queries exceeding 100 ms.
• Consider caching frequently read, rarely changed data (job list, item definitions) in Lua tables at resource start instead of querying them each time.

Common Performance Culprits and Fixes

Enabling and Leveraging OneSync

OneSync changes FiveM's entity model from client-authoritative to server-authoritative. This is not just a player-count feature — it is a security and performance architecture choice. With OneSync enabled, the server controls entity creation and synchronization rather than individual clients, which closes a large class of cheat vectors and improves consistency across all players.

# server.cfg
set onesync on

# OneSync is required for > 32 player slots
# Also enables server-side entity management and modern API surface
# Verify it is active: check the server console startup banner for "OneSync: on"

Scheduled Restarts to Prevent Memory Bloat

Even well-optimized servers accumulate memory bloat over time. Lua tables grow, entity handles are not always cleaned up, and resource state compounds across sessions. txAdmin includes a built-in scheduled restart system — use it. A restart every 12 to 24 hours takes players offline for under a minute and keeps the server thread FPS stable throughout the day.

• Set restart times during low-activity hours (e.g., 04:00 and 16:00 server time).
• Configure a countdown announcement via txAdmin so players get a 5-minute warning.
• After each restart, check resmon values to confirm they reset to expected baselines.
• Monitor hitch warning frequency before and after scheduling restarts — improvement is usually immediate.

Right-Sizing Your VPS

Because FiveM's server thread is single-core, raw clock speed matters more than core count. A VPS with a 3.5 GHz single-core boost will outperform a 16-core machine clocking at 2.0 GHz for FiveM purposes. However, additional cores still benefit database servers, txAdmin, and any companion web services running on the same box.

Conclusion

Optimizing a FiveM server is a continuous process, not a one-time fix. Start with resmon to identify your worst offenders, eliminate polling loops, switch to event-driven logic, compress your assets to power-of-two dimensions, and let oxmysql handle all database I/O asynchronously. Layer in OneSync for server-authoritative networking and scheduled restarts to keep memory in check long-term.

If you want a performance-first foundation from day one, CRM Development builds all its server packs — from the 100K or Die street pack to the full Miami/NYC map setups — with these principles baked in. Every included resource is pre-audited for tick efficiency so you can focus on building your community, not hunting down lag spikes.