7 Signs It’s Time to Upgrade From KVM 1 to KVM 2

You should upgrade from KVM 1 to KVM 2 when your server runs out of headroom, not when your traffic hits some magic visitor number: the clear signals are CPU load sitting near 100% of your single core for hours at a time, memory pinned close to the 4 GB ceiling with swap being used daily, disk sitting above roughly 80% of the 50 GB NVMe allowance, or monthly transfer creeping toward the 4 TB cap. KVM 2 doubles all four of those, giving you 2 vCPU cores, 8 GB RAM, 100 GB NVMe storage and 8 TB of bandwidth. Most single WordPress sites, small business sites and portfolios never come close to needing that; the setups that do are multi-site servers, busy WooCommerce stores, Docker stacks, self-hosted apps like n8n or a mail server, and anything running a database that’s grown past a few gigabytes.

The switch itself happens inside hPanel and needs a short reboot, so your data and configuration stay exactly where they are.

KVM 1 and KVM 2 are the same plan with every number doubled

The two plans sit next to each other in Hostinger’s VPS lineup and there’s no difference in the underlying technology, only in how much of the host machine you’re allocated. Both run on KVM virtualisation, which gives each customer a genuinely separate virtual machine with its own kernel rather than a shared container. If you want the technical background on that, the KVM hypervisor project documents how the Linux kernel handles it.

Here’s how the two compare:

The jump from one core to two matters more than the raw doubling suggests. With one vCPU, a single runaway process, a backup job, or a heavy WP-Cron task can occupy the whole processor and everything else queues behind it. With two cores, one busy task leaves the other core free to keep serving pages.

That’s the practical difference people notice first.

Note: specs and pricing on VPS plans do change. Confirm the current numbers on Hostinger’s own plan page before you buy, especially bandwidth allowances, which get adjusted more often than CPU and RAM.

Five signs your site has outgrown a KVM 1 server

None of these on their own proves you need more resources. Two or three showing up together over a week or more usually does.

CPU load stays above your core count

On a single-core VPS, a one-minute load average above 1.00 means requests are waiting. Brief spikes during a backup or a plugin update are normal. Load sitting at 1.5 or higher through your whole busy period, every day, means the core is the bottleneck and no amount of caching tweaks will fix it permanently.

Memory is full and swap is active every day

Linux uses free RAM for disk caching, so “low free memory” by itself is meaningless. What matters is the available figure and swap activity. If available memory regularly drops below a few hundred megabytes and swap usage climbs past a hundred megabytes or so, your workload wants more than 4 GB.

MySQL and MariaDB are the usual culprits here once a database passes a couple of gigabytes.

Processes are getting killed

The Linux out-of-memory killer terminates whatever it decides is the biggest offender when RAM runs out. On a WordPress server that’s almost always MySQL, which is why sites suddenly show “error establishing a database connection” and then recover on their own. If you find OOM entries in your kernel log more than once a month, that’s your answer.

Disk is past 80% full

50 GB sounds generous until you add backups, a Docker image cache, uncompressed logs and a media library. Once you’re above 80%, MySQL temp tables and package updates start failing in ways that look like random errors. Cleaning up buys time.

If you’re back at 80% within a couple of months, the storage is genuinely too small. Keeping media trimmed helps too, and there are sensible upload limits worth applying before you blame the plan.

You’re running out of bandwidth headroom

4 TB a month is a lot for a normal site. It stops being a lot when you host video, large downloads, a heavily crawled store with thousands of product images, or a public API. If you’re consistently past 3 TB, upgrade before you hit the ceiling rather than after.

How to check whether your VPS is actually maxed out

Time needed: about 15 minutes, plus a week of watching graphs.

Difficulty: beginner-friendly for the hPanel parts, basic command line for the rest.

1. Log in to hPanel, open your VPS, and go to the resource usage graphs. Set the window to 30 days rather than 24 hours, because a single spike tells you nothing and a repeating daily pattern tells you everything.
2. Connect over SSH and run htop. Watch the CPU bar and the load average in the top-right during your busiest hour. On one core, sustained load above 1.00 means requests are queuing.
3. Run free -h and read the “available” column, not “free”. If available memory sits under roughly 400 MB during normal traffic, you’re memory-bound.
4. Run df -h and look at the percentage used on /. Anything past 80% needs either a cleanup or a bigger disk.
5. Check for out-of-memory kills with sudo journalctl -k | grep -i "out of memory" or sudo dmesg -T | grep -i oom. Any recent hits mean the server has already failed under load at least once.
6. Run sudo mysqladmin status or check your control panel’s database size, then compare it against your InnoDB buffer pool setting. A database larger than the RAM you’ve allocated to it is a slow database.

Warning: don’t run a synthetic load test against a production VPS during business hours. You’ll take your own site down and the numbers you get won’t reflect real traffic patterns anyway.

