The First Hour on a New VPS: Five Numbers That Tell You What You Bought

A cheap VPS is not usually a broken VPS. It is a machine where several numbers are smaller than the label suggests, and the label is not lying — it is measuring something adjacent to what you assumed.

The kernel already publishes the five counters that reveal this. Reading them takes about an hour, once, and it converts “this feels slow” into a measurement you can act on or stop worrying about.

1. Steal: the CPU time someone else took

The /proc/stat CPU line ends with several fields most people never look at. The eighth is steal, and the kernel documentation defines it in four words:

“steal: involuntary wait”

That is the whole official definition, and the phrase is precise. Your vCPU is a share of a physical core. When another tenant’s work occupies the core that would have run your instruction, your guest does not see an error and does not see idle. It waits, involuntarily, and the time is accounted to steal.

Check it with a snapshot, then a live sample:

head -1 /proc/stat      # eighth field of the aggregate cpu line
vmstat 1 5              # 'st' column, sampled every second

A single non-zero reading means nothing — some steal is normal on any virtualised host. What matters is whether it is persistently non-zero while your machine is idle, because that is a machine sharing a core with something busy. There is no official threshold here, and anyone quoting one is quoting their own preference. Build your own baseline: take a reading on a quiet machine, take another while under load, and compare the same host at the same hour tomorrow.

2. Available, not free

free -m prints a free column that is often alarmingly small, and people conclude the machine is out of memory. It usually is not. Look at available instead, which the kernel documentation defines as:

“An estimate of how much memory is available for starting new applications, without swapping. Calculated from MemFree, SReclaimable, the size of the file LRU lists, and the low watermarks in each zone.”

The important part is the phrase “without swapping.” A Linux box deliberately uses otherwise-idle RAM for page cache, and that cache is reclaimable the moment a new process needs it. So free counts memory that is doing useful work but is available on demand; available counts what a new process can actually get. On a healthy machine, available stays high while free looks grim, and that is the system working as designed.

What you are actually checking on a new cheap VPS is whether available is close to the advertised RAM after a fresh boot with nothing running. If a plan sells 2 GB and a clean boot leaves 900 MB available, something is consuming it, and it is worth knowing what before you install anything.

3. Load average is a count, not a percentage

uptime reports three numbers, and the docs are explicit about what they are:

“Load average of last 1, 5 & 15 minutes; number of processes currently runnable (running or on ready queue); total number of processes in system; last pid created.”

A count of runnable processes. Not CPU utilisation. A machine at load 2.00 on 2 vCPUs is fully occupied and healthy; the same 2.00 on an 8-core box is nearly idle. This is why load average is useless until you divide it by the core count — and why comparing your 2.00 to someone else’s 4.00 on a different machine tells you nothing.

The one thing load average does reveal on a cheap box is stuck processes. If load climbs while CPU usage stays low, you are looking at processes blocked on I/O, which leads directly to the fourth number.

4. Disk latency, because the disk is probably not yours

Cheap plans put your writes on network-attached storage, and network storage has a latency profile that a local SSD does not. Measure it directly, bypassing the page cache:

dd if=/dev/zero of=testfile bs=1M count=1024 oflag=direct

oflag=direct matters — without it you are measuring RAM. Run it twice. The first run pays for allocation; the second is closer to what a steady write costs. Then delete the file.

What you are looking for is not a number but a shape: if repeated runs vary wildly, or if a sequential write stalls for hundreds of milliseconds, that is the I/O path you will be sharing at 3 a.m. Combine it with the load reading above — high load with low CPU and a stalling dd is a complete diagnosis, and it took two commands.

5. Inodes, the limit nobody mentions at checkout

df -h shows space. df -i shows inodes — the count of files, not bytes. Many cheap plans allow generous storage and a modest inode ceiling, and small files are exactly what modern deployments produce: node_modules, build caches, session files, mail queues.

df -i

A plan with a few hundred thousand inodes is fine for a static site and tight for anything that accumulates small files. The failure looks like a full disk that reports as empty, and the error messages rarely mention inodes, which is why it costs people an evening.

Build a baseline, not a verdict

The mistake is to run these once, find a number you dislike, and open a support ticket. Counters are only interpretable against a reference.

1. Take the readings on a fresh boot, with nothing running — that is the machine’s resting state.
2. Take them again under a realistic load for your site, not a synthetic benchmark.
3. Repeat at the same hour a day later. A pattern across two days is evidence; one sample is an anecdote.

If the numbers are stable and the machine does what you need, the plan is correctly priced and you can stop looking. If steal climbs whenever your neighbour is busy, or available never reaches the advertised figure, you have found the thing the price was hiding — and the first month is the cheapest time to find out, because most hosts refund inside a window.

What this does not tell you

This measures the machine. It says nothing about whether the network path to your visitors is good, which is a different measurement with its own traps — TTFB in particular is easy to mismeasure and will make a fine host look slow. And if what you actually need is a decision between a shared plan and a VPS, the five counters above are the wrong starting point; the shared-plan limits are the ones that matter there.

The point of the hour is not to grade the vendor. It is to replace “this felt sluggish” with five numbers you can compare against the same five numbers next month, on this machine or a replacement.