VPS Throttled? (2026) Identify CPU, Disk & Network Limits

When a VPS slows down, most people's first reaction is the same:

The CPU isn't enough
The machine is junk
The provider is overselling
Should I upgrade the specs right away?

The problem is that a slow VPS doesn't necessarily mean "resources are genuinely maxed out."

Sometimes what you're seeing isn't normal saturation, but another, harder-to-diagnose situation: throttling (being limited, speed-capped, or stuck at some ceiling).

For example:

The CPU can spike very high at first, then suddenly drops to a fixed level
No matter how much pressure you apply in disk tests, IOPS just won't go up
The network is rated at 1Gbps, but iperf3 always gets stuck at some neat number
The workload is light, yet latency suddenly worsens, and monitoring shows no obvious CPU saturation

The trickiest part of these problems is:

If you misdiagnose throttling as ordinary performance shortfall, you'll waste a lot of time and money in the wrong direction.

This article is dedicated to clarifying this: how to distinguish "genuinely maxed out" from "throttled by the platform or host layer," and how to look at each of the CPU, disk, and network layers.

1. The Conclusion First: Distinguish Throttling from Normal Saturation

Many troubleshooting efforts go off track from the start because these two situations get conflated.

Situation	What you're actually dealing with
Normal Saturation	Your workload genuinely uses up the resources
Throttling (rate limiting/restriction)	The platform, quotas, credits, QoS, or host layer caps you at some ceiling

The most intuitive difference is:

Normal saturation: resource usage rises with load and approaches the bottleneck linearly
Throttling: performance suddenly "hits a wall" near some threshold and shows a very neat ceiling

One-sentence test

The harder you push your workload, the more the resource metrics rise in tandem, eventually maxing out → more like normal saturation
Your workload wants to go higher, but performance is stuck at a fixed value → more like throttling

This is also the core of the whole article:

First prove you're being limited, then decide whether to upgrade, migrate, or complain to the provider.

2. When Are You Most Likely to Suspect "Not Slow, but Throttled"

The following signals are worth suspecting throttling first:

1. Performance drops to a very neat number

For example:

The CPU stays stuck at some fixed baseline for a long time
Disk IOPS always stops at roughly the same ceiling
Network throughput stays stuck at some fixed tier for a long time

"Neatness" itself is a very strong signal.

2. Fast at first, then suddenly slow after running a while

This looks a lot like the behavior after credits run out:

There's burst up front
Then it's pushed back down to baseline

3. The workload isn't obviously heavy, but latency starts to degrade

For example:

CPU usage doesn't look high
But response times start to jitter
Queues get longer
The system feels noticeably laggy

At this point you can't just stare at %cpu; you need to look at steal, iowait, credits, and throughput ceilings.

4. Multiple tests all hit the same ceiling

Normal jitter won't be this neat every time. Repeatedly hitting the same ceiling usually means the limit is "rule-based."

3. The CPU Layer: How to Tell Whether It's Insufficient Compute or CPU Throttling

CPU is the most common layer and the easiest to misjudge.

First look at `steal time`

In virtualized VPS scenarios, steal time is a very key signal.

It means:

Your virtual CPU wanted to run
But the host machine gave the time slice to another VM

This usually means host-layer contention, not your program maxing out the CPU itself.

How to look

top
vmstat 1
mpstat -P ALL 1

Focus on:

st / %st

How to interpret

%st close to 0: usually normal
%st persistently and noticeably high: means you're waiting for the host to give up CPU

If your workload isn't heavy but %st stays high, this isn't something "optimizing your code" can fully solve.

Then look at burst / credits-type instances

Machines like AWS T series and Azure B series aren't "always at full speed" by design; instead they:

Accumulate credits normally
Burst when needed
Return to baseline once credits run out

The most typical misjudgment here is:

"Why was the stress test so strong for the first 10 minutes, then suddenly it couldn't keep up?"

This may not mean the machine is broken—it may mean you used up the burst.

Typical signs of CPU throttling

