Burstable Resources

In order to maximize affordability and flexibility, Luna Node General-Purpose and Memory-Optimized virtual machines are assigned a portion of available CPU resources and disk I/O rather than specific dedicated CPU cores or physical disks. Because most application workloads have both periods of high CPU and I/O utilization and periods of low utilization, this maximizes cost savings -- essentially, instead of needing to continuously pay for a particular VM's peak utilization, you need only pay for its average utilization.

Compute-Optimized virtual machines are assigned dedicated CPU cores.

At a high-level, we assign each VM a baseline CPU and I/O performance. If your VM has periods where its resource utilization is below this baseline, then it collects "points" that it can later use to obtain resource utilization above the baseline.

Burst Points System

Baseline performance. Each virtual machine has a baseline performance:

CPU: 100% CPU utilization for every 1.0 CPU-Points specified in the plan (for example, s.half includes 0.2 CPU-Points, and a baseline performance of 20% CPU utilization)

CPU: 1 CPU burst point corresponds to 100% utilization of a core for five minutes. A VM receives the plan CPU-Points every five minutes.

Disk I/O: 1 I/O burst point corresponds to 100 IOPS sustained over five minutes. A VM receives 1 burst point every five minutes.

For example, if an s.half VM (which has 0.2 plan CPU-Points) starts with 10 burst points, and then uses 20% of the CPU core for one hour, it will end with 10 burst points. On the other hand, if the VM uses 10% of a core for one hour, it ends with 11.2 burst points (an additional 0.1 points for each five-minute interval), and if it uses 30% of a core for one hour, it ends with 8.8 burst points.

Throttling. VM resource utilization may be throttled to the baseline performance if it has zero burst points. In some cases, the platform will not throttle the VM, or will throttle it to a level above the baseline performance, if it determines that the system can handle the additional load from the VM.

Maximum points. There are upper limits on the number of burst points that a VM can accumulate. Once it reaches the limit, the VM burst points will stop increasing:

CPU: 24 CPU burst points * number of cores (e.g. max of 48 points for a VM with two cores)

I/O: 60 I/O burst points

Borrowing. If a VM runs out of CPU points, and there is another VM on your account on the same hypervisor with close to the maximum CPU points, then the system will re-allocate points from the second VM to the first. Thus, the first VM will not be throttled until you no longer have any VMs on the same hypervisor with close to the maximum CPU points. I/O points cannot be "borrowed".

In some cases, you may want to prevent a VM's CPU points from being re-allocated to other VMs even if its points are close to the maximum. To do so, disable CPU utilization lending from the CPU tab.

Monitoring points. Charts showing CPU points and I/O points over time can be retrieved from the Graphs tab.

Paying for CPU Performance above the Baseline

By default, VMs may be throttled once they run out of CPU or I/O burst points.

To avoid CPU throttling, you can opt to pay for CPU performance above the baseline performance from the CPU tab.

Pricing is $0.0037 per CPU burst point. If your VM runs out of burst points, instead of throttling the VM, the platform will grant the VM one burst point while assessing the charge to your account. If the VM's CPU burst point count never reaches zero, then you will not be charged.

For example, suppose that you use 50% of each core over 30 days on a s.1 VM, which has 0.4 plan cpu-points. Your VM will need an additional 0.6 burst points for every five-minute interval in the month, on top of the 0.4 baseline performance included in the plan. Thus, the VM will use a total of 5184 additional CPU burst points over the 30-day interval, which is equivalent to a $19.18 charge.

History

Before 3 January 2018, we simply had a "fair share usage policy" that stated that CPU and disk I/O are shared, and excessive utilization may result in service suspension. In practice, we would send an e-mail when excessive utilization was detected, and coordinate with the user to either reduce the usage to an acceptable level or upgrade to a larger instance.

We have since deployed an automatic management system that makes this policy much more concrete.