Vloxt field guide
Shared CPU vs Dedicated CPU: which workload needs which?
Understand the practical difference between shared and dedicated CPU servers and when predictable allocation is worth it.
Should this workload use Shared CPU or Dedicated CPU?
Use Shared CPU for general websites, development, small services, and workloads with variable demand. Use Dedicated CPU when compute is sustained, latency variance matters, or a busy database or worker needs predictable allocation. The deciding factor is workload behavior, not company size.
Assumptions
- Shared and Dedicated CPU are Vloxt product allocation categories, not universal industry specifications
- No plan label guarantees application performance
- The workload can be tested under representative demand
Definitions
- Contention
- Multiple workloads seek access to a finite resource at the same time.
- CPU allocation
- The scheduling or capacity boundary made available to a workload.
- Tail latency
- Slower responses near the high end of the observed response-time distribution.
Start here when CPU variation is acceptable.
Use when predictable allocation matters.
Use only when software and memory fit the GPU.
Use when host isolation justifies the commitment.
Decision table
| Observed situation | Starting decision | Evidence before committing |
|---|---|---|
| Idle or bursty most of the time | Shared CPU | Observe variance during peak periods |
| Sustained CPU work | Dedicated CPU | Check utilization and queueing under full demand |
| Latency variance has material user impact | Dedicated CPU | Measure tail latency before and after |
| CPU is not the bottleneck | Do not upgrade CPU first | Inspect memory, storage, database, and network |
What Shared CPU is good at
Shared CPU offers a practical balance for workloads that are idle part of the time or can tolerate some variation. It is often the right first deployment for websites, internal tools, prototypes, and modest APIs.
What Dedicated CPU changes
Dedicated CPU gives the workload a more predictable compute allocation. That matters for sustained processing, busy application workers, latency-sensitive services, and databases where variable CPU access becomes visible to users.
When to move
Move when measurement shows sustained CPU contention or performance variance—not simply because the project reached production. Memory, storage, database design, and network distance may be the actual constraint.
A practical selection rule
Start shared when the workload is uncertain and failure cost is modest. Start dedicated when the workload is known to remain CPU-bound or consistent response time is part of the product experience.
Primary sources and further reading
- Linux kernel documentation: Control Group v2 CPU controller
- NIST SP 500-322: Evaluation of Cloud Computing Services
These sources support the general technical reasoning stated above. They do not verify Vloxt performance or the availability of a specific configuration.
Keeping this guide current
General guidance is reviewed separately from changing plan and location availability. Check the server catalogue for options available today.
We review this guide again when: Review when Vloxt changes the meaning of a CPU family or publishes new allocation evidence.
Ready to test the decision against the current catalogue?
Compare active configurations, then validate the selected shape with representative workload evidence.
Compare current servers