Cloud Server Bottlenecks: CPU, Memory, Disk & Network

A cloud server bottleneck is the resource, dependency, or serialized step that limits latency, throughput, or stability by forcing useful work to wait. The bottleneck may be CPU, memory, disk I/O, network, a database, or an external service.

The busiest metric is not automatically the bottleneck. A server can run at high CPU and still meet every latency target, while another can show moderate CPU and feel slow because requests are waiting on memory reclaim, storage, database locks, DNS, or an external API.

The practical diagnostic question is: where is the affected work waiting, and does that wait control an outcome users or operators care about?

Raff Technologies supports 3,000+ customers and 15,000+ VMs. In infrastructure reviews, a recurring mistake is reacting to the highest utilization graph before correlating it with request latency, queue growth, failed jobs, or service restarts.

How to identify a server bottleneck

Use this five-step sequence before resizing a slow cloud server:

1. Define the symptom. Is the problem slow requests, growing queues, failed jobs, restarts, long builds, or low throughput?
2. Measure where work waits. Check CPU pressure, memory pressure, disk latency, network latency, database time, and external dependencies.
3. Correlate pressure with impact. A metric matters when it rises at the same time as the workload problem.
4. Change one variable where practical. Optimize, resize, separate, or scale based on the identified constraint.
5. Repeat an equivalent workload. Confirm the original symptom improves and check whether the bottleneck moved downstream.

A useful rule is impact + wait evidence > utilization alone.

Linux Pressure Stall Information (PSI) can help because it reports time tasks lose while waiting for CPU, memory, or I/O resources through /proc/pressure/cpu, /proc/pressure/memory, and /proc/pressure/io on supported systems.

CPU bottleneck: look for sustained compute pressure plus impact

A CPU bottleneck exists when useful compute demand exceeds the processing capacity available within the workload's timing requirement.

Typical signals include:

• sustained CPU pressure during the affected period;
• runnable work accumulating;
• p95/p99 latency rising with CPU demand;
• queue or worker backlog growing while CPU remains busy;
• builds or tests taking longer under equivalent work;
• one thread saturating while machine-wide CPU looks moderate.

Short CPU spikes are not enough. A deployment, cache warm-up, package update, or brief traffic burst can consume all available CPU without creating a persistent server performance problem.

Add vCPU when the workload can use more parallel compute and the result improves. Optimize code when profiling reveals avoidable CPU work. Evaluate dedicated compute when sustained CPU timing consistency matters more than additional shared-vCPU count.

For that narrower choice, see 2 vCPU vs 4 vCPU Cloud VMs and Shared CPU vs Dedicated CPU.

Memory bottleneck: look for pressure, swap, OOM, and restarts

A memory bottleneck appears when the workload's active working set no longer fits safely in RAM.

Linux uses otherwise idle memory for useful cache, so raw “used RAM” percentage is not enough. Stronger evidence includes:

• low available memory during normal peaks;
• repeated swap-in and swap-out activity;
• memory PSI or reclaim stalls;
• out-of-memory events;
• container or process restarts;
• process memory that keeps growing after load falls;
• database or cache behavior degrading as memory pressure rises.

Separate three patterns:

Sustained swap can turn a memory shortage into a disk I/O problem. More CPU does not solve that chain.

Use High Memory VMs (HiMem) when the workload needs more RAM per vCPU.

Disk bottleneck: separate capacity from I/O performance

A disk bottleneck can exist even when a filesystem still has free space. Disk capacity and disk performance are separate constraints.

Inspect storage across four dimensions:

Databases, write-heavy logs, backups, analytics, file processing, and multiple services sharing one VM can all create disk I/O contention.

High I/O wait is supporting evidence, not a complete diagnosis. Correlate it with device latency, queueing, database time, or job duration. When I/O is implicated, tools such as iostat, vmstat, database metrics, and application traces can help locate the responsible path.

Common responses include:

• fix inefficient queries or indexes;
• reduce unnecessary logging and temporary writes;
• move uploads or archives away from the application disk;
• change backup timing;
• separate application and database storage paths;
• expand storage when capacity is genuinely the constraint.

