Choosing a Virtual Server: How Much CPU and RAM Do You Need?

You've brought your server up, the site responds on it, but every few hours TTFB jumps from 200 milliseconds to two seconds and then recovers on its own. Or the opposite: you pay a few hundred thousand tomans a month for resources you never use even half of. The real question isn't "how much CPU and RAM is good"; the question is which resource runs out first and how to figure that out before buying.

First figure out which resource is the bottleneck, then choose a virtual server

Most people do it backwards. They first buy a plan with 4 vCPU and 8 GB of RAM, then discover the problem was MySQL queries that could have been solved with a proper index. Estimating resources without data is a guess. With data, it's simple arithmetic.

Before anything else, run this on your current server and keep it for a week:

vmstat 5 720 >> /var/log/vmstat.log
sar -u -r -d 5 1

If the si and so columns in vmstat show non-zero numbers, it means the system is swapping and RAM is short. A wa (iowait) column above 10 percent means the disk is the bottleneck, not the CPU. These two lines clarify half of your purchasing decision.

Signs of shortage for each resource, separately

• CPU shortage: load average stays consistently above the number of vCPUs, but iowait is low. The site slows down under concurrent load and immediately recovers after traffic drops.
• RAM shortage: The OOM killer leaves traces in dmesg. PHP-FPM or MySQL restart for no reason. You see this in the log as Out of memory: Killed process.
• Disk shortage: High iowait, but idle CPU. If you're on an HDD, this happens much sooner than you think.
• Bandwidth shortage: None of the above, but file downloads are slow. Here the problem is elsewhere.

A point that's rarely mentioned: on virtual servers, vCPU is a quota, not a dedicated core. If you buy a 4 vCPU plan but the hypervisor is busy, you might get the equivalent of only 2 cores during peak hours. That's why you should check steal time in top; if it's above 5 percent, the problem isn't your code.

Estimate from real traffic, not from guesswork

A rule-of-thumb formula that works in practice: count concurrent requests, not daily visits. If your site gets 50,000 visits a day and each visit generates an average of 8 requests, that's 400,000 requests per day. Spread over 24 hours, that's about 4.6 requests per second. But site traffic isn't uniform; take the peak factor as 5 to 10 times. That means you need to be ready for 25 to 50 requests per second.

Now it depends on how much CPU each request consumes. An uncached WordPress page with a few heavy plugins might use 150 to 300 milliseconds of CPU. A simple API endpoint uses under 10 milliseconds. With 50 requests per second and 200 milliseconds of CPU each, you need 10 full cores. You reduce this number dramatically with caching.

Here's where people make a mistake: they get too little RAM for the database and then run with the default innodb_buffer_pool_size of 128 megabytes. The result is that every query goes to disk and iowait jumps up, while the CPU is nearly idle. They see the symptoms, say "the server is weak," and go buy more CPU. A wrong diagnosis wastes money.

When vertical scaling works and when it doesn't

Up to a point, making the same server bigger is the simplest path. A server with 8 cores and 32 GB of RAM handles the load without any change in architecture. Choose this as long as your traffic is below several times your current capacity.

But this path breaks in two places. First, when you hit the ceiling of the plans and can't go any higher. Second, when you want to reach more capacity without downtime; because changing plans usually requires a restart. If your site can't tolerate even two minutes of downtime, you should design for horizontal architecture from the start. I've explained the difference between these two approaches with numerical examples in Autoscaling; horizontal or vertical? A guide to choosing correctly.

A common trap: don't choose RAM based on instantaneous usage. Instantaneous usage during off-peak hours is half of peak usage. If you buy based on off-peak hours, you'll swap during peak and everything slows down. Always decide based on the 95th percentile of usage, not the average.

Don't underestimate the disk

On a virtual server, the disk type matters as much as its capacity. A 100 GB NVMe is faster than a 500 GB SATA for a database. If IOPS matters to you, ask before buying what type of disk it is and whether it has an IOPS quota or not. Some providers share IOPS among customers, and during busy hours the real number is much lower than what you saw in the ads.

For a real test, run this after setup:

fio --name=randread --ioengine=libaio --rw=randread \
  --bs=4k --numjobs=4 --size=1G --runtime=60 --group_reporting

The iops number in the output is what you bought in the contract. If it's far from what you expected, follow up in the first week.

Initial configuration after choosing a virtual server

After you've chosen your resources, do three things on the very first day. First, configure swap with vm.swappiness=10 so it's only used under real pressure. Second, set up monitoring before a problem appears; the practical guide is in Server monitoring: a practical guide to smart monitoring and alerting. Third, use separate storage for static files and backups so the server's main disk doesn't fill up.

If your site has image or file traffic, separate object storage from the start. This both keeps the server disk free and makes backups simpler. For static content, also put a content delivery network in front of the server; this can take up to half the CPU load off the server, because static requests never reach your server at all.

If your workload is truly variable and you don't want to pay for peak, instead of buying one big server, use infrastructure where you can scale resources up and down based on demand. Cloud infrastructure (IaaS) from ServerNet offers this same flexibility; but note that autoscaling without proper monitoring only increases costs.

Frequently asked questions

How many CPU cores and how much RAM does a typical WordPress site need?

For a site with moderate traffic and caching enabled, 2 CPU cores and 4 GB of RAM is a logical starting point. If you use page caching and object caching, this amount handles several times more traffic. RAM usually runs out before CPU, so if you have to pick one to increase, choose RAM.

How do I tell whether the problem is a RAM shortage or CPU?

If iowait is low but load average stays above the number of cores, it's a CPU problem. If swap is active or you see OOM killer messages in dmesg, it's a RAM problem. The si and so columns in vmstat output are the fastest way to diagnose.

Is vCPU equal to a physical core?

No. A vCPU is a processing quota from a physical core that is shared among several virtual machines. If the steal time value in top is above 5 percent, it means other machines are putting pressure on the same core and you're getting less than your quota. Check this number during peak hours, not off-peak.

When should I migrate from one big server to several small servers?

When you've hit the ceiling of available plans, or when you can't accept the downtime caused by changing plans. At that point, separating the database from the web server is the first step, and after that you can scale the web layer horizontally. Before this point, making the same server bigger is the simplest and least troublesome path.

Before buying the next plan, collect a week of data. If after that you're still not sure which resource is the bottleneck, the problem is probably in the code or configuration, not the server size.