A virtual server here is a virtual machine whose vCPU and memory are reserved for you and not overcommitted, so other tenants cannot take your CPU time or reclaim your RAM. A standard VPS often shares CPU more loosely. You can verify the difference: CPU steal should stay near zero under load, and repeated benchmarks should give consistent results.
What makes a virtual server different
Every virtual machine gets its CPU time from a hypervisor that schedules virtual CPUs onto physical cores. The question is how many virtual CPUs the host has promised compared with the physical threads it has. That ratio is the overcommit ratio.
On a typical budget VPS host, more vCPUs are sold than there are physical threads, on the reasonable bet that most machines are idle most of the time. When several tenants get busy at once, vCPUs queue for a physical thread, and your server slows for reasons that are not yours. Memory can also be overcommitted, with the host reclaiming idle RAM through a balloon driver or swapping guest memory on the host.
A virtual server, as we quote it, sets that ratio to no overcommit for CPU and memory: each vCPU you buy corresponds to a physical hardware thread reserved for you, and your memory is not reclaimed. Some platforms go further and pin vCPUs to specific cores. The exact mechanism (dedicated CPU class, pinning, or reserved capacity) depends on the supplier platform and is written into your quote, along with the CPU model and generation.
Worked example: what overcommit costs under contention
Assume a host with 64 hardware threads that has sold 256 vCPUs: a 4:1 overcommit. If every tenant is busy at once, each vCPU gets 64 / 256 = 25 % of a thread. A 4 vCPU VPS would then do the work of about one thread, and its guest would report heavy steal time. With no overcommit, the same 4 vCPUs map to 4 reserved threads whether the neighbors are busy or not. In practice full contention is rare; the problem is that you cannot predict when it happens.
Who needs reserved allocation, and who does not
Worth it for
- Databases where query times must stay steady at peak.
- Real-time media, game servers and trading or bidding systems where jitter shows up to users.
- Build and CI servers that run at full CPU for long periods.
- Anything with a latency target in a contract you sign with your own buyers.
- Capacity planning: you can only size accurately when the resources do not vary.
Not worth it for
- Mostly idle servers: small sites, VPN endpoints, low-traffic tools. A standard VPS costs less.
- Teams with nobody to run the OS: consider managed hosting, which can sit on top of a virtual server.
- Workloads needing a whole machine's memory bandwidth, local NVMe at full speed or special hardware: bare metal.
How to verify your allocation yourself
Do not take any provider's word for it, including ours. These checks take an afternoon and give you evidence.
1. Watch CPU steal under load
Steal is the time a vCPU was ready to run but the hypervisor ran something else. Linux exposes it as the eighth value on the cpu lines of /proc/stat, shown as st in top and vmstat and as %steal in mpstat. Run your normal peak load, or a synthetic one, and sample per core:
mpstat -P ALL 5 120On a reserved allocation, steal should stay at or very close to zero on every core, including during the busiest hours of the day on the host. Persistent steal of several percent means the CPU is being shared.
2. Check that repeated benchmarks agree
Run the same CPU-bound benchmark every hour for a day or two, for example sysbench cpu --threads=N --time=60 run with N equal to your vCPU count. Record events per second. On reserved CPU, results cluster tightly; on contended CPU, they swing with the time of day. A spread of a few percent is normal turbo and thermal variation; large drops at regular hours are neighbors.
3. Confirm memory is not ballooned
Check MemTotal in /proc/meminfo matches the quote and stays constant. Check whether a balloon driver is loaded with lsmod | grep balloon; its presence alone is not proof of reclaim, but a falling MemTotal or rising memory pressure in /proc/pressure/memory while your own usage is flat is.
4. Test disk latency, not just throughput
Storage is the resource most often shared even when CPU is not. Use fio with a 4k random read and write test at a queue depth that matches your database, and look at the 99th percentile latency, not the average. Repeat at different times of day.
Your quote states the allocation model in writing. If your measurements show sustained steal or memory reclaim, send us the output and we take it up with the supplier. Our benchmark method describes how we plan to measure plans ourselves; those tests have not been run yet.
What you can specify
| Item | Options we quote | Written in the quote |
|---|---|---|
| vCPU | 2 to 32 reserved vCPU, by supplier availability | CPU model or generation, thread vs core, allocation model |
| Memory | 4 GB to 128 GB, reserved | No ballooning or host overcommit |
| Storage | NVMe-backed local or network block storage | Performance class and any IOPS limit |
| Network | Port speed, monthly transfer, IPv4 count, IPv6 | Overage terms |
| Operating system | Linux LTS images; Windows Server where licensed | Confirmed at quote |
| Backups and snapshots | Optional, schedule and retention chosen by you | Confirmed at quote |
| Management | Self-managed or managed | Scope, if managed |
Reference configurations
| Shape | Reserved vCPU / memory | Storage | Typical fit | Price |
|---|---|---|---|---|
| Steady app | 2 / 8 GB | 100 GB | An application server with latency targets | Price shown at quote |
| Database | 4 / 32 GB | 250 GB, high-IOPS class | PostgreSQL or MySQL with a working set that fits in RAM | Price shown at quote |
| Build server | 8 / 32 GB | 200 GB | CI runners, compilation, container image builds | Price shown at quote |
| Large | 16 / 64 GB | 500 GB | Consolidated services, analytics, real-time media | Price shown at quote |
Use cases
A production database
Databases amplify contention: a short CPU stall holds locks longer, and queued queries pile up. Reserved CPU and memory that is never reclaimed keep the buffer cache warm and response times flat.
Real-time audio, video or game sessions
Media processing works in small time slices. A few milliseconds of steal becomes audible or visible jitter, so consistency matters more than raw speed.
CI and builds
Builds use all cores for minutes at a time, which is exactly when a contended host hurts. Reserved vCPUs make build times predictable, which makes queue planning possible.
Virtual server compared with a VPS, cloud and bare metal
| Question | Standard VPS | Virtual server | Cloud instance | Bare metal |
|---|---|---|---|---|
| CPU | Shared, may be overcommitted | Reserved, not overcommitted | Shared or dedicated class | Whole machine |
| Memory | May be reclaimable | Reserved | Usually reserved | Whole machine |
| Expected steal | Varies with neighbors | Near zero | Depends on class | None (no hypervisor) |
| Flexibility | Resize by plan | Resize by reservation | Resize and scale out | Hardware change |
| Relative cost | Lowest | Higher than VPS | Itemized | Highest per server |
Need several reserved machines on a private network? That is cloud hosting with a dedicated CPU class.
Responsibility matrix
| Task | BroadNet | Supplier | You |
|---|---|---|---|
| Host hardware and hypervisor | - | Owns | - |
| Allocation model stated in writing | Owns | Provides | - |
| Investigating measured steal or reclaim | Owns | Fixes | Sends evidence |
| OS patching, firewall, accounts | - | - | Owns |
| Backups and restore tests | Confirmed at quote | - | Owns |
| Application and data | - | - | Owns |
Support terms and how buying works
The quote fixes the allocation model, CPU generation, storage class, contact routes, staffed hours, severity levels, response targets and renewal terms. General terms are on the support page.
- Share your measurements. Current CPU, steal, memory and disk latency help us size the reservation. The sizing tool and sizing guide help if you are starting fresh.
- Request a quote through the configurator or contact.
- Review the allocation terms alongside supplier, region and price.
- Provision and verify. Run the four checks above in your first week.
Frequently asked questions
Is a virtual server the same as a VDS?
Broadly, yes. "Virtual dedicated server" is the industry term for a virtual machine with dedicated, non-overcommitted resources. We call it a virtual server and write the allocation model into the quote.
What steal time should I expect?
At or very near zero on every core, including at busy times. If you measure persistent steal, send us the mpstat output and we raise it with the supplier.
Does reserved CPU make my server faster?
Not faster than the same CPU uncontended, but consistent. The gain shows at peak times and in tail latency rather than in a single benchmark run on a quiet host.
Is disk I/O reserved too?
Not automatically. Storage performance depends on the class you choose, and any IOPS limit is listed in the quote. Test 99th percentile latency with fio.
Can I add management later?
Yes. Managed hosting can run on top of a virtual server; the scope, change windows and response targets are then added in writing.
Do you publish benchmark results?
Not yet. Our benchmark method is published, but plan tests have not been run. Until then we give you the checks to run on your own server.
Sources
- proc(5): /proc/stat steal field, Linux man-pages
- mpstat(1) manual page, Linux man-pages
- PSI: Pressure Stall Information, Linux kernel documentation
- fio documentation, fio project
Related
Last reviewed . Facts on this page are checked against the sources listed; anything not yet contracted is marked “confirmed at quote”.