What is CPU Priority?
The CPU priority is the amount of CPU resource a VS is given (you can think of this as its “share percentage” multiplied by the number of cores allocated to that VS). This is a minimum number – you can burst over it, up to 100% multiplied by the number of cores.
For example, you have a hypervisor with 3GHz CPU cores. Then:
100% x 1 core = 3GHz (burstable to 3GHz)
10% x 2 cores = 600MHZ (burstable to 6GHz)
5 % x 4 cores = 600MHz (burstable to 12GHz)
So you can either create one VS with 100% CPU priority on that HV, or 5 VSs with 20% CPU priority (or any other combinations with the total of 100%).
How does it work?
Imagine a hypervisor like a grocery store with only two checkouts ( CPU cores). In the afternoon, there are not so many customers (virtual servers) so when someone needs to go to checkout, there is always one available. Later in the night, a queue starts to form and customers have to wait, but some of them push to the front of the queue (100 % priority) whilst all other (1% priority) have to wait patiently for the line ahead to clear.
Can I oversell resources?
Depending on the settings of your cloud (CPU Guarantee), OnApp may allow overselling of cloud resources. For example, OnApp will allow you to create 5 virtual servers with 100% CPU priority/1 CPU core on a hypervisor with a 4-core CPU. In this example, OnApp would reduce the guaranteed CPU for each virtual server.
If resource overselling is disabled for your cloud, OnApp will not create virtual servers requiring more CPU resource than is available on the hypervisor.
Does CPU priority depend on the virtualization type?
Yes, the CPU priority you can set to virtual server depends on the virtualization type of the hypervisor the server is located on:
- On Xen hypervisors, you can set the 1-100 CPU priority value.
- On KVM hypervisors under CentOS 6, you can set the 1-100 CPU priority value.
- On KVM hypervisors under CentOS 5, the CPU priority is 100 by default.
How are CPU/CPU shares charged?
Starting with the 3.1 version, CPU, CPU shares and memory limits are set for the hypervisor zone. This change does not affect the billing algorithm.
When calculating CPU billing for a particular resource, the sum of all virtual server’s CPU over the free limit is billed.
So, the CPU billing formula can be displayed as follows:
(VS1 CPUs) + (V2 CPUs) + (VS# CPUs) - free CPU limit
In this example, free CPU limit is 3.
If we have 2 virtual servers:
First virtual server has 2 CPUs
Second virtual server has 3 CPUs
The number of CPU charged:
(2+3) - 3 = 2
To calculate the CPU shares price for the virtual server, multiply the number of server’s cores by CPU priority percentage given.
Then, each virtual server’s CPU priority value is compared to the free CPU shares limit in a linear queue (starting from the first added virtual server), then each next virtual server is compared to the free CPU shares limit remainders.
In this example, free CPU shares limit is 140.
First virtual server has 2 CPUs and 50% CPU priority (100% in total).
Second virtual server has 3 CPUs and 40% CPU priority (120% in total).
According to the billing algorithm, first virtual server checks if there are servers added before it and then gets compared to the free CPU shares limit:
100 < 140, so it is not charged (40 of free CPU shares limit remain)
Then, second virtual server is compared to the remaining CPU shares limit:
120 > 40 (120 – 40 = 80, so 80 percent of this server’s CPU shares will be charged).