Timing note: if you’ve just migrated to the server, wait a full week before judging. Fresh migrations trigger crawler activity, cache rebuilds and backup jobs that make the first few days look far worse than normal.

The workloads that hit the KVM 1 ceiling fastest

Some setups sail along on one core for years. Others struggle in month two. Knowing which camp you’re in saves you from guessing.

Multiple WordPress sites on one server. Three or four brochure sites with light traffic are fine on KVM 1. Once you’re past six or seven, each with its own PHP-FPM pool and cron schedule, RAM goes first. This is also where people notice the sluggish dashboard problem that has nothing to do with front-end speed and everything to do with admin-ajax requests eating the one core you have.

WooCommerce and other logged-in-heavy sites. Cart, checkout and account pages can’t be page-cached. Every one of those requests hits PHP and the database. A store doing a few hundred orders a month is fine; a store with steady concurrent shoppers during a sale is exactly the scenario where a second core pays for itself.

Docker and multi-container stacks. Each container carries its own overhead. A Portainer instance plus a database plus two or three app containers will use 3 GB before you’ve had a single visitor.

Self-hosted apps. n8n, Nextcloud, Grafana, GitLab runners, Matomo and self-hosted mail servers are all memory-hungry. A full mail stack alone wants a couple of gigabytes, and if you’re already wrestling with messages landing in spam, adding resource pressure on top makes diagnosis a nightmare.

Game servers and voice servers. These are latency-sensitive and single-threaded in many cases. One core with a busy web stack alongside it produces lag that no configuration change removes.

Staging plus production on one box. Cloning a live site to a staging subdomain doubles the memory footprint. If you’re spinning up extra subdomains for client previews, count each one as a real workload rather than a freebie.

When you should fix the setup instead of paying for more resources

I’d rather you spend an afternoon tuning than an extra year of hosting fees solving a problem you created. Plenty of “I need to upgrade” situations are configuration problems wearing a costume.

Start with page caching. A WordPress site without full-page caching does 10 to 50 times more work per visitor than one with it. LiteSpeed Cache, WP Super Cache or an nginx FastCGI cache will drop CPU load dramatically on content sites.

If your load average halves overnight, you didn’t need KVM 2.

Next, check your PHP-FPM pool settings. Default configs often spawn far more child processes than 4 GB can support, which produces memory exhaustion under load even though the actual traffic is modest. Setting pm.max_children to something your RAM can genuinely feed prevents OOM kills.

Then look at the database. An untuned MySQL install with a 128 MB buffer pool on a 4 GB server is leaving performance on the table. Cleaning post revisions, transients and orphaned meta rows often shrinks a bloated WordPress database by half.

Finally, audit what’s actually running. Old backup plugins that keep archives on the server, log files nobody rotates, abandoned test installs. Clearing out leftover sites that still exist on disk frees space and cuts the cron jobs firing in the background.

Note: if your CPU is pinned at 100% and you can’t identify a single process responsible, check for a brute-force attack on wp-login.php or xmlrpc.php before upgrading. Bots can consume an entire core, and a bigger plan gives them a bigger playground rather than solving anything.

What actually happens when you change the plan

The upgrade runs from hPanel. You open the VPS, go to the plan or server details section, choose KVM 2, and confirm. Hostinger applies the value remaining on your current term toward the new plan and shows the amount payable on the confirmation screen before you commit, so read that figure rather than assuming.

Your data stays. The virtual machine is resized rather than rebuilt, which means your operating system, control panel, sites, databases, SSH keys, firewall rules and IP address all survive. What you do get is a reboot, because CPU and memory allocation changes require the VM to restart.

Expect a short outage measured in minutes, not hours.

Take a snapshot before you start anyway. It costs you nothing and it’s the difference between a five-minute rollback and a bad afternoon. Weekly backups run on both plans, and it’s worth knowing how long restore points stick around before you rely on them as your only safety net.

One more practical point: schedule the change for your quietest hour. If your traffic peaks at lunchtime in the US, do it at 3am. And confirm the disk actually expanded afterwards by running df -h, because on some setups the filesystem needs to catch up with the new partition size.

Timing note: plan changes are usually live within a few minutes of payment clearing, but Hostinger’s own help center is the place to check current process details, since the flow in hPanel gets updated periodically.

Should you skip KVM 2 and go straight to KVM 4?

If your current server is failing on memory alone, KVM 2’s 8 GB solves it for most people and there’s no reason to overshoot. If you’re already at 2 GB of database in RAM plus multiple containers, look harder at KVM 4, which gives 4 vCPU, 16 GB RAM, 200 GB storage and 16 TB bandwidth.

The honest rule I use: pick the plan that leaves you at roughly 50 to 60% resource use during your peak hour. That gives room for traffic growth, a viral post, and the occasional backup job without immediately shopping for another upgrade. Sitting at 90% on a new plan means you bought the wrong one.

