What is CPU Bursting?
CPU Bursting is a proprietary feature developed by Pufferfish Host, which aims to give your server extra performance boosts when necessary. It works similar to CPU bursting features by enterprise cloud platforms like Google Cloud Platform.
As your server is running, CPU resources are consumed at different rates. If a plugin on your server needs to perform a particularly intensive task, then you may see a lag spike due to an increase in CPU usage. Other dedicated server hosts will throttle you to a maximum limit, not allowing you to use any extra resources, even if your node has them available. At Pufferfish Host, we don’t agree with this. Why waste CPU resources?
With Pufferfish Host’s CPU Bursting feature, these lag spikes would be prevented. Instead of limiting your CPU usage, we would allow you to temporarily use additional CPU resources, while they are available. When CPU bursts are active, your server can use up to 2x its typical CPU allocation, which is an effective way to minimize or eliminate lag spikes due to these periodic intensive tasks.
In fact, we’ve thoroughly benchmarked our CPU burst feature to prove that it actually makes a difference. In this benchmark, we compared Pufferfish Host’s 6GB plan with similar plans from our competitors. With CPU bursting disabled, we saw an insignificant difference in performance between us and our competitors, as expected. However, with CPU bursting enabled, we saw an obvious difference in the severity of lag spikes:
We also were able to observe significantly faster server startup times due to CPU bursts being applied during server startup (startup times mesasured on Paper 1.17 with no plugins):
CPU Bursting is enabled according to a proprietary algorithm that automatically determines when your server needs the extra power. CPU Bursts can last anywhere from a few seconds to a few minutes, depending on how large the resource requirements are. If your server is using a greater percentage of its resource allocation, then CPU bursts will last for a shorter period of time.
When your server is using its CPU burst allocation, it does not get priority over other servers on the machine. CPU bursts are not guaranteed, but due to how resources are typically consumed on Minecraft servers, they are likely to always be available. If your server is using all of its normal allocation, then another server will not be eligible to burst onto your server’s CPU cores.
Overall, Pufferfish Host’s CPU Burst technology is a great way to minimize lag spikes that occur during a server’s normal operation, and will give your server extra resources when required. Creating a platform that delivers the absolute maximum performance is our goal, and with this CPU bursting feature, your server will perform far better.
What is CPU burst?
Amazon has recently announced Micro instances for Amazon EC2. I’m also keep reading about «. allow you to burst CPU capacity when additional cycles are available.» My question is, what does CPU burst mean? I want to know/understand this better. Any pointers, articles, documentation, etc. on the same are appreciated.
- amazon-ec2
- central-processing-unit
18k 6 6 gold badges 64 64 silver badges 82 82 bronze badges
asked Sep 10, 2010 at 14:11
1,479 13 13 gold badges 26 26 silver badges 32 32 bronze badges
2 Answers 2
Good question — meanwhile there is more information available regarding this topic:
At steady state, Micro instances receive a fraction of the compute resources that Small instances do. Therefore, if your application has compute-intensive or steady state needs we recommend using a Small instance (or larger, depending on your needs). However, Micro instances can periodically burst up to 2 ECUs (for short periods of time). This is double the number of ECUs available from a Standard Small instance. Therefore, if you have a relatively low throughput application or web site with an occasional need to consume significant compute cycles, we recommend using Micro instances. [Note: ECU is a “EC2 Compute Unit”, see What is a “EC2 Compute Unit” and why did you introduce it? for details]
CPU Bursting
CPU bursting is a feature of SmartOS that allows hosted web applications in a zone to temporarily use more CPU cycles than is allocated to a virtual machine, providing a temporary performance boost.
Baseline vs. Cap¶
Virtual machines running SmartOS have a flexible and inflexible number of CPU cycles available at any time: baseline and cap. The CPU cap is the maximum amount of CPU cycles available to a virtual machine at any given time. The CPU baseline is a percentage of the CPU cap and is the number of CPU cycles available to it without the need to burst. When a hosted web application experiences a high volume of throughput, the virtual machine hosting the application can use CPU bursting to consume CPU cycles that exceed the baseline limit for a short period of time.
The amount a virtual machine can burst depends on how much of the CPU resource pool is available. If only a single virtual machine in a datacenter needs to burst, it can use as many CPU cycles as is needed (up to the cap limit). If multiple virtual machines in a datacenter need to burst at the same time, they will share available cycles in the resource pool.
The amount of time a virtual machine can burst is set as a property in the global zone. If a virtual machine continues to burst past the allocated time limit, the CPU cap for that virtual machine is temporarily reduced to the value of the CPU baseline, effectively disabling bursting.
When an application is placed in a reduced cap state for bursting too long, a timer begins to countdown that determines how long the application remains in a reduced cap state. The CPU cap is reset to the original value and bursting is re-enabled once the timer counts down to zero. The amount of time a virtual machine must stay in a reduced CPU cap state is also set as a property in the global zone.
CPU Burst
CPU Burst is a service level objective (SLO)-aware resource scheduling feature provided by Koordinator. You can use CPU Burst to improve the performance of latency-sensitive applications. CPU scheduling for a container may be throttled by the kernel due to the CPU limit, which downgrades the performance of the application. The koordlet component automatically detects CPU throttling events and automatically adjusts the CPU limit to a proper value. This greatly improves the performance of latency-sensitive applications.
How CPU Burst works
Kubernetes allows you to specify CPU limits, which can be reused based on time-sharing. If you specify a CPU limit for a container, the OS limits the amount of CPU resources that can be used by the container within a specific time period. For example, you set the CPU limit of a container to 2. The OS kernel limits the CPU time slices that the container can use to 200 milliseconds within each 100-millisecond period.
CPU utilization is a key metric that is used to evaluate the performance of a container. In most cases, the CPU limit is specified based on CPU utilization. CPU utilization on a per-millisecond basis shows more spikes than on a per-second basis. If the CPU utilization of a container reaches the limit within a 100-millisecond period, CPU throttling is enforced by the OS kernel and threads in the container are suspended for the rest of the time period, as shown in the following figure.
The following figure shows the thread allocation of a web application container that runs on a node with four vCPUs. The CPU limit of the container is set to 2. The overall CPU utilization within the last second is low. However, Thread 2 cannot be resumed until the third 100-millisecond period starts because CPU throttling is enforced somewhere in the second 100-millisecond period. This increases the response time (RT) and causes long-tail latency problems in containers.
Upstream Linux kernel >=5.14 and Anolis OS both provide Burstable CFS Controller, namely CPU Burst feature. It allows a container to accumulate CPU time slices when the container is idle. The container can use the accumulated CPU time slices to burst above the CPU limit when CPU utilization spikes. This improves performance and reduces the RT of the container.
For kernel versions that do not support CPU Burst, koordlet detects CPU throttling events and dynamically adjusts the CPU limit to achieve the same effect as CPU Burst.
Setup
Prerequisite
- Kubernetes >= 1.18
- Koordinator >= 0.3
Installation
Please make sure Koordinator components are correctly installed in your cluster. If not, please refer to Installation.
Configurations
Koordlet has already enabled CPU Burst feature ( -feature-gates=AllAlpha=true ). If not, please enable it manually by updating the feature gate in the koordlet daemonset.
NOTE: CPU Burst is not available for LSR and BE pods since it targets on burstable cpu usages.
apiVersion: apps/v1 kind: DaemonSet metadata: name: koordlet spec: selector: matchLabels: koord-app: koordlet template: metadata: labels: koord-app: koordlet spec: containers: - command: - /koordlet args: - -CgroupRootDir=/host-cgroup/ - -feature-gates=XXXX,CPUBurst=true # enable CPU Burst feature . Use CPU Burst
Use an annotation to enable CPU Burst for the pod
Add the following annotation to the pod configuration to enable CPU Burst:
apiVersion: apps/v1 kind: Pod metadata: name: demo-pod-xxx annotations: # Set the value to auto to enable CPU Burst for the pod. koordinator.sh/cpuBurst: '' # To disable CPU Burst for the pod, set the value to none. #koordinator.sh/cpuBurst: '' Use a ConfigMap to enable CPU Burst for all pods in a cluster
Modify the slo-controller-config ConfigMap based on the following content to enable CPU Burst for all pods in a cluster:
apiVersion: v1 kind: ConfigMap metadata: name: slo-controller-config namespace: koordinator-system data: cpu-burst-config: '>' #cpu-burst-config: '>' #cpu-burst-config: '>' (Optional) Advanced Settings
The following code block shows the pod annotations and ConfigMap fields that you can use for advanced configurations:
# Example of the slo-controller-config ConfigMap. data: cpu-burst-config: | "clusterStrategy": "policy": "auto", "cpuBurstPercent": 1000, "cfsQuotaBurstPercent": 300, "sharePoolThresholdPercent": 50, "cfsQuotaBurstPeriodSeconds": -1 > > # Example of pod annotations. koordinator.sh/cpuBurst: '' The following table describes the ConfigMap fields that you can use for advanced configurations of CPU Burst.
- none: disables CPU Burst. If you set the value to none, the related fields are reset to their original values. This is the default value.
- cpuBurstOnly: enables the CPU Burst feature only for the kernel of Anolis OS or upstream linux kernel >= 5.14.
- cfsQuotaBurstOnly: enables automatic adjustment of CFS quotas of general kernel versions.
- auto: enables CPU Burst and all the related features.
Verify CPU Burst
- Use the following YAML template to create an apache-demo.yaml file.
To enable CPU Burst for a pod, specify an annotation in the annotations parameter of the metadata section of the pod configuration.
apiVersion: v1 kind: Pod metadata: name: apache-demo annotations: koordinator.sh/cpuBurst: '' # Use this annotation to enable or disable CPU Burst. spec: containers: - command: - httpd - -D - FOREGROUND image: koordinatorsh/apache-2-4-51-for-slo-test:v0.1 imagePullPolicy: Always name: apache resources: limits: cpu: "4" memory: 10Gi requests: cpu: "4" memory: 10Gi nodeName: # $nodeName Set the value to the name of the node that you use. hostNetwork: False restartPolicy: Never schedulerName: default-scheduler - Run the following command to create an application by using Apache HTTP Server.
kubectl apply -f apache-demo.yaml - Use the wrk2 tool to perform stress tests.
# Download, decompress, and then install the wrk2 package. # The Gzip module is enabled in the configuration of the Apache application. The Gzip module is used to simulate the logic of processing requests on the server. # Run the following command to send requests. Replace the IP address in the command with the IP address of the application. ./wrk -H "Accept-Encoding: deflate, gzip" -t 2 -c 12 -d 120 --latency --timeout 2s -R 24 http://$target_ip_address:8010/static/file.1m.test - Check the results of CPU Burst enabled and disabled.
e.g. We may have the following results:
| CentOS 7 | Disabled | Enabled |
|---|---|---|
| apache RT-p99 | 111.69 ms | 71.30 ms (-36.2%) |
| CPU Throttled Ratio | 33% | 0% |
| Average pod CPU utilization | 32.5% | 33.8% |
The preceding metrics indicate the following information:
- After CPU Burst is enabled, the P99 latency of apache is greatly reduced.
- After CPU Burst is enabled, CPU throttling is stopped and the average pod CPU utilization remains approximately at the same value.