Compute classes

Every VM class on ServersCamp comes in two CPU flavours: burst (shared vCPU, throttleable under contention) and dedicated (pinned physical cores, never throttled). Same memory, same disk, same network. The difference is how the cores are shared with neighbours, and how predictable the CPU is under load.

This page explains what each mode actually means, how the throttle works, and when each one is the right call.

At a glance

Burst instances

Burst VMs share physical cores with other burst VMs on the same hypervisor. Each VM is configured with a CPU corridor:

• cpu_min: guaranteed share. You always get at least this much, regardless of what neighbours are doing.
• cpu_max: burst ceiling. When the host has spare cycles, your VM can go all the way up to 100% of its vCPU count.

Most workloads sit comfortably at low single-digit percent and occasionally spike. The shared model lets you pay for the average while still having headroom for the spikes. Concrete cpu_min/cpu_max values per class:

How throttling works (CPU Guard)

If your VM sustains very high CPU for a long time, or if the host as a whole gets hot, our CPU Guard worker steps in and lowers cpu_max in 10% increments. The rules:

• Sustained load. The worker looks at a 5-minute rolling window. If the VM averages above the class-relative threshold for that whole window across two consecutive checks, cpu_max drops by 10%.
• Hot node. If the whole hypervisor is overloaded, every burst VM on the node loses 10% from its ceiling, oldest-offending first.
• Step cooldown. No more than one step every 60 seconds, so changes are gentle, not cliff-like.
• Instant restore. When the VM goes idle, or the node cools down, the ceiling is restored back to cpu_max immediately. There is no penalty box.
• Floor. The throttle never drops below cpu_min. Your guaranteed share is, well, guaranteed.

In practice this means a 30-second build spike never triggers anything. A runaway process pegging 100% for ten minutes will get gently nudged down. Most users never notice CPU Guard exists.

When burst is the right call

• Web apps and APIs with bursty traffic and idle periods between requests.
• CI runners and build boxes that work hard for a minute, then sit at 0%.
• Development, staging, demos: anywhere you want a real VM but don't need production-grade CPU SLA.
• Background workers with light average load and occasional batches.
• Anything where the cost saving over dedicated is worth a small chance of throttling during sustained 100% CPU.

Dedicated instances

Dedicated VMs get physical cores pinned to them. No other VM is scheduled on those cores. The hypervisor still runs a thin kernel for IO and management, but compute capacity is yours.

Consequences:

• No noisy neighbours. Performance is the same on a quiet hypervisor as on a packed one. Latency and tail latency are predictable.
• No throttle, ever. CPU Guard does not act on dedicated VMs. You can sit at 100% CPU forever and nothing happens.
• Same vCPU count as the equivalent burst class. A 4 vCPU dedicated class gives you 4 real cores, not 4 shared ones.

The dedicated catalog mirrors the burst shapes one-for-one. All sizes run with cpu_min = cpu_max = 100%, so the throttle floor and ceiling are identical:

Same rule as with burst: sizes above dedicated-l are catalog-defined and rolled out on request.

When dedicated is the right call

• Production databases. PostgreSQL, MySQL, Redis: anywhere a tail-latency hiccup is a real problem.
• Latency-sensitive services: real-time APIs, game servers, financial workloads.
• Steady-state batch processing where the CPU sits at 80–100% for hours.
• Anywhere you've already hit the burst throttle in production and want the issue to go away permanently.
• Compliance or SLA reasons that require deterministic compute.

Switching classes

You can change a VM's class at any time, in either direction:

1. Open the VM in the cabinet.
2. In the More menu pick Resize.
3. Pick the target class and confirm.

Two outcomes depending on what changes:

• Mode toggle only (burst ↔ dedicated, same vCPU and memory): applied live. No downtime. The throttle just stops or starts being a thing on the next CPU Guard tick.
• Size change (different vCPU or memory): the VM is stopped, patched, and started. Typical downtime 10-60 seconds. You can choose between graceful shutdown (ACPI signal, waits up to 60s) and force stop (instant qemu kill) in the resize dialog.

Disk, IP addresses, and network attachments are preserved across resize. CLI and Terraform support is on the roadmap.

Rule of thumb

If you're not sure, start on burst and watch the throttle indicator in the cabinet under VM details → CPU. If it never trips for a week, you have your answer. If it trips often during normal traffic, switch the class to dedicated.