I am not writing this as a negative review of AVA Hosting.
This is simply one of my days as a developer: a server behaved badly, the obvious explanations did not fit, and eventually Linux showed me what was happening.
I had a small AVA Hosting KVM VPS with:
1 vCPU
2 GB RAM
25 GB NVMeA normal production workload was running on it. Nginx was alive. The backend was alive. There was available memory. The disk was not full.
But the server could not keep up.
So I ran a passive 60-second diagnostic under normal production traffic. No stress test, synthetic HTTP flood or disk benchmark.
The result:
vCPU count: 1
Average CPU user: 52.52%
Average CPU system: 8.07%
Average CPU softirq: 6.69%
Average CPU steal: 32.73%
Average CPU iowait: 0.00%
Average CPU idle: 0.00%
Maximum runnable queue: 11The number that mattered was 32.73% CPU steal. That changed the diagnosis completely.
Why this surprised me
AVA Hosting currently advertises its VPS product with the phrase “Guaranteed resources — no sharing”. Its VPS pages also describe fixed or dedicated vCPU allocation and say performance should not be affected by other customers. On its Linux VPS material, AVA goes further and says that another tenant's CPU-intensive workload cannot introduce steal time into your instance. Another page says CPU steal is eliminated at the hypervisor level.
Those are unusually specific claims. This was not simply a VPS page listing 1 vCPU while leaving the CPU allocation model unspecified. AVA was explicitly advertising protection from the exact kind of CPU contention that Linux appeared to be reporting inside my VM.
What CPU steal means
steal is a normal Linux CPU metric used in virtualized environments. It represents CPU time during which the guest had runnable work but the virtual CPU was not actually running.
That is different from my application simply consuming all of its CPU. If I had seen roughly 100% user/system CPU, 0% steal and 0% idle, I would have concluded that my workload simply needed more processing power.
Instead, roughly one third of the CPU accounting was steal.
I cannot see AVA's hypervisor from inside the guest. I cannot know the physical-node load, number of neighbouring VMs, CPU pinning policy or overcommit ratio. What I can see is what Linux reported to my VM: the vCPU was repeatedly not running while there was work waiting to execute.
It was sustained, not a one-second spike
A single ugly CPU sample would not have convinced me of much, so I measured the machine continuously for 60 seconds. I deliberately did not run a stress test, synthetic HTTP flood or disk benchmark.
The per-second samples repeatedly looked like this:
%usr %sys %soft %steal %idle
53.54 10.10 5.05 31.31 0.00
56.44 6.93 5.94 30.69 0.00
51.52 7.07 6.06 35.35 0.00
55.45 6.93 5.94 31.68 0.00
51.49 8.91 5.94 33.66 0.00
52.53 7.07 7.07 33.33 0.00
52.48 6.93 7.92 32.67 0.00Near the end of the observation, the pattern was still there:
50.98 10.78 6.86 31.37 0.00
48.48 8.08 9.09 34.34 0.00
55.00 5.00 7.00 33.00 0.00The full average was:
user: 52.52%
system: 8.07%
softirq: 6.69%
steal: 32.73%
iowait: 0.00%
idle: 0.00%So this was not a brief scheduling anomaly. For most of the minute, steal remained around 30% or more while CPU idle remained at zero.
For intuition, 32.73% of one minute is about 19.64 seconds. That does not mean the VPS froze for 19.64 consecutive seconds; it means the smaller intervals during which the vCPU was not scheduled accumulated to roughly that amount.
The backend could not catch up
The CPU problem was also visible at the application level. Before monitoring, the backend listen queue was:
Recv-Q: 168
Send-Q: 511After 60 seconds:
Recv-Q: 166
Send-Q: 511The exact numbers are not important. What matters is that the queue essentially did not drain. The application had a full minute to catch up and remained behind.
There were also many CLOSE-WAIT connections. I would not blame the host for those alone, because that state can also involve application-side connection handling. But the overall picture was consistent:
1 vCPU
32.73% steal
0% idle
~99% CPU pressure
elevated runnable queue
backend queue not drainingThe server was alive, but it was not healthy.
RAM and disk were not the obvious bottlenecks
I checked the usual alternatives. Memory looked like this:
RAM total: ~1.9 GiB
RAM available: ~959 MiB
Swap total: 2 GiB
Swap used: ~33 MiBThere was still substantial memory available and no obvious OOM event explaining the behaviour.
The filesystem looked like this:
24 GB total
14 GB used
9.4 GB available
60% usedAverage CPU I/O wait was 0.00%. CPU pressure, meanwhile, stayed close to 99%, load average was around 3.5–4 on a one-vCPU VM, and the runnable queue reached 11.
Those measurements all pointed in the same direction: the machine was CPU-starved, not obviously blocked by RAM or storage.
The contradiction with AVA's wording
This is the part I find most interesting.
AVA says “Guaranteed resources — no sharing”. It says performance should not be affected by other customers. Its Linux VPS material says a co-hosted tenant cannot introduce steal time, and another page says CPU steal is eliminated at the hypervisor level.
My AVA VPS showed:
Average CPU steal: 32.73%I cannot prove from inside the VM exactly why that happened. I cannot prove malicious overselling, identify a particular neighbouring workload, or reconstruct AVA's host-side CPU configuration.
I am also not claiming that every AVA Hosting VPS behaves this way. I tested one VPS.
But I can say that the behaviour I measured is very difficult to reconcile with those specific CPU-isolation claims. That is enough for this article.
Why I did not upgrade
The obvious response would have been to buy more vCPUs.
If the VPS had been giving me essentially zero steal and my application had simply consumed an entire core, upgrading would have made sense. Instead, roughly one third of the observed CPU accounting was steal.
I did not want to pay for additional virtual CPUs before understanding why such a large fraction of the first one's execution time was already being reported as unavailable. So I cancelled the VPS and requested a refund.
AVA refunded everything quickly
This part of the experience was good.
AVA Hosting returned the full amount. They handled the refund quickly and did not spend days arguing with me about the CPU measurements. I explained the problem, requested my money back, and they refunded it.
I appreciate that.
So there are two separate conclusions from my experience: the VPS I received had a serious CPU-availability problem, and AVA handled my refund properly. Both are true.
What I took away from this
I no longer judge a VPS only by a specification such as 1 vCPU / 2 GB RAM / NVMe / KVM. Those numbers tell me what has been provisioned. They do not tell me how predictable the CPU will be under a real workload.
Now one of the first things I check on a new virtual machine is:
mpstat 1 60
vmstat 1 60
cat /proc/pressure/cpu
ss -ltnp
free -h
df -h
iostat -xz 1 60The most useful lesson from my AVA Hosting experience was not that one vCPU is too small. It was that a running process, available RAM and a healthy-looking disk can hide a very different problem underneath.
In my case, Linux made that problem unusually clear:
CPU steal: 32.73%
CPU idle: 0.00%
CPU pressure: ~99%AVA Hosting advertises CPU resources without sharing and says steal from neighbouring workloads should not happen. My VPS reported otherwise.
I cancelled it. AVA returned all of my money quickly and without an argument.
And that was the end of this particular debugging day.