Performance is normal or even great at the start
After sustained pressure it drops to a fixed level
Credits approach 0 in the provider's monitoring
The workload isn't finished, but the CPU ceiling seems to have been capped

Typical signs of normal CPU saturation

us / sy are very high
Throughput rises as load rises
It's just that real compute power is the final limit

This looks more like "the machine isn't enough," not "the platform is capping you."

4. The Disk Layer: How to Tell Whether I/O Is Genuinely Maxed Out or IOPS Is Capped

The disk layer is the easiest to misunderstand, because many people only look at one number: disk MB/s.

But the actual bottleneck is often not sequential throughput, but:

IOPS
Latency
Queue depth
Random read/write capability

First look at `iowait`

Common command:

vmstat 1
iostat -x 1

Focus on:

%wa
%util
await

Common misconception

High iowait doesn't necessarily mean throttling.

It only means:

The CPU is waiting on I/O

As for why it's waiting, it could be:

The disk is genuinely slow
The queue is too long
Storage latency is high
IOPS is capped by quota

Typical signs of disk throttling

You keep adding pressure, but IOPS stops growing
Latency starts rising noticeably
%util is very high, but throughput won't go up
Multiple fio results hit the same ceiling

See it more clearly with `fio`

fio --name=randwrite-test     --ioengine=libaio     --direct=1     --rw=randwrite     --bs=4k     --size=1G     --iodepth=64     --numjobs=4     --runtime=120     --time_based     --group_reporting

What you need to look at isn't "how much it ran in a single run," but:

Whether IOPS keeps growing as iodepth and numjobs increase
Whether p95 / p99 latency suddenly degrades
Whether random read/write is stuck, or sequential throughput is stuck

If you keep adding pressure and the result always gets stuck at a similar threshold, it looks a lot like an I/O quota or storage-layer rate limiting.

5. The Network Layer: How to Tell Whether It's a Bad Link, Workload Jitter, or Network Rate Capping

The network layer has the most misjudgments.

Many people see "slow speed" and immediately attribute it to circuit detours, packet loss, or peak hours.

These are of course common, but another possibility should also be considered:

The platform itself imposes limits on ports, instances, monthly traffic, or certain protocols

First use `iperf3` to see the ceiling

## 服务端
iperf3 -s

## 客户端
iperf3 -c <server_ip> -R

If you suspect a single stream isn't accurate, you can also test multiple streams.

Common signs of network throttling

A single stream is stuck at a fixed ceiling
Multiple streams can't break through that ceiling either
Tests at different times all hit the same tier
Rated at 1Gbps, but measured results look long-term capped at a lower value

Cases where the network is slow but not necessarily throttled

Bad routing
Packet loss
Peak-hour congestion
The target end is itself slow
Local ISP issues

So the network layer must be examined in two steps:

Path quality
Whether the throughput ceiling is being hit in a rule-based way

If it only fluctuates during peak hours, it's more like congestion; if it's stuck at the same tier at all times, it's more like a limit.

Another easily overlooked kind of "rate limiting"

Some are not instance-layer throttling, but business policy limits, such as:

Rate limiting after exceeding monthly traffic
Specific ports / specific protocols being capped
Outbound port 25 blocked by default for email scenarios

This isn't "host machine preemption," but a limit at the provider's policy layer.

6. The 4 Most Easily Confused Situations

1. CPU maxed out doesn't mean CPU is rate-limited

If your application genuinely maxes out the CPU, that's resource saturation, not throttling.

2. Slow network doesn't mean network is rate-capped

Bad links, peak hours, packet loss, and slow target ends can all make you feel "like it's rate-limited."

3. High disk latency doesn't necessarily mean there's an IOPS quota

It could also just be that the host storage is genuinely busy, or your access pattern itself is unfriendly.

4. Low benchmark scores don't mean the platform is ripping you off

Benchmark scores are only a symptom, not a conclusion. You must combine:

Metrics
Timeline
Quota model
Results reproduced multiple times

and judge them together.

7. The Most Practical Troubleshooting Order for Ordinary Users

