How much vCPU and RAM does a server need?
By Datafex Engineering TeamPublished Updated 4 min read
There is no single answer to this question, but there is a single way to find it: measure which resource is actually limiting you first. The most common mistake when a server slows down is adding vCPUs, and for most workloads that changes nothing.
vCPU: core count, or per-core performance?
The critical distinction is whether your workload parallelises.
Some workloads spread work across multiple cores — a web server, a PHP-FPM pool, several game server processes. Adding cores genuinely helps there.
Other workloads do their main work on a single thread. Buying 16 cores instead of 4 produces no measurable gain; what decides is the clock speed and IPC of that one core. For this kind of work, the fastest core in our catalogue is on the Ryzen 9 7950X VDS plans (Zen 4, DDR5).
| Workload | What decides | Do more vCPUs help? |
|---|---|---|
| FiveM / RedM (CitizenFX) | Single-core performance | No, nothing beyond 3-6 vCPU |
| Minecraft (Java, vanilla) | Single-core performance | Partly, tails off past 4-6 |
| MySQL / MariaDB | Memory + storage latency | Up to a point |
| Nginx + PHP-FPM | Concurrent request count | Yes |
| alt:V | Networking and streaming threads | Yes |
| Multiple CS 1.6 servers | Process count | Yes, 3-4 servers per core |
| Video encoding | Total cores | Yes, close to linear |
The practical rule: on single-threaded work, upgrade the processor family; on parallel work, add cores.
RAM: how the calculation works
A RAM estimate has three components:
- Baseline — the operating system and always-on services. 0.5-1 GB on Linux, 2-3 GB on Windows Server.
- The application's fixed cost — the resource list and assets on a game server, code and caches in a web application.
- The per-unit variable — the part that grows with connected players, concurrent requests or open sessions.
Example: for a 64-slot FiveM server, a Linux baseline of 1 GB, 6 GB for the resource list and streamed assets, 50 MB per player × 64 = 3.2 GB, and 2 GB for MySQL gives roughly 12 GB. That runs comfortably on a 16 GB plan and sits at the limit on 8 GB during peak hours.
One caveat: build the calculation on the number of players actually connected at peak hour, not on the slot count. The per-game, per-player load table and the full worked example are in a separate guide: game server slot planning
Do not rely on swap. Swap turns the moment memory runs out into a slowdown rather than a crash; it is insurance, not a solution. A game server paging to disk is already unusable for its players.
Storage: latency matters more than capacity
Most people look at GB when choosing storage, yet for most workloads the problem is latency rather than capacity. The gap between NVMe and SATA SSD is a matter of percentages on sequential reads but multiples on small random reads — and database queries are precisely small random reads. Where that gap comes from and how to measure it: what is an NVMe SSD?
Things to keep in mind:
- Growth is permanent. World saves, MySQL binlogs, backups and log files do not shrink back.
- Backups take space. If you keep backups on the same machine, size storage at 1.5x.
- Shrinking storage is not supported. Because it risks data loss, most providers (Datafex included) only grow storage. Picking comfortable headroom up front is easier than migrating later; you can see what the initial storage choice does to the monthly total in the server configurator.
What should drive an upgrade decision?
Measure these before growing the hardware:
- CPU: in
top, is a single core pinned at 100%, or is load spread across cores? If it is the former, adding cores is wasted. - Memory: what is
availableinfree -mat peak? If it drops below 500 MB, RAM really is short. - Storage:
%utilandawaitiniostat -x 1. Ifawaitclimbs into milliseconds, storage is the bottleneck. - Application: is the slow query log on? Often the hardware is fine and a single unindexed query is holding up the whole server.
An upgrade made without measuring these four usually means spending the right money in the wrong place.
Once you have measured them and the limit really is the hardware, the next question is what the resources you measured cost on each side today: cost comparison with current prices
Where to go next
We have written separately about how resource sharing affects performance: What is a VDS and how does it differ from a VPS?
If you are building a game server, we have compiled RAM, vCPU and storage guidance per game by player count: game server plans. For general use, you can pick each resource and see the monthly total instantly: virtual server plans.