Overview
A VPS (Virtual Private Server) gives you a slice of a physical host machine, with a guaranteed portion of its VPS resources including RAM, CPU, and storage. You’re not sharing those resources the same way you would on shared hosting, but you’re also not getting the full isolation of a dedicated server. Understanding the difference matters a lot when your site slows down or an application starts throwing errors.
Most users only look at the numbers on their plan page. What they miss is how those numbers behave under real workload conditions. RAM on a VPS is almost always a hard limit. CPU is often where things get more nuanced — and that’s where most performance surprises come from.
This article covers how RAM and CPU allocation works on a typical KVM-based VPS (which is what Host & Tech uses), how to check your current usage, and how to tell when you’ve genuinely outgrown your plan versus when something is just misconfigured.
Prerequisites
- SSH access to your VPS (root or sudo user)
- A terminal client — PuTTY on Windows, Terminal on macOS/Linux
- Basic comfort with Linux command line (you don’t need to be an expert)
- Your VPS should be running a standard Linux distribution — these examples use Ubuntu 22.04 or CentOS Stream 9, but the commands work on most distros
How RAM Allocation Works on a VPS
RAM is typically the most straightforward resource on a VPS. With KVM virtualisation (the technology behind most modern VPS hosting, including our VPS SSD Hosting), your RAM allocation is hard-set at the hypervisor level. If your plan says 4 GB, your OS sees exactly 4 GB and cannot exceed it.
This is different from older OpenVZ-based setups, where RAM could be soft-limited and occasionally borrowed from a shared pool. KVM doesn’t work that way — which is actually better for consistency, even if it means you hit the wall more abruptly.
Checking Your Available RAM
To see your current RAM usage, run:
free -hYou’ll get output like this:
total used free shared buff/cache available
Mem: 3.8Gi 1.2Gi 512Mi 128Mi 2.1Gi 2.3Gi
Swap: 1.0Gi 0.0Gi 1.0GiThe column to watch is available, not free. The free column shows memory not in use at all. The available column shows what the kernel can actually hand to a new process, including memory currently used for cache that can be released. Most people panic when they see a low free value — but Linux intentionally uses spare RAM for disk caching. That’s normal and healthy behaviour.
📝 Note: If your available column is consistently below 200–300 MB under normal load (not a traffic spike), that’s a genuine sign you’re running low. Under 100 MB and you’re likely already seeing swap use or OOM (Out of Memory) kills.
Swap: The Safety Net You Shouldn’t Rely On
Swap is disk space used as overflow RAM. It keeps your server from crashing outright when memory fills up, but it’s orders of magnitude slower than real RAM. If your server is consistently using swap, that’s not a configuration win — it’s a sign you need more RAM or need to audit what’s consuming memory.
Check swap usage with:
swapon --show
free -h⚠ Warning: On SSD-based VPS plans, swap is less destructive than on spinning disk, but heavy swap use will still tank your application response times. Don’t treat swap as a substitute for proper RAM allocation.
How CPU Allocation Works on a VPS
CPU on a VPS is where things get more interesting, and where a lot of users get confused or frustrated.
When your plan says “2 vCPUs,” that means you’ve been assigned 2 virtual CPU cores. On a KVM host, each vCPU maps to a thread on the physical host’s processor. Whether those vCPUs are dedicated or shared depends on the hosting provider and plan tier.
On most standard VPS plans (including our entry-level VPS SSD Hosting starting from $5.83/mo), vCPUs are shared at the hypervisor level. This means your 2 vCPUs are guaranteed up to their allocated share, but if the physical host is under light load, you can burst beyond that. Conversely, under heavy host load, you’ll be throttled back to your fair share.
This is not a gotcha — it’s standard practice across the industry and is usually what makes affordable VPS pricing possible. What matters is whether the provider oversells aggressively. We don’t.
Checking CPU Usage
The quickest way to check real-time CPU usage is top or the more readable htop:
# Install htop if it's not already there
apt install htop -y # Ubuntu/Debian
dnf install htop -y # CentOS/AlmaLinux/Rocky
# Run it
htopIn htop, look at the CPU bars at the top. You want to understand which processes are consuming CPU, not just the total percentage. A single PHP-FPM worker pegging one core is a very different problem from a MySQL query causing system-wide CPU saturation.
For a historical view of CPU usage over time, sar (part of the sysstat package) is more useful than any real-time tool:
apt install sysstat -y
sar -u 1 10This samples CPU usage once per second, ten times. The %iowait column is the one people overlook — high I/O wait means your CPU is idle but waiting on disk, which points to a storage bottleneck rather than a CPU one.
CPU Steal Time: The Non-Obvious One
In top or htop, there’s a metric called steal time (shown as %st in top). This is the percentage of time your vCPU wanted to run but the hypervisor couldn’t give it CPU cycles because the physical host was busy. This is genuinely the most important metric on a shared VPS that most users never check.
Steal time above 5% consistently is a red flag. Above 10–15% means you’re on an overloaded host and your performance will suffer regardless of how well-tuned your application is. In my experience, this is more often the cause of “my VPS feels slow” complaints than anything in the application stack.
Check it with:
topLook at the CPU line: %Cpu(s): 12.0 us, 2.0 sy, 0.0 ni, 80.0 id, 1.0 wa, 0.0 hi, 0.5 si, 4.5 st — that last st value is steal time.
If you’re consistently seeing high steal time on a Host & Tech VPS, open a support ticket and we’ll investigate the host node or migrate you.
Storage I/O: The Third Resource People Forget
RAM and CPU get all the attention, but disk I/O throughput matters just as much for most web workloads. All Host & Tech VPS plans use NVMe or SSD storage precisely because spinning-disk I/O on a virtualised environment is painful under any real load.
Check disk I/O with:
iostat -x 1 5The %util column shows how saturated your disk is. If it’s sitting above 80–90% regularly, you have an I/O problem — often caused by a database without proper indexing, a runaway log file, or a backup job running during peak hours.
Common Issues and Troubleshooting
Server feels slow but CPU and RAM look fine
Check steal time first (see above). If steal time is low, run iostat -x 1 10 and look for high %util on your disk. High I/O wait (%iowait in top) combined with high disk utilisation almost always points to a database query doing a full table scan, or a backup process running during business hours.
Application crashes randomly with no clear error
This is usually an OOM (Out of Memory) kill. The Linux kernel silently kills processes when memory runs out. Check /var/log/syslog or /var/log/messages for entries containing oom-kill or Out of memory:
grep -i 'oom|out of memory' /var/log/syslog | tail -20If you find OOM kills, you need either more RAM or to tune your application’s memory limits (PHP’s memory_limit, MySQL’s innodb_buffer_pool_size, etc.).
MySQL is consuming all available RAM
MySQL (and MariaDB) will use as much RAM as you give it. The main culprit is innodb_buffer_pool_size in /etc/mysql/mysql.conf.d/mysqld.cnf (Ubuntu) or /etc/my.cnf (CentOS). A common rule of thumb is to set this to 50–70% of total RAM on a dedicated database server — but on a VPS running a full web stack, 25–40% is safer.
[mysqld]
innodb_buffer_pool_size = 512MRestart MySQL after changing this: systemctl restart mysql
PHP processes piling up and eating RAM
If you’re running PHP-FPM, check your pool configuration at /etc/php/8.2/fpm/pool.d/www.conf. The pm.max_children setting controls how many PHP worker processes can run simultaneously. Set it too high and you’ll exhaust RAM. A rough calculation: divide your available RAM (after OS and MySQL overhead) by the average RAM per PHP process (~30–50 MB for a typical WordPress site).
; For a 2 GB VPS with ~800 MB free for PHP workers:
pm.max_children = 20VPS becomes unresponsive after traffic spike
Under sudden traffic, the first thing to check is whether it’s a RAM exhaustion event (OOM kills) or CPU saturation. If it’s CPU, look at whether your web server is spawning too many worker processes. On Apache with the prefork MPM, MaxRequestWorkers in /etc/apache2/mods-enabled/mpm_prefork.conf controls this. On Nginx, the defaults are much more conservative and rarely cause this problem. If you’re regularly hitting this scenario, it may be time to look at a higher-tier VPS plan or a dedicated server for consistent high-traffic workloads.
FAQ
Frequently Asked Questions
What's the difference between RAM on a VPS vs shared hosting?
On shared hosting, there’s no guaranteed RAM allocation — you’re competing with every other account on the server. On a KVM VPS, your RAM is hard-allocated and reserved specifically for your instance. Other VPS users on the same physical host cannot take your RAM, even if they’re sitting idle.
How much RAM do I need for a WordPress VPS?
For a single WordPress site with moderate traffic (under 10,000 visits/day), 1–2 GB is workable if you’re running a caching plugin like WP Rocket or W3 Total Cache. For WooCommerce stores or multiple WordPress sites on the same VPS, 2–4 GB is more realistic. If you want a managed setup without worrying about this tuning, Host & Tech’s managed WordPress hosting handles it for you.
Can I upgrade my VPS RAM without migrating to a new server?
With KVM virtualisation, RAM changes typically require a reboot of your VPS but not a full migration to new hardware. Most upgrades through the control panel take effect after a clean restart. Always take a snapshot or backup before resizing, in case anything doesn’t come back up cleanly.
What is CPU steal time and should I be worried about it?
Steal time is the percentage of time your vCPU was waiting for the physical host’s CPU because other virtual machines were competing for it. A steal value under 2–3% is normal. Consistent steal time above 5–10% means your VPS host is overloaded and your workloads will be affected. Check it using the ‘st’ metric in the top command, and contact support if it’s persistently high.
My VPS plan says 4 vCPUs — are those dedicated cores?
On standard VPS plans, vCPUs are virtualised threads mapped to physical host cores, not dedicated cores in the way a bare-metal dedicated server would give you. You’re guaranteed your fair share of those CPU resources, and you can often burst higher when the host is under light load. If you need guaranteed, consistent CPU performance with no contention, a dedicated server is the right product for that use case.