If you suspect your VPS is being throttled right now, you can follow this order:

Step 1: First confirm whether it's "genuinely maxed out"

Look at:

CPU usage
load
Memory
iowait
Network throughput

If the workload itself is heavy, don't rush to blame the platform.

Step 2: Look for a "rule-based ceiling"

Focus on:

Whether the CPU drops to a fixed baseline
Whether IOPS hits a wall
Whether throughput is always stuck at a fixed tier

Step 3: Look at host-layer contention signals

Focus on:

steal time
credits
The provider's monitoring panel

Step 4: Reproduce with testing tools

CPU: look at behavior after sustained stress testing
Disk: use fio
Network: use iperf3

Don't just run once, but:

Run at different times
Run at different pressure levels
See whether it always hits the same ceiling

Step 5: Then decide on action

If you confirm it's throttling, then consider:

Upgrading the instance specs
Switching to a non-burstable instance type
Migrating to another provider/datacenter
Contacting the provider with evidence to communicate

8. After Confirming Throttling, What to Do Next

CPU layer

Check whether credits are exhausted
Switch to a non-burstable instance type
Avoid running long-term high-CPU tasks on shared burstable instances

Disk layer

Look at the current disk type and IOPS model
Check whether higher-spec storage is needed
Avoid putting high-random-write databases on low-spec shared disks

Network layer

Check whether the plan description has traffic/bandwidth/port policies
Distinguish bad links from rule-based rate limiting
For high-throughput workloads, try to avoid plans that are "cheap but have many network policies"

A very practical suggestion

Keep evidence before filing a ticket.

Don't just say:

"I feel it's gotten slower"

Instead, bring:

Time periods
Monitoring screenshots
fio / iperf3 / vmstat / iostat output
Results of multiple retests

This makes it harder for the provider to brush you off with a template reply.

9. Which Workloads Fear "Invisible Throttling" Most

The following workloads are especially vulnerable to limits that "look minor but actually hurt a lot":

Database services
Download sites
Proxy/gateway/relay services
High-concurrency API services
CI/CD build nodes
Video transcoding and batch processing tasks

Because these scenarios are all sensitive to the following metrics:

Stable throughput
Tail latency
Sustained CPU capability
Random I/O

It's not that they will definitely be throttled, but:

Once throttled, the impact will be very obvious.

10. Frequently Asked Questions (FAQ)

Q1: Can CPU usage be low and still be rate-limited?

Yes. For example, when steal time is high, credits are exhausted, or I/O wait is severe, the experience can be bad, but the CPU usage you see may not be outrageously high.

Q2: How to fastest distinguish "the machine is too weak" from "throttled by the platform"?

Look for whether there's a rule-based ceiling. True saturation is more like hitting a wall linearly; throttling is more like being stuck at some neat threshold.

Q3: Can low benchmark scores directly prove rate limiting?

No. Benchmark scores are only a clue, not a conclusion. You need to judge together with steal, credits, iowait, and fio/iperf3 retest results.

Q4: After confirming throttling, what's the top priority action?

First keep evidence and monitoring results, then decide whether to upgrade, switch instance types, migrate, or take the data to communicate with the provider.

Conclusion

The hardest part of VPS throttling isn't "how to solve it," but how to prove that what you're encountering isn't an ordinary performance bottleneck.

This whole article really just wants to help you build a judgment framework:

CPU layer: look at steal time, look at credits, look at the speed drop after sustained stress testing
Disk layer: look at iowait, look at whether IOPS hits a wall, look at whether latency rises abnormally
Network layer: look at whether throughput is rule-based capped, look at whether there are plan or port policy limits

In one sentence:

First distinguish "resources genuinely maxed out" from "the platform capping you," then decide whether to optimize, upgrade, or migrate.

If you now suspect your VPS is being throttled, don't rush to just run a speed test script once. What's truly useful isn't "I feel it's slow," but whether you can produce a set of sufficiently clear evidence proving that it's slow in a very regular way.

Situation

What you're actually dealing with

Normal Saturation

Your workload genuinely uses up the resources

