Cloud server performance bottlenecks are resources or dependencies that limit latency, throughput, or stability by forcing useful work to wait.
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 diagnostic question is therefore: where does the affected work wait, and does that wait control an outcome users or operators care about?
Raff Technologies supports 3,000+ customers and 15,000+ VMs. In Raff infrastructure reviews, a recurring diagnostic mistake is reacting to the highest utilization graph before correlating it with request latency, queue growth, failed jobs, or service restarts.
This guide is the diagnostic branch of Raff’s VM sizing and performance content. Start with How to Choose the Right VM Size for Your Workload for initial sizing, then use this framework when a running server becomes slow, unstable, or difficult to scale.
Cloud server performance bottlenecks are waiting problems
A performance bottleneck is the resource, dependency, or serialized step that controls how quickly the workload can complete useful work.
That distinction matters because utilization alone is ambiguous. High utilization can mean a resource is being used efficiently. Low utilization can hide a blocked workload. The stronger diagnosis combines impact with pressure or wait evidence.
Linux Pressure Stall Information (PSI) is useful here because it reports time tasks lose while waiting for CPU, memory, or I/O resources. It exposes those signals through /proc/pressure/cpu, /proc/pressure/memory, and /proc/pressure/io on supported systems.
A practical bottleneck model has four layers:
- Impact: What is slow, failing, or backing up?
- Wait: Where is work spending time instead of progressing?
- Cause: Why is that resource or dependency constrained?
- Decision: Should the team optimize, resize, separate, or scale?
Raff supports 3,000+ customers and 15,000+ VMs, but the correct resize decision still begins with measured workload pressure.
The same model works for an API, database, CI runner, worker queue, self-hosted application, or mixed production VM.
The diagnostic framework connects symptoms to constrained resources
Start from the affected workload, not from a dashboard panel.
| Symptom | Evidence to inspect | Likely constraint | Better first decision |
|---|---|---|---|
| p95/p99 latency rises under load | CPU pressure, run queue, traces, DB time | CPU, lock, or dependency | Find the dominant wait before resizing |
| Queue age keeps growing | CPU, worker throughput, downstream latency | Compute or downstream capacity | Add useful concurrency or remove downstream limit |
| Processes restart or disappear | Available memory, swap, OOM events | Memory pressure or leak | Reduce demand, fix leak, or add RAM |
| Database slows during writes | Query time, locks, I/O latency, checkpoints | Query, lock, memory, or storage | Diagnose the database path first |
| Uploads or downloads are slow | RTT, loss, retransmits, throughput | Network path or application limit | Test path before adding compute |
| Deployments destabilize the server | CPU, RAM, I/O during deploy window | Missing operating headroom | Resize or change deployment behavior |
| Workers hurt web latency | CPU, memory, I/O, queue activity | Role contention | Limit or separate workers |
| Performance drops after a release | Version marker, traces, DB queries, errors | Application regression | Roll back or isolate the change |
Use at least one workload-impact signal and one resource/dependency signal. Examples:
- p99 latency rises and CPU PSI rises;
- queue age grows and worker CPU stays saturated;
- service restarts occur and OOM events appear;
- database time rises and storage latency increases;
- request duration rises and one external API dominates traces.
In Raff infrastructure work, this correlation is more useful than a universal CPU or RAM percentage. A fixed threshold can trigger too early for a batch workload and too late for a latency-sensitive service.
A healthy baseline makes incident data useful
Compare equivalent workload periods. A normal weekday, backup window, deployment, campaign, and batch job may have different healthy profiles.
Record at least:
- request or job latency;
- traffic and concurrency;
- queue depth or oldest-job age;
- CPU activity and pressure;
- available memory, swap, and OOM events;
- storage latency and throughput;
- network latency, throughput, loss, and retransmissions;
- database query and lock time;
- external dependency duration.
Percentiles are usually more useful than averages for user-facing latency because a good average can hide a small group of very slow requests.
CPU and memory bottlenecks require different fixes
CPU and memory are often grouped together as “the VM is too small,” but their failure patterns are different.
CPU pressure appears when runnable work cannot progress fast enough
CPU becomes the constraint 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 package update, deployment, cache warm-up, or brief traffic burst can consume available CPU without creating a real service problem.
Add vCPU when the workload can use more parallel compute and the outcome 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 the narrower core-count decision, use 2 vCPU vs 4 vCPU Cloud VMs. For CPU allocation, use Shared vs Dedicated vCPU.
Memory pressure appears when the working set no longer fits safely
Linux uses otherwise idle RAM for useful cache, so “used memory” alone is not a reliable sizing verdict.
Stronger memory signals include:
- 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;
- growing process memory that does not return after load falls;
- database or cache behavior degrading as memory pressure rises.
Separate three cases:
| Pattern | Meaning | Better response |
|---|---|---|
| Stable working set is too large | Legitimate capacity demand | Add RAM |
| Memory grows without stabilizing | Leak or unbounded behavior | Fix application/configuration |
| Several services compete for RAM | Role contention | Add memory or separate services |
Sustained swap can turn a memory shortage into a storage-latency problem. More CPU does not solve that chain.
Use HiMem VMs Explained when the workload needs more RAM per vCPU.
Disk I/O and network bottlenecks need path-level evidence
Storage and network problems are easy to misdiagnose because both can leave CPU relatively idle while requests remain slow.
Disk capacity and disk performance are separate constraints
A filesystem can have free space and still suffer high I/O latency. It can also provide fast I/O and fail because capacity or inodes are exhausted.
Inspect storage across four dimensions:
| Dimension | Evidence |
|---|---|
| Capacity | Free space, inode use, growth rate, retention |
| Latency | Read/write completion time |
| Throughput | Bytes transferred per second |
| Queueing | Outstanding operations and wait time |
Databases, write-heavy logs, backups, analytics, file processing, and multi-service VMs can create storage contention.
High I/O wait is supporting evidence, not a complete diagnosis. Correlate it with device latency, queueing, database time, or job duration. Red Hat’s performance guidance similarly treats vmstat as a starting signal and iostat as a tool for identifying the responsible block device when I/O is implicated.
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;
- add or expand storage when capacity is the actual constraint.
Network bottlenecks include latency, loss, and dependency behavior
Bandwidth is only one network dimension. 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, remote dependency, or client geography problem.
Raff Cloud Servers include a 3 Gbps public port and unmetered bandwidth, so network diagnosis should still focus on measured path behavior.
Current Raff pricing documentation also lists private networking as included, which can keep internal service traffic off the public path where the architecture requires it.
Databases and application behavior can imitate infrastructure bottlenecks
A larger VM cannot repair every slow application.
Database and application behavior frequently create symptoms that look like CPU, memory, disk, or network shortages.
| Application or database pattern | Visible infrastructure symptom |
|---|---|
| Missing database index | High query time and storage activity |
| Lock contention | Slow requests with moderate VM utilization |
| Synchronous external API | Low CPU with long request latency |
| Unbounded worker concurrency | CPU, RAM, and I/O contention together |
| Excessive retries | Network and downstream amplification |
| Excessive logging | Storage growth and write latency |
| Cache miss storm | Database and network pressure |
| Memory leak | Rising RAM usage and eventual OOM |
| Serial processing path | One busy thread with idle vCPUs |
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. Likewise, moving from 2 vCPU to 4 vCPU can expose a downstream bottleneck without improving 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.
The decision is optimize, resize, separate, or scale
Once the bottleneck is identified, choose the smallest architectural change that addresses it.
| Evidence | Better move | Why |
|---|---|---|
| Inefficient code/query dominates | Optimize | Capacity would hide avoidable work |
| One VM resource is consistently constrained | Resize vertically | One server still fits the operating model |
| App and database compete repeatedly | Separate roles | Independent resource and recovery boundaries help |
| Workers harm user-facing traffic | Limit or separate workers | Protect request-path capacity |
| Stateless app tier reaches repeatable capacity | Scale horizontally | Traffic can be distributed across nodes |
| Short bursts exceed headroom | Buffer, rate-limit, resize, or scale | Burst handling is the actual requirement |
| External dependency dominates | Cache, queue, or redesign carefully | Local compute does not remove remote wait |
| No clear correlation exists | Improve observability | Architecture changes would be guesswork |
Vertical resizing is usually the lowest-complexity move when one VM still provides the right 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 the additional concurrency.
Use Horizontal vs Vertical Scaling after diagnosis identifies capacity as the problem rather than an application defect.
Validate the change against the original symptom
Performance work becomes unreliable when several variables change at once.
For a controlled change:
- record the affected workload and healthy baseline;
- select one bottleneck hypothesis;
- change one variable where practical;
- repeat an equivalent workload;
- compare latency, throughput, errors, queueing, and resource pressure;
- check whether the bottleneck moved downstream.
A successful change improves the workload outcome. A prettier utilization graph by itself is not success.
Raff supports diagnosis before capacity changes
Raff Cloud Servers give teams full server access, NVMe storage, monitoring, shared-vCPU General Purpose options, dedicated-vCPU CPU-Optimized options, and a resize path for CPU, RAM, and storage. Current public pricing documentation lists a 3 Gbps public port, unmetered bandwidth, private networking, DDoS protection, browser console/SSH, API/Terraform access, and live monitoring as included Cloud Server capabilities.
That supports an evidence-first workflow:
- inspect operating-system and application behavior;
- identify whether CPU, memory, storage, network, database, or another dependency controls the outcome;
- optimize application behavior when capacity is not the real problem;
- resize when the current VM resource profile is genuinely constrained;
- use Volumes when storage needs an independent capacity boundary;
- separate workers or databases when resource contention becomes repeatable;
- move toward horizontal scaling only after the application and data paths can support it.
Raff does not remove the need to measure. A 3 Gbps port does not guarantee an external API will be fast, and NVMe storage does not make an inefficient query cheap. Platform capacity and workload design must be diagnosed separately.
For current VM sizes and plan details, use Raff General Purpose VM Plans and verify the live pricing page before deployment.
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.
CPU pressure points toward more compute only when runnable work is delayed. Memory pressure points toward more RAM only when the working set cannot remain resident safely. Storage and network require path-level latency, throughput, and queue evidence. Databases 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 the broader sizing framework, or continue with Horizontal vs Vertical Scaling when the diagnosis shows that additional capacity is the correct next move.