Compute

A ServersCamp VM is defined by two independent choices: the hardware generation (which silicon your cores run on) and the compute profile (how the scheduler treats your cores when a host is busy). Everything else, storage fabric, network, security, is identical across all of them.

This page explains both axes with the measured numbers behind them: what the generations actually score from inside a guest, how throttling really works, and how to pick.

At a glance

Hardware generations

Standard

Proven dual-socket Xeon Scalable servers. Inside a 4 vCPU / 8 GB guest, Geekbench 6 lands at 1094 single-core / 3358 multi-core, squarely in the advertised 1000-1200 band. That is comfortable territory for the vast majority of workloads: web servers, application backends, queues, CI, anything that scales out rather than up.

One consequence of the older core is a hard ceiling on I/O: pushing 4k random reads flat out, a Standard guest tops out around 62k IOPS before the vCPU itself becomes the bottleneck, not the storage. That is why Standard VMs cap disk limits at 50k IOPS / 1 GB/s and storage tiers above 3 are not offered on this generation: a number the guest cannot physically reach is not a number worth selling.

Performance

AMD EPYC 4565P: server silicon built from desktop-flagship cores, clocking to 5.7 GHz. The same 4 vCPU / 8 GB shape scores 3336 single-core / 9194 multi-core from inside a guest, and that run was on the cheaper Burst profile, not a tuned lab box. Per core, that is 3.05x Standard, and faster than most machines your code has ever run on, laptops included.

Third-party confirmation: vpsbenchmarks.com ran their standard yabs suite on a 2 vCPU / 4 GB Performance VM and published the result: roughly double the CPU and disk marks of same-size plans in their comparison, on a replicated network disk.

Performance guests carry no disk clamp: the hardware digests the upper storage tiers, verified past 300k IOPS in-guest. If your workload is a transactional database, a compiler, a single-threaded game loop or a latency-bound API, this is the generation the arithmetic favors.

Burst vs Sustained

Hosts are deliberately not run at the redline, so most of the time both profiles behave identically: full speed. The profile decides who yields in the moments that a host is genuinely saturated.

• Sustained keeps top scheduling priority at all times. Full core speed under any host load, around the clock. CPU Guard never acts on Sustained VMs.
• Burst runs at full speed by default, and is first in line to be limited when a host runs hot. Each Burst class carries a CPU corridor: a guaranteed floor (cpu_min) it can never be pushed below, and a ceiling of 100%.

The corridor floors per Standard Burst class, straight from the live catalog:

Performance offers the same two profiles with the same semantics; the current per-class corridor values are always visible in the wizard and via GET /api/v1/vm-classes.

How throttling works (CPU Guard)

Burst limiting is done by a worker called CPU Guard, and its rules are deliberately gentle:

• Sustained load. It watches a 15-minute rolling window, so idle time inside it dilutes short spikes. Only a VM whose average stays above its guaranteed share across two consecutive checks gets its ceiling lowered, first to about that average and then by one 10% step a minute while the load goes on.
• New servers. For the first 45 minutes after creation the sustained-load rule leaves a VM alone, so the OS install and first setup run at full speed.
• Hot node. If a whole hypervisor runs hot, the Burst VMs on it drop to their guaranteed share until it cools down.
• Restore. Once the 15-minute average falls to half of the current ceiling, or to the guaranteed share, the ceiling goes back to 100% in one step. There is no penalty period.
• Floor. The throttle can never go below the class floor. The guaranteed share is guaranteed.

In practice a 30-second build spike triggers nothing. A runaway process pegging 100% for ten minutes gets nudged down and bounces back once it calms. Most users never find out CPU Guard exists.

Resizing

VMs resize from the panel: More → Resize.

• Profile switch (Burst ↔ Sustained, same size): applied live, no downtime.
• Size change (different vCPU or RAM): the VM is stopped, reshaped and started. Typical downtime is 10-60 seconds; you choose graceful shutdown or force stop in the dialog.
• Generation is fixed. Resizes stay within a hardware generation: moving a workload from Standard to Performance means creating a VM on the new generation and moving the data (a snapshot makes that painless).

Disk, IP addresses and network attachments are preserved across resizes.

Which one to pick

Prices for every combination, with full example bills: Compute pricing. How the disks behave underneath: Block Storage docs.