Throttling (rate limiting/restriction)

The platform, quotas, credits, QoS, or host layer caps you at some ceiling

1. The Conclusion First: Distinguish Throttling from Normal Saturation

One-sentence test

2. When Are You Most Likely to Suspect "Not Slow, but Throttled"

1. Performance drops to a very neat number

2. Fast at first, then suddenly slow after running a while

3. The workload isn't obviously heavy, but latency starts to degrade

4. Multiple tests all hit the same ceiling

3. The CPU Layer: How to Tell Whether It's Insufficient Compute or CPU Throttling

First look at steal time

How to look

How to interpret

Then look at burst / credits-type instances

Typical signs of CPU throttling

Typical signs of normal CPU saturation

4. The Disk Layer: How to Tell Whether I/O Is Genuinely Maxed Out or IOPS Is Capped

First look at iowait

Common misconception

Typical signs of disk throttling

See it more clearly with fio

5. The Network Layer: How to Tell Whether It's a Bad Link, Workload Jitter, or Network Rate Capping

First use iperf3 to see the ceiling

Common signs of network throttling

Cases where the network is slow but not necessarily throttled

Another easily overlooked kind of "rate limiting"

6. The 4 Most Easily Confused Situations

1. CPU maxed out doesn't mean CPU is rate-limited

2. Slow network doesn't mean network is rate-capped

3. High disk latency doesn't necessarily mean there's an IOPS quota

4. Low benchmark scores don't mean the platform is ripping you off

7. The Most Practical Troubleshooting Order for Ordinary Users

Step 1: First confirm whether it's "genuinely maxed out"

Step 2: Look for a "rule-based ceiling"

Step 3: Look at host-layer contention signals

Step 4: Reproduce with testing tools

Step 5: Then decide on action

8. After Confirming Throttling, What to Do Next

CPU layer

Disk layer

Network layer

A very practical suggestion

9. Which Workloads Fear "Invisible Throttling" Most

10. Frequently Asked Questions (FAQ)

Q1: Can CPU usage be low and still be rate-limited?

Q2: How to fastest distinguish "the machine is too weak" from "throttled by the platform"?

Q3: Can low benchmark scores directly prove rate limiting?

Q4: After confirming throttling, what's the top priority action?

Conclusion

Loading…

1. The Conclusion First: Distinguish Throttling from Normal Saturation

One-sentence test

2. When Are You Most Likely to Suspect "Not Slow, but Throttled"

1. Performance drops to a very neat number

2. Fast at first, then suddenly slow after running a while

3. The workload isn't obviously heavy, but latency starts to degrade

4. Multiple tests all hit the same ceiling

3. The CPU Layer: How to Tell Whether It's Insufficient Compute or CPU Throttling

First look at steal time

How to look

How to interpret

Then look at burst / credits-type instances

Typical signs of CPU throttling

Typical signs of normal CPU saturation

4. The Disk Layer: How to Tell Whether I/O Is Genuinely Maxed Out or IOPS Is Capped

First look at iowait

Common misconception

Typical signs of disk throttling

See it more clearly with fio

5. The Network Layer: How to Tell Whether It's a Bad Link, Workload Jitter, or Network Rate Capping

First use iperf3 to see the ceiling

Common signs of network throttling

Cases where the network is slow but not necessarily throttled

Another easily overlooked kind of "rate limiting"

6. The 4 Most Easily Confused Situations

1. CPU maxed out doesn't mean CPU is rate-limited

2. Slow network doesn't mean network is rate-capped

3. High disk latency doesn't necessarily mean there's an IOPS quota

4. Low benchmark scores don't mean the platform is ripping you off

7. The Most Practical Troubleshooting Order for Ordinary Users

Step 1: First confirm whether it's "genuinely maxed out"

Step 2: Look for a "rule-based ceiling"

First look at `steal time`

First look at `iowait`

See it more clearly with `fio`

First use `iperf3` to see the ceiling

First look at `steal time`

First look at `iowait`

See it more clearly with `fio`

First use `iperf3` to see the ceiling