UptimeUptime Wiki

Uncontended compute (1:1 CPU pool)

Most tenants share CPU: you sell more virtual cores than you own and lean on the fact that they're rarely all busy at once. An uncontended customer refuses that bet. They pay for guaranteed 1:1 CPU -- every virtual core they buy maps to a real core that nobody else can borrow. Their workload never fights for cycles, so their service stays fast no matter how loud the rest of the floor gets.

You don't have to set anything up. The engine keeps a managed "uncontended pool": a set of servers that run 1:1 with no overselling, shared between all your uncontended customers. When one of these tenants needs room, the engine pulls a server into the pool and runs it at 1:1 for you. If the pool has no room and there's no free server to convert, THAT is when you get told to add a host -- a new server auto-joins the pool at 1:1. You never wire it up by hand.

Uncontended is a CPU promise, not a privacy promise. Those pool servers are still SHARED -- several uncontended customers sit on the same box, they just each get real cores that can't be stolen. That's different from a dedicated customer, who wants a whole machine to themselves, and different again from spreading a customer's copies across separate servers for resilience. Three separate ideas: guaranteed CPU, private machine, and spread-out copies.

Detailed explanation

1:1 overcommit on a shared pool

requires_uncontended flips the workload's effective overcommit to 1.0 -- its reserved vCPUs map to physical cores, unaffected by the fleet overcommit dial. Delivery is by ADMISSION, not by a per-host dial the player twiddles: the engine keeps a managed+uncontended L3VNI ("the uncontended pool"), and host_effective_overcommit returns 1.0 for any host admitted to it, so a pool host computes 1:1 capacity everywhere consistently. The pool is SHARED -- multiple uncontended tenants co-locate on its 1:1 hosts.

Auto-managed, auto-expanding

On first placement the engine ensures the pool exists (reusing the customer's own player segment if it already resolves to one, else the single managed pool) and pins the customer to it. When an uncontended VM won't fit, it auto-admits the least-loaded open host -- evacuating its contended tenants and flipping it 1:1 -- then retries, one host at a time up to demand, never converting the last open contended host. Only when it can find NO convertible host does it raise CustomerUnservable / NeedsUncontendedHosts: the fix is to add a host, which auto-joins the pool. This is distinct from requires_dedicated_hosts (private single-tenant host) and from anti_affinity_required (spread replicas across distinct hosts) -- three orthogonal flags, each driving its own mechanism.

On this page