Sustained Load, Burst Capacity and CPU Credits Reality

Burst capacity sounds generous and can quietly bankrupt a workload's performance. A plan that happily bursts to several cores for a minute looks fast in benchmarks, then drops to a small sustained baseline when the burst budget runs out. For anything that runs longer than a quick spike, the sustained baseline is the number that determines real throughput, and confusing the two is how production surprises happen.

Credits are a spending account, not a limit

On many cloud hosts CPU beyond the baseline is billed from a credit balance: you accumulate credits while idle and spend them during bursts, and when the balance hits zero you sink to the baseline. An idle server builds a trial balance you can spend in a rush, but a continuously busy server runs on the baseline alone.

The practical read: sustained work is capped by the baseline, burst work is capped by the credit balance. Choose a plan whose baseline covers your steady load, and treat burst as a cushion for short jumps above it, never as your design capacity.

Measuring sustained throughput

To find the real sustained number, run a steady CPU load long enough to exhaust any burst budget and watch where the throughput settles. Anything under roughly ten minutes may still be riding the burst account, so extend the run to an hour.

# hammer all cores for 60 seconds, repeat and watch the settle point
sysbench cpu --threads=$(( $(nproc) )) --time=60 run
# then a longer, lower load to find the steady baseline
yes > /dev/null & sleep 600
top -b -n 1 | grep Cpu
kill %1

Run the burst test, note the peak, then run the sustained test and note the floor. If the two are far apart, your plan's headline numbers are telling you the best case, not the everyday case.

Watch the settle pattern across a whole day

A single hour shows the burst, not the sustained reality. Log throughput and CPU across a full day on production traffic, then look at the shape: how long after each burst does the box fall back to baseline, and does the fallback happen exactly when you need the speed? For a service that bursts on the hour, the hourly pattern is the design requirement.

# sample DCU utilisation every minute into a time-series file
while true; do
  printf "%s %s " "$(date +%F-%T)" "$(mpstat -P ALL 1 1 2>/dev/null     | awk '/^Average/ {print 100-$NF}')"
  uptime
  sleep 60
done > /var/log/cpu-sustained.log 2>&1

Plot the result and you will see whether your sustained work rides the baseline or constantly dips below it waiting for burst credits to refill. The plan is sustainable when the baseline covers the recurring load and burst only absorbs the spikes between. If the baseline is below your recurring load, no amount of burst capacity closes that gap and the plan is wrong.

The memory-and-burst trap

Burst CPU interacts badly with memory pressure. A server that bursts on credits while simultaneously swapping spends those precious requested cycles waiting on storage. Size memory generously before you chase CPU credits, because a plan whose CPU bursts but whose memory starves converts expensive bursts into slow stalls.

Why burst-only sizing breaks in production

A bursty benchmark flatters a server whose average load is low but whose realized demand comes in surges. The trap is assuming the surges are rare. Many real workloads burst constantly: a cron sweep, a backup window, a batch of webhooks all land in the same minutes. What looks like a burst cushion becomes continuous baseline demand, the credits drain, and the server sits at the floor during exactly the traffic you care about.

How to design around it

• Size the plan so the sustained baseline covers your worst sustained hour, not your slow afternoon.
• Keep twice the memory you think you need for the working set, because memory and burst CPU interact badly when both peak.
• Put surge work (backups, batch jobs) in a schedule offset from traffic peaks so it does not double-spend the credit balance.

Takeaway

Look past the burst headline to the sustained baseline, because that is what your steady traffic runs on. Measure both, then size to the sustained number and keep burst as genuine headroom. On Netbay, pay-as-you-go plans and on-demand resizing let you match either profile from the dashboard or the API at netbayhosts.in.