How Much CPU and RAM Does Your VPS Need? A Practical Sizing Guide

"How big a server do I need?" has no single answer, and be wary of anyone who gives you one without asking what you run. A static brochure site and a busy online shop differ by orders of magnitude. The sensible approach is to estimate from the pieces of your stack, start with a reasonable size, and measure. Because VPS plans can usually be resized, a wrong first guess is cheap to fix when you watch the right numbers.

The four resources

• RAM is the resource most often exhausted. Web servers, PHP or application processes, databases and caches all hold memory.
• CPU matters for application code, image processing, encryption and compression. Many sites use far less CPU than they use memory.
• Disk holds the system, your site, uploads, databases, logs and backups. Space and speed both matter, and databases love fast storage.
• Network covers bandwidth and traffic limits. Check what your plan includes, since media-heavy sites can consume a lot.

Estimate RAM by adding up the parts

Write down each component and its approximate memory use, ideally measured from a similar setup. An illustrative example for a PHP site (the numbers are placeholders to show the method; measure your own):

Component	Example estimate
Operating system and basic services	300 MB
Web server (Nginx)	50 MB
PHP-FPM: 10 workers x 60 MB	600 MB
Database buffers and connections	500 MB
Cache (Redis)	128 MB
Headroom for spikes and file cache	at least 20 to 30%

The sum tells you the order of magnitude. The most important line to measure is the per-worker memory of your application, which differs hugely between a lean framework and a WordPress site with many plugins. Use ps or htop on a running copy to find real values, and never size from the application's idle state.

Estimate concurrency, not visitors

Monthly visitor numbers are a poor guide. What counts is how many requests are being processed at the same moment. If each page takes 200 ms of PHP time, one worker can finish roughly five requests per second; ten workers cover about fifty per second in theory. Static files, CDN caching and page caching reduce the number of requests that reach PHP at all, which can shrink the needed size dramatically. A cached WordPress site on a CDN often needs much less than the same site uncached.

CPU and disk

CPU: cores and what they are for

One or two cores is enough for many small sites. More cores help when requests are processed in parallel by several workers, or when background jobs run alongside the web server. Check the load average against your core count: sustained load above the number of cores means processes are waiting for CPU. Also learn whether your VPS offers dedicated or shared vCPU time; on shared plans, performance can vary when neighbours are busy, so ask the provider how CPU is allocated. Single-threaded tasks such as one slow database query do not get faster with more cores, only with better code or indexes.

Disk: add up growth and backups

Estimate the space as: operating system and software, plus site files, plus database size, plus logs, plus local backup copies, plus growth for the next year, plus 20% free space. Running a disk close to full causes failures that look unrelated. Keep backups on another system anyway, so local backup space is only a short-term buffer. Track disk usage monthly so growth does not surprise you.

Signs the size is wrong

Signs your server is too small

• Swap is in constant use and vmstat shows heavy swapping activity.
• The kernel's out-of-memory killer ends your database or PHP processes (visible in dmesg and the journal).
• Load stays above your core count for long periods, and response times rise with it.
• The PHP-FPM log warns that pm.max_children was reached while memory is already nearly full.

Signs it is too big

Memory shown as "available" stays above half for weeks, CPU idles below a small fraction, and disk is mostly empty. An oversized server wastes money, but being slightly generous is more forgiving than being short; a site that runs out of memory fails in dramatic ways. Review utilisation every few months and after major traffic or feature changes.

Scale up, out, or smarter

Before buying a bigger plan, look for cheaper fixes: enable page caching, put a CDN in front, add database indexes, tune OPcache, and remove heavy plugins. When you do outgrow one machine, the first split is usually moving the database to its own server. For steady, high-demand workloads or when you need all of a machine's resources, a dedicated server becomes worth considering.

Whatever size you start with, write down your baseline numbers on day one: memory in use, load average and disk used. Those figures make every later decision easier, and our knowledge base explains how to read them.

Choosing a size at Zebra Hosting

Start with the plan that covers your estimate with headroom, and grow when your measurements say so. Compare the VPS plans to find a fit.