Raff Volumes provide a separate storage boundary at $0.08/GB-month when persistent data should not depend only on a VM's local disk. See Raff Volumes.

Network bottleneck: bandwidth is only one part of the path

A network bottleneck can come from bandwidth, latency, loss, retransmissions, DNS, TLS setup, a proxy, geography, or an external service.

Inspect:

• round-trip time;
• packet loss and retransmissions;
• achieved throughput;
• DNS lookup time;
• TLS and connection-establishment time;
• proxy or load-balancer timing;
• external API duration;
• application upload/download limits.

Test each relevant path separately: user-to-application, application-to-database, service-to-service, and application-to-external-provider. This distinguishes a slow server from a slow route or remote dependency.

Raff Cloud Servers currently use a 3 Gbps public connection with unmetered VM traffic and no VM egress fee. That removes a transfer-metering concern for VM traffic, but it does not guarantee every remote route or third-party dependency will be fast. Network diagnosis still requires measured path behavior.

Private networking through Raff VPC is free and can keep internal service traffic off the public path when the architecture requires it.

Database and application bottlenecks can look like infrastructure problems

A larger VM cannot repair every slow application.

Review database query duration, lock time, connection behavior, cache effectiveness, checkpoint/write activity, and backup traffic beside host metrics.

Adding application servers can make a database bottleneck worse by increasing concurrency against the same constrained data layer. Moving from 2 vCPU to 4 vCPU can expose a downstream bottleneck without reducing total request latency.

Use Application Observability for Small Teams when metrics, logs, and traces need to be connected across one user request or background job.

Optimize, resize, separate, or scale based on the bottleneck

Once the constraint is identified, choose the smallest change that directly addresses it.

Vertical resizing is usually the lowest-complexity move when one VM still provides the correct deployment and recovery boundary. Separation becomes useful when roles need different scaling, deployment, security, or recovery behavior. Horizontal scaling becomes useful when the application can distribute traffic and the data layer can support additional concurrency.

Use Horizontal vs Vertical Scaling after diagnosis shows capacity is the actual problem.

Raff VM options for CPU, memory, and storage constraints

Current September 2026 Raff VM reference points include:

General Purpose uses shared vCPU. CPU-Optimized uses dedicated compute. Raff supports hourly pay-as-you-go VM usage alongside monthly, yearly, and 24-month billing terms.

The pricing table should be used only after diagnosis. Buying dedicated CPU for a memory leak or adding RAM for a disk bottleneck increases cost without addressing the root cause.

For current plan details, use Raff Cloud Servers, Raff General Purpose VM Plans, and the live pricing page.

Validate the fix against the original performance issue

Performance work becomes unreliable when several variables change at once.

For a controlled change:

1. record the affected workload and healthy baseline;
2. select one bottleneck hypothesis;
3. change one variable where practical;
4. repeat an equivalent workload;
5. compare latency, throughput, errors, queueing, and resource pressure;
6. check whether the bottleneck moved downstream.

A successful change improves the workload outcome. A prettier utilization graph by itself is not success.

The bottleneck is the constraint that controls the workload outcome

Cloud server performance diagnosis is most reliable when it begins with a real symptom and follows the wait path to its cause.

A CPU bottleneck points toward more compute only when runnable work is delayed. A memory bottleneck points toward more RAM when the working set cannot remain resident safely. Disk and network bottlenecks require path-level latency, throughput, and queue evidence. Database and application dependencies must be checked before infrastructure is blamed.

The final decision should be proportionate: optimize unnecessary work, resize a constrained VM, separate roles that should no longer compete, or scale a stateless service when one node has reached a repeatable capacity limit.

Return to How to Choose the Right VM Size for Your Workload for initial sizing, or continue with Cloud VM Types & Machine Classes when the constrained resource points toward a different VM profile.

Sources

• Linux Kernel: Pressure Stall Information
• Linux Kernel: Memory Management
• Red Hat Enterprise Linux 9: Monitoring and Managing System Status and Performance
• Raff Pricing
• Raff Cloud Servers