When to upgrade your VPS, and when not to

October 18, 2026 · Updated October 22, 2026

A bigger plan fixes a server that is short every day. It does nothing for a slow afternoon.

Upgrade your VPS when memory, disk or processor is short on most days, at ordinary hours. One slow day is not a reason. Neither is a nightly backup that keeps the server busy for a while. A bigger plan fixes a server that has outgrown its size. It does nothing for a problem that comes and goes.

Here is how to tell which part is short, and what to try before you pay more.

Look at days, not minutes

Every server has busy minutes: a traffic spike, an import, a plugin update. Those pass on their own. The question is whether the server is short on an ordinary day. Check at a few different times over a week before you decide.

The commands below run in a terminal on the server. If someone else set it up, send them this page.

Memory: read “available”, not “free”

On a small WordPress or Laravel server, memory is often the first thing to run short.

free -h

Look at the available column. Linux fills spare memory with cache, so free always looks low. That is normal. available is what programs can still use.

Judge the amount left, not the percentage. 10 % of 16 GB is 1.6 GB, which is plenty. 10 % of 1 GB is about 100 MB, which is not.

Memory really is short when:

• available sits at a few hundred megabytes or less for hours, on ordinary days.
• The server keeps pushing memory out to disk (swap), even when it is quiet.
• The system has stopped a program because memory ran out.

To see swap activity, run vmstat 5 5. Skip the first line, which is an average since boot. Numbers above zero under si and so mean memory is going to and from disk.

To see whether memory ran out since the last restart:

sudo journalctl -k | grep -i "out of memory"

A line here means the system closed a program to survive, often the database. That is not a maybe. It will happen again until the server has more memory, or until whatever grew is fixed. We go through it step by step in why MySQL keeps getting killed on your VPS.

Disk: how much is left, and how fast it goes

df -h

Look at Avail for / and for any other disk you use. When a disk fills, the database cannot save anything new.

How fast it shrinks matters more than today’s number. Run df -h again a week later. If it lost 2 GB and 6 GB are left, you have about three weeks.

Before you buy disk, find what grew:

sudo du -xh --max-depth=1 / 2>/dev/null | sort -h | tail

Old backups, logs and database dumps are the usual answer. Clearing them is free.

One odd case: df -i can show a disk out of file slots while space is still free. Lots of tiny files cause it, such as old sessions or cache. Deleting those files is the fix.

Processor: compare the load with your processors

nproc
uptime

nproc is how many processors your plan gives you. uptime ends with three load averages: the last 1, 5 and 15 minutes. A load near the processor count means the processor is fully used. Well above it means work is waiting.

One high reading is nothing. A load above the processor count for long stretches, on most days, means the plan is too small.

To see what is using it, run top. Look at the program at the top of the list. Then look at st in the %Cpu(s) line. We come back to that one below.

Three things that are not reasons to upgrade

A nightly backup. Backups compress files and dump the database. They can keep the processor flat out for a while. That is normal. If it runs during your busiest hours, move it to a quieter time.

A busy machine at your provider. A VPS shares a physical machine with other customers. The st (steal) figure in top is processor time they took from you. When it stays high, nothing on your side is wrong. Ask your provider about it, or ask to move to another machine. A bigger plan on the same machine may not help.

A program that keeps growing. Some programs use a little more memory every hour until it runs out. After a restart, it starts again. A bigger plan only makes the gap between restarts longer. Ask your developer what grew.

Try these before paying more

• Find the biggest programs by memory with ps aux --sort=-rss | head.
• Ask your developer whether PHP or the database is set to use more memory than the server has. Too many PHP workers is a common cause on small servers.
• Add a page cache, so most visits do not run PHP or the database at all.
• If the server has no swap, a small swap file gives it room for short peaks. It does not fix a server that is short every day.
• Clear old backups and logs before you buy disk.
• Restart a service, or the server, to buy a little time while you decide.

What to upgrade, and by how much

Upgrade the part that is short. If your provider sells plans where everything grows together, take the next plan up.

Plan sizes usually double: 1 GB of memory to 2 GB, 1 processor to 2, a 25 GB disk to 50 GB. The next common size up is usually the right step. If the server is still short a week later, take the next one. For a WordPress server, how much RAM a WordPress server needs shows how to work out the number.

Resizing is usually done from your hosting panel, and it needs a restart. Some providers cannot make a disk smaller again, so check before you add disk.

After the upgrade, compare an ordinary day after it with one before. If the same signs come back, the size was not the problem. Ask your developer what is growing.

Or let the server tell you

If you’d rather not run these checks by hand, PimiPulse watches your server for you. It waits until a shortage has lasted, then names the part that is short and the size to move to. It reads, and never changes anything.

On a 1 GB server that is getting tight, it says: “Your server is coping, but memory is getting tight.” And then: “The next common size up from 1 GB is 2 GB, which would give it room. If this keeps up for a day or two, upgrade memory from your hosting panel.”

This post is about PimiPulse, part of Pimi.