CPU and storage are coupled: a workload that uses more CPU also reads and writes more, and a workload that reads and writes more uses more CPU. The relationship is the lever for sizing. The team that sizes the CPU and the storage independently is going to over-provision one and under-provision the other.
Table of contents
- The relationship
- What the workload does
- How to size
- The trade-offs
- When to oversize
- When to right-size
- FAQ
The relationship
The relationship between CPU and storage is not 1:1; it is workload-dependent. A workload that does a lot of computation (a video encoder, a numerical simulation) uses a lot of CPU and very little storage I/O. A workload that does a lot of I/O (a database, a log shipper) uses a moderate amount of CPU and a lot of storage I/O.
The team that sizes the CPU and the storage independently is going to be wrong about one of them. The fix: size them together, based on the workload’s actual pattern.
What the workload does
The workload pattern is the most important input. The four patterns that cover most workloads:
- CPU-bound. The workload spends most of its time computing. The CPU is the bottleneck. The storage is mostly idle.
- Storage-bound. The workload spends most of its time reading and writing. The storage is the bottleneck. The CPU is mostly idle.
- Memory-bound. The workload spends most of its time waiting for memory. The memory is the bottleneck. The CPU and the storage are mostly idle.
- Network-bound. The workload spends most of its time waiting for the network. The network is the bottleneck. The CPU, the memory, and the storage are mostly idle.
How to size
The sizing rule:
- CPU-bound: right-size the CPU. The storage can be the smallest available tier. The network can be the cheapest available tier.
- Storage-bound: right-size the storage. The CPU can be the smallest available tier. The network can be the cheapest available tier.
- Memory-bound: right-size the memory. The CPU and the storage can be the smallest available tiers. The network can be the cheapest available tier.
- Network-bound: right-size the network. The CPU, the memory, and the storage can be the smallest available tiers.
The trade-offs
The trade-offs the team needs to understand:
- Oversize CPU, undersize storage. The workload is fast until it reads from the storage, and then it is slow. The slow is the storage, not the CPU. The team concludes the CPU is fine, but the storage is the bottleneck.
- Oversize storage, undersize CPU. The workload reads and writes fast, but it cannot keep up with the data. The slow is the CPU, not the storage. The team concludes the storage is fine, but the CPU is the bottleneck.
- Right-size both. The workload is fast. The cost is the right amount. The team has to know the workload’s actual pattern.
When to oversize
The team that should oversize:
- The team that does not know the workload’s pattern. Oversize is the safe default.
- The team that is running a workload with a peak that is 2-3x the average. Oversize for the peak.
- The team that is running a workload with a SLA that requires a 99.99% availability. Oversize for the failure modes.
When to right-size
The team that should right-size:
- The team that knows the workload’s pattern. Right-size is the right answer when the team has the data.
- The team that is running a workload with a predictable load. Right-size for the average, with a buffer for the peak.
- The team that has the engineering time to monitor the workload and adjust the size as the pattern changes.
FAQ
What is the relationship between CPU and storage?
They are coupled. A workload that uses more CPU also reads and writes more, and a workload that reads and writes more uses more CPU. The relationship is workload-dependent.
How do I size CPU and storage together?
Size them based on the workload’s actual pattern. CPU-bound workloads right-size the CPU. Storage-bound workloads right-size the storage. Memory-bound workloads right-size the memory.
What is the most common sizing mistake?
Sizing the CPU and the storage independently. The team that sizes one without the other is going to over-provision one and under-provision the other.
When should I oversize?
When the team does not know the workload’s pattern, when the workload has a peak that is 2-3x the average, or when the workload has a SLA that requires high availability.
When should I right-size?
When the team knows the workload’s pattern, when the workload has a predictable load, or when the team has the engineering time to monitor and adjust.
If you are sizing a server tier for a new project, the RunxBuild hosting calculator is the place to model the line items. The CPU, the memory, the storage, the I/O - each one is a separate number, and the team’s mental model for the platform is the sum of those numbers. The RunxBuild dashboard is where the team sees the actual usage in one place.