FiveM / GTA RP Server Dedicated Hardware Sizing: Slots, Script Load and OneSync Budgets

Size for scripts and entities, not for raw slot count

FiveM performance is dominated by the number of networked entities, the running server-script load and the OneSync mode — not by the headline player cap. Two servers both advertising “128 slots” can have wildly different hardware needs depending on how many props, peds and vehicles their frameworks stream. This guide builds a hardware budget from those three variables so you can match a machine, not a marketing number.

OneSync mode changes the cost profile

Classic OneSync streams entities per routed client; Infinity OneSync extends the streaming radius and entity count dramatically. The practical rule of thumb:

Infinity roughly doubles the entity budget per viewable range. If your framework spawns dense props and peds, plan for the higher row even at modest player counts — entity streaming, not player count, is what saturates the tick.

RAM: framework before players

FiveM itself is light; the resource bundle is not. Modern RP frameworks (ESX, QBCore, custom) with 150–400 resources routinely hold 4–8 GB resident before any player connects.

Add roughly 80–150 MB per active player for session and streaming state at scale. The node RAM column already includes headroom for MariaDB and a web/CAD backend, which many RP servers co-locate on the same box.

CPU: single-thread clock is the ceiling

The FiveM server tick and most script execution favour single-thread clock. A 128-slot server on a 3.2 GHz core will lag under a busy resource manifest where a 4.8 GHz core holds steady. After selecting for clock, add cores for:

• Database (MariaDB) — a dedicated 2–4 cores if co-located.
• Node or C# workers for large frameworks.
• Voice server (mumble / pma-voice) and reverse proxy.
• Anticheat and logging daemons.

A practical split is 4–6 high-clock cores for the game server plus 4–8 additional cores for supporting services on a 128-slot deployment. Disable power-saving C-states in BIOS so the boost clock does not sag between ticks.

Bandwidth and tick: the underrated constraints

FiveM is upload-heavy: each client streams entity updates and voice. Budget roughly 30–60 KB/s per player for gameplay plus voice traffic, and more toward the upper bound with heavy custom streaming. At 128 players that is 4–8 MB/s sustained, with bursts during traffic spikes.

uplink_Mbps = players * avg_KBps * 8 / 1000

A 128-player server at 50 KB/s needs about 52 Mbps sustained; leave 2x headroom for spikes, voice and any external database replication.

Storage: NVMe plus a database volume

FiveM resources load from disk at connect and during hot restarts. Use NVMe for the resource root and a separate NVMe or high-end SATA volume for MariaDB. Disable swap on the game volume — swapping during a tick storm turns lag into a stall. Keep the resource cache warm so restarts do not re-download assets under load.

Sizing checklist for a 128-slot RP server

1. Count resources; use it to fix the RAM row above.
2. Pick OneSync mode and set the entity budget accordingly.
3. Choose CPU by sustained clock, then add cores for DB and services.
4. Provision 2x headroom on uplink above measured peak.
5. Place resources and DB on separate NVMe volumes.

Provision from the resource count and OneSync mode first — slot count alone will mislead you. For node configurations that satisfy these budgets, review the hardware line-up at bestdedicatedwebhostingserver.com, and benchmark the chosen node against your own resource manifest before launch. A quick pre-launch load test with your real scripts at target player count will expose the true tick ceiling far earlier than guesswork.

Common sizing mistakes

Three failures recur on FiveM deployments. First, sizing by slot count and ignoring the resource manifest — a 64-slot server with 400 heavy resources can need more CPU than a 128-slot server with 80. Second, co-locating MariaDB on the same cores as the game server and then wondering why the tick spikes during saves; the database needs its own cores or its own machine. Third, running OneSync Infinity on a node chosen for clock speed alone without accounting for the entity-load multiplier, which pushes single-thread usage past the ceiling during dense roleplay scenes. Measure entity counts in a populated session, not in an empty city, and scale the CPU decision from there. Treat the database, voice and anticheat as first-class workloads rather than afterthoughts — their scheduling directly affects whether the game tick stays flat.

Putting the budget together

Work the numbers in order and the machine selects itself: count resources, read the RAM row, fix OneSync mode, then choose CPU by clock and add cores for the database and services. A typical well-tuned 128-slot RP server lands on a node with 32–64 GB RAM, a high-clock six-to-eight-core CPU plus a few spare cores, and dual NVMe volumes. Compare that against the configurations listed at dedicated hosting for game servers and pick the closest match with room to grow. Overprovisioning RAM is far cheaper than a mid-wipe crash caused by an OOM kill, so err generous on memory and exacting on clock.