# How many vCPU, RAM and how much storage should you plan for an VPS?

[Corresponding web page](https://wisphost.com/blog/vps-resource-sizing/)

A setup is better chosen with a few measurements than with an estimate of visitor numbers. The right starting point depends on the work performed by your application and the resources that actually limit its responses.

By WispHost. Published on 2026-11-01.

Topic: Infrastructure.

## The short answer

Measure CPU, RAM and input/output separately under a representative load, then add a margin for peaks and scheduled tasks. Then compare these needs with the available configurations, without inferring a universal hosting capacity from the number of vCPU alone.

- A vCPU is a virtual compute resource, not a guarantee of application throughput.
- The available RAM and the signs of memory pressure matter more than an isolated percentage.
- NVMe capacity, disk throughput and I/O latency are distinct criteria.

## First describe a representative load

Note the operations actually used: page views, API calls, database queries, file conversion or scheduled processing. Identify peak periods and overlapping tasks. A daily average can mask a heavy import or a backup run at the wrong time.

To compare two setups, use the same data, versions and settings. Record response time and errors, then resource consumption during that test. A performance figure only makes sense if the scenario and the conditions that produced it are known.

## When do you need more vCPU?

KVM presents virtual processors to the guest system. Their number describes a setup, but does not by itself summarize the behavior of your application. A program that mainly executes one task at a time will not necessarily spread that work across all available vCPU.

Observe the processes consuming the CPU, the task queues and the moments when responses slow down. If the processor is waiting on storage or a remote service, adding compute may leave the cause intact. Start by identifying the resource that is blocking processing.

## Interpret memory along with its symptoms

The system may use part of the RAM for useful caches. Memory shown as used is therefore not, by itself, proof of a shortage. Examine available memory, processes, swap activity and out-of-memory events.

Under Linux, tools such as top, vmstat or your system's monitoring dashboards help observe these changes. Their availability depends on your installation. Compare a normal period and a peak, then check whether the slowdown coincides with real memory pressure.

## Plan for storage space and activity

Count the system, the application, the data and temporary files. Add the space needed for updates, exports and expected growth. Keeping a working copy on the same disk can also increase the required space without providing independent protection.

The capacity stated in GB does not measure the speed of your accesses. Observe the volume and duration of reads and writes with the appropriate tools, especially iostat when it is installed. The term NVMe does not provide a guaranteed result for your database or application.

## Read the five WispHost setups

The range lets you compare compute, memory and storage together. The table below describes the resources in the catalog; it does not turn each setup into a guaranteed number of sites, connections or requests per second.

| Configuration | vCPU | RAM | NVMe storage |
| --- | --- | --- | --- |
| Wisp Spark | 2 | 4 GB | 60 GB |
| Wisp Core | 3 | 8 GB | 120 GB |
| Wisp Flow | 4 | 16 GB | 240 GB |
| Wisp Scale | 6 | 32 GB | 480 GB |
| Wisp Prime | 8 | 64 GB | 800 GB |

## Set a starting point and review criteria

Choose the setup that covers your measured scenario with a reasonable margin, then record your re-evaluation thresholds: insufficient available memory, storage soon to be full, or responses exceeding your target under a known load. There is no margin percentage suitable for every project.

Before an upgrade, rerun the same test and check the options for changing range with the team. A well-organized application, database and backup strategy make this decision easier. The server should follow the measured need rather than compensate for an estimate that has remained unchanged.

## Sources and references

- [Red Hat — monitoring tools for CPU, memory and I/O](https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/10/html-single/monitoring_and_managing_system_status_and_performance/index)
- [Red Hat — how virtual hardware works with KVM](https://www.redhat.com/en/topics/virtualization/what-is-KVM)

## Your next step

[Compare the resources of the VPS](https://wisphost.com/vps/)

## Read next

- [VPS or dedicated server: how to choose for your project?](https://wisphost.com/blog/vps-or-dedicated-server/)
- [Snapshot, backup and RAID: what differences for your data?](https://wisphost.com/blog/snapshots-vs-backups/)

[All WispHost guides](https://wisphost.com/blog/)