How CPU Burst Improves Container Performance Without Reducing Deployment Density

Background

In Kubernetes, cpu limits enforce a maximum CPU time for a container via the Linux CPU Bandwidth Controller. When usage exceeds the limit, the controller throttles the cgroup, degrading latency‑sensitive metrics. To avoid throttling, operators often inflate limits many times, which reduces container deployment density.

CPU Burst Feature

CPU Burst, merged into Linux 5.14 and supported by Anolis OS 8.2, Alibaba Cloud Linux 2/3, introduces “burst tokens”. When a cgroup’s average usage is below its quota, unused quota accumulates as tokens. Tokens can be spent to exceed the quota briefly, allowing short CPU spikes without raising the static limit.

Bandwidth Controller Mechanics

The controller works with a period (e.g., 100 ms) and a quota (e.g., 50 ms). In each period a cgroup may consume up to quota CPU time; excess usage is throttled. Fine‑grained 100 ms spikes are not visible in second‑level utilization metrics, leading to unexpected throttling.

Analytical Model

We model the system as a classic queueing problem. Let m be the number of cgroups sharing the CPU, each with quota = 1/m. In each period a cgroup generates a CPU demand drawn independently from a chosen distribution (exponential or Pareto) with mean u_avg × quota. A buffer parameter b (multiple of quota) limits the amount of burst tokens that can be accumulated.

The model checks two constraints per period:

Scheduler stability – total demand must be ≤ 100 % of CPU capacity.

Real‑time guarantee – the worst‑case execution time (WCET) of any cgroup must not exceed one period.

Monte‑Carlo Evaluation

We run Monte‑Carlo simulations to estimate:

Probability that WCET > period.

Expected WCET for given m, demand distribution, and buffer size.

Results show that lower average utilization and larger m reduce the probability of violating the constraints, confirming that CPU Burst is safe when the system is not heavily loaded.

Key Findings

Higher u_avg and fewer cgroups increase WCET and the chance of throttling.

Increasing the buffer improves performance for the burst‑enabled cgroup but can raise WCET for its neighbors.

When average CPU utilization stays below ≈ 70 %, CPU Burst has negligible impact on other containers.

Practical Guidance

For workloads with modest average CPU usage, enable CPU Burst with a moderate buffer (e.g., b = 2 × quota). This improves latency‑sensitive services without sacrificing deployment density. For high‑load scenarios, consider reducing container density or increasing CPU allocation before enabling Burst.

Simulation Tool

A lightweight simulator is available at

https://codeup.openanolis.cn/codeup/yingyu/cpuburst-simulator

. It accepts real‑world CPU traces (e.g., ./data/cg1_data.npy) and lets the user set m, u_avg, and b to predict the impact of CPU Burst.

Example Workflow

Collect CPU usage from a representative container and store it as cg1_data.npy.

Run sample.py to compute average usage (e.g., 6.5 %).

Execute simu_from_data.py with m=10 and b=200%. The simulation reports negligible WCET increase, indicating that CPU Burst can be safely enabled.