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

Basic

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 Basic guest tops out around 62k IOPS before the vCPU itself becomes the bottleneck, not the storage. That is why Basic 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.

High Frequency

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 Basic, 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 High Frequency VM and published the result: roughly double the CPU and disk marks of same-size plans in their comparison, on a replicated network disk.

High Frequency 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 Basic Burst class, straight from the live catalog:

High Frequency 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 5-minute rolling window. Only a VM that averages above its class threshold for the whole window, across two consecutive checks, gets its ceiling lowered, in 10% steps.
• Hot node. If a whole hypervisor runs hot, Burst VMs on it are stepped down, heaviest consumers first.
• Step cooldown. At most one step per 60 seconds. No cliffs.
• Instant restore. The moment the VM goes idle or the node cools down, the ceiling snaps back to 100%. 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 the moment 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 Basic to High Frequency 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.