A choice for sustained processing
Evaluate applications whose demand extends beyond occasional CPU spikes. Observe a representative operating period instead of sizing from one busy moment.
COMPUTE / DEDICATED CPU
Plan processor capacity for long-running tasks, demanding APIs and build pipelines. Evaluate Dedicated CPU against the parallelism of your workload, its memory needs and its completion targets, instead of choosing by core count alone.
01 / Overview
Dedicated CPU is a virtual server model centred on allocated processor resources. It is different from using an entire physical server. Consider this family when applications compute for much of the day, worker queues grow or processing times affect the service you deliver to customers.
Adding vCPUs does not accelerate every application proportionally. Single-threaded tasks, database locks and storage waits need separate investigation. Test the available plan specifications with a representative workload to balance processing capacity, memory and data access.
Evaluate applications whose demand extends beyond occasional CPU spikes. Observe a representative operating period instead of sizing from one busy moment.
Track execution time, concurrent workers and queue waiting time together for builds and background jobs. Those measurements describe what extra capacity needs to achieve.
Compare Shared CPU, Dedicated CPU and Bare Metal against workload and control requirements. A CPU allocation model does not imply ownership of an entire physical server.
02 / Architecture
Illustrative workflow: jobs execute on processor resources. Available parallelism and access to data both influence the outcome.
Selection guide03 / Selection guide
| Consider | How to decide | Why it matters |
|---|---|---|
| Duration of demand | Record how long CPU demand stays high during a normal operating cycle. | Brief bursts and sustained processing suggest different capacity decisions. |
| Parallel execution | Test whether the application can actually use additional cores. | More vCPUs cannot automatically speed up serial code. |
| Memory and storage | Monitor memory pressure and storage latency during CPU testing. | Adding processor capacity may leave the original bottleneck untouched. |
| Operating budget | Include storage, traffic and backup alongside compute costs. | A useful comparison reflects the complete operating requirement. |
04 / Use cases
Measure processing per request and latency during peak periods. Separate CPU demand from time spent waiting for databases or external services.
Run a representative build at different concurrency levels. Include source downloads and artifact storage in the overall pipeline rather than timing compilation alone.
Plan report generation and data transformation around completion time, queue depth and the safe retry of failed work.
Plans & pricing
| Host | CPU | RAM | Storage | Bandwidth | Monthly price (USD) |
|---|---|---|---|---|---|
|
|
2
|
4 GB
|
80 GB
|
Includes 6TB bandwidth
|
16.00$Est. hourly: 0.022222
|
| Host | CPU | RAM | Storage | Bandwidth | Monthly price (USD) |
|---|---|---|---|---|---|
|
|
4
|
8 GB
|
160 GB
|
Includes 7TB bandwidth
|
28.00$Est. hourly: 0.038889
|
| Host | CPU | RAM | Storage | Bandwidth | Monthly price (USD) |
|---|---|---|---|---|---|
|
|
8
|
16 GB
|
320 GB
|
Includes 8TB bandwidth
|
49.00$Est. hourly: 0.068056
|
| Host | CPU | RAM | Storage | Bandwidth | Monthly price (USD) |
|---|---|---|---|---|---|
|
|
16
|
32 GB
|
640 GB
|
Includes 9TB bandwidth
|
94.00$Est. hourly: 0.130556
|
Hourly estimates divide the monthly price by 30 days (720 hours).
Review the current configuration, price and order terms before selecting a service.
Choose a location to measure your connection latency.
05 / From planning to operation
Capture job duration, peak demand and errors. Define the performance problem you want the infrastructure change to address.
Use realistic data to test CPU demand and concurrency. Record software and configuration differences between the test and production environments.
Plan data transfer, access changes and maintenance time. Keep a tested way to return to the previous environment before switching workloads.
Repeat the same workload after the change. Assess processing time alongside cost, memory consumption and error behaviour.
No. Dedicated CPU describes a CPU resource model within a virtual server. Bare Metal addresses requirements at the physical-server level, with different control and operating considerations.
They may help if the work can run in parallel. Single-threaded execution, locking, data access and external dependencies can limit the benefit of additional cores.
It is worth evaluating for CPU-heavy database work. Working-set size, query design and storage behaviour still matter; compare High Memory when memory is the main requirement.
Check the current plans and transition options. Back up data, test the application and schedule maintenance; do not assume every change can happen without interruption.
Connect product decisions with installation, configuration and operating knowledge.
These references explain the technical concepts discussed on this page. Available configurations and service scope are defined by FibaCloud product and order information.
FIBACLOUD / Dedicated CPU
Tell us about your application, expected usage and operating requirements. Let’s bring the resource choices together.