Cost matters too. Upgrading twice in six months costs more in aggravation than in money, but the aggravation is real: two reboots, two rounds of testing, two maintenance windows. If your growth is steady and predictable, one bigger step beats two small ones.

There’s also a direction people forget to consider. If you’re on shared hosting and reading this to work out which VPS to start with, the decision tree is a bit different, and the case for stepping up from a shared plan is worth reading first, because plenty of sites don’t need a VPS at all yet.

Things people get wrong about the KVM 1 to KVM 2 jump

Mix-up: More RAM makes a website load faster.

Reality: Extra RAM only helps if memory was the bottleneck. For a single visitor on an uncontested server, load time is decided by PHP execution, database queries, caching and network latency. Doubling RAM on a server that was never short of it changes nothing you can measure.

Mix-up: One vCPU means the server can only handle one visitor at a time.

Reality: A single core handles many concurrent requests by time-slicing between them. Your real concurrency limit comes from PHP-FPM worker count and how long each request takes, not the core count. One core with 80ms cached responses serves far more traffic than two cores with 2-second uncached ones.

Mix-up: Upgrading wipes the server and you have to reinstall everything.

Reality: The plan change resizes the existing VM. Your OS, files, databases and IP address stay put. The only interruption is the reboot.

Mix-up: Bandwidth caps mean your site goes offline the second you hit 4 TB.

Reality: Policies vary and can change. Check the current terms on the plan page rather than assuming either a hard cutoff or unlimited leniency.

Problems that show up after the upgrade, and how to fix them

Problem: You moved to KVM 2 and the site is exactly as slow as before.

Fix: The bottleneck was in the application, not the hardware. Run a query profiler, check for a plugin doing external API calls on every page load, and confirm page caching is actually serving cached HTML rather than being bypassed by a cookie.

Problem: df -h still shows a 50 GB disk after upgrading.

Fix: The filesystem hasn’t been expanded to match the new partition. Reboot once more, and if it still reports the old size, open a support ticket rather than resizing partitions by hand on a live server.

Problem: Services didn’t come back after the reboot.

Fix: Something wasn’t set to start on boot. Run sudo systemctl status on your web server, PHP-FPM and database, then use sudo systemctl enable on anything that was running manually before.

What to do next with this information

If you’ve watched a full week of graphs and two or more of the warning signs are showing, upgrade and stop worrying about it. The difference between one core and two on a busy server is immediately obvious in your response times, and you’ll spend less time firefighting than you would tuning a machine that’s fundamentally out of capacity.

If only one sign is showing, and especially if it’s disk space, fix the underlying cause first. Clean up, add caching, tune PHP workers, then re-measure a week later. Half the people who think they need to upgrade from KVM 1 to KVM 2 don’t, and the other half needed to do it three months ago.

And if you’re setting up a new server rather than rescuing an existing one, size it for the workload you’ll have in six months, not the one you have on launch day. Buying KVM 2 up front for a Docker stack or a multi-site setup avoids a migration window you didn’t need to schedule.

Check current Hostinger VPS plans and pricing and use code hHostCouponHub for up to 85% off. You can also compare it against the rest of our Hostinger deal roundup if you’re bundling an SSL certificate into the same order.

Frequently asked questions

How many websites can a KVM 1 VPS handle?

There’s no fixed number, because it depends entirely on traffic and how the sites are built. As a working guide, 4 GB of RAM and one core comfortably runs five or six low-traffic WordPress sites with page caching enabled, and struggles with two busy WooCommerce stores. Watch memory use rather than counting sites.

Does upgrading from KVM 1 to KVM 2 cause downtime?

Yes, but only a brief one. Changing CPU and RAM allocation requires the virtual machine to reboot, so expect a few minutes of unavailability. Take a snapshot first and run the change during your quietest hours.

Is 4 GB of RAM enough for WordPress on a VPS?

For one WordPress site, yes, comfortably, even with a decent amount of traffic and full-page caching in place. It gets tight once you add a control panel, a staging copy, an object cache, a mail service and multiple sites on the same server. The database is usually what pushes you past the limit.

Can I downgrade from KVM 2 back to KVM 1 later?

Plan changes on Hostinger VPS are built for moving up, and going back down isn’t something you should assume you can do from hPanel. Ask support what’s possible before you upgrade if you think you’ll want to reverse it, since shrinking a disk that already holds data is not a routine operation anywhere.

Pick the plan that matches the load you measured, not the one that sounds impressive, then leave the server alone and let it work. When you’re ready to move up, grab the current VPS discount here with code hHostCouponHub, and keep our notes on documenting your server setup handy so the next person who touches the box knows what changed.

This page contains affiliate links. If you purchase through the links on this page, we may earn a commission, at no extra cost to you.