You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cloudstack.apache.org by Abhinandan Prateek <Ab...@citrix.com> on 2013/02/05 07:44:20 UTC
FW: Regarding Cpu and memory overcommit feature.
On 01/02/13 4:22 PM, "Bharat Kumar" <bh...@citrix.com> wrote:
>Hi All,
>
>I have made changes to the way capacity is calculated in Cloudstack ,
>please review and comment.
>
>I will illustrate this with an example.
>
>let us say we have a host with
>Actual Total capacity=4GB ram,
>
>and the overcommit ratio be 2.
>
>Current way
>Total capacity= 4*2= 8GB.
>Values after deploying 4 VMs with 1GB in service offering.
>Allocated per vm =1GB.
>Used=4GB
>Available=8-4=4GB
>now if we decrease the overcommit ratio to 1
>Total Capacity = 4*1=4GB.
>used Capacity = 4GB.
>Available = 4-4=0. (implies 100% usage. can also go to more than 100%)
We should store the actuals in the db with over commit ratio. And rest of
the values of available memory and used memory can be calculated form that.
So the new method mentioned below looks consistent.
-abhi
>
>XenServer uses DMC for memory overcommit, to use this feature we have to
>set the minimum and maximum ram that we want to allocate.
>The memory used by the VMs can vary between the minimum and maximum. In
>case of contention they will be allowed to use the minimum memory
>allocated
>to them. Minimum memory is the reserved memory which is guaranteed for
>the VM.
>
>New WAY.
>Total Capacity= 4GB.
>Values after deploying 4VMs with 1GB in service offering.
>Allocated per VM = 1GB/ overcommit = 512MB. (This is set as the minimum
>and 1GB is the maximum.)
>Used = 4* minimum allocated per vm = 2GB.
>Available = 4-2= 2GB.
>Value that is visible to admin as available = Available * overcommit
>ratio =2*2= 4GB.
>Now if we decrease the overcommit ratio to 1
>Available capacity =total - used = 4-2= 2GB. (This 2GB will be made
>available by the XenServer using DMC.)
>(we can still deploy VMs in this case )
>
>Major differences are
>1.) In new way we store what we actually allocate in the DB rather than
>the one in the service offering.
>2.) All calculations are done based on the actuals.
>3.) Depending on the overcommit values we scale down and then allocate.
>
>Advantages
>1.) The usage can never go beyond 100% and is independent of changes in
>overcommit values.
>2.) We can deploy more VMs.
>
>Also please comment if we need to show actuals on the dashboard or the
>over provisioned values and why.
>
>Regards,
>Bharat.
>
>
>
>
>
Re: Regarding Cpu and memory overcommit feature.
Posted by Bharat Kumar <bh...@citrix.com>.
Hi Prachi,
When I said actual I was referring to the minimum memory available to a VM.
Bharat.
On Feb 6, 2013, at 1:11 AM, Prachi Damle <Pr...@citrix.com> wrote:
> Hi Bharat / Abhi,
>
> Even currently we always store actuals in the DB in op_host_capacity table. During allocation, the overprovisioning ratios are applied dynamically to find the overprovisioned "total" capacity.
> So it's good that even the new way will follow that.
>
>> Major differences are
>> 1.) In new way we store what we actually allocate in the DB rather than
>> the one in the service offering.
>> 2.) All calculations are done based on the actuals.
>> 3.) Depending on the overcommit values we scale down and then allocate.
>
> This is based on the XenServer overcommit support. What will happen for rest of the hypervisors, since currently capacity calculation is a generic logic?
>
>
> -Prachi
>
> -----Original Message-----
> From: Abhinandan Prateek [mailto:Abhinandan.Prateek@citrix.com]
> Sent: Monday, February 04, 2013 10:44 PM
> To: cloudstack-dev@incubator.apache.org
> Subject: FW: Regarding Cpu and memory overcommit feature.
>
>
> On 01/02/13 4:22 PM, "Bharat Kumar" <bh...@citrix.com> wrote:
>
>> Hi All,
>>
>> I have made changes to the way capacity is calculated in Cloudstack ,
>> please review and comment.
>>
>> I will illustrate this with an example.
>>
>> let us say we have a host with
>> Actual Total capacity=4GB ram,
>>
>> and the overcommit ratio be 2.
>>
>> Current way
>> Total capacity= 4*2= 8GB.
>> Values after deploying 4 VMs with 1GB in service offering.
>> Allocated per vm =1GB.
>> Used=4GB
>> Available=8-4=4GB
>
>> now if we decrease the overcommit ratio to 1 Total Capacity = 4*1=4GB.
>> used Capacity = 4GB.
>> Available = 4-4=0. (implies 100% usage. can also go to more than 100%)
>
>
> We should store the actuals in the db with over commit ratio. And rest of
> the values of available memory and used memory can be calculated form that.
> So the new method mentioned below looks consistent.
>
> -abhi
>
>>
>> XenServer uses DMC for memory overcommit, to use this feature we have to
>> set the minimum and maximum ram that we want to allocate.
>> The memory used by the VMs can vary between the minimum and maximum. In
>> case of contention they will be allowed to use the minimum memory
>> allocated
>> to them. Minimum memory is the reserved memory which is guaranteed for
>> the VM.
>>
>> New WAY.
>> Total Capacity= 4GB.
>> Values after deploying 4VMs with 1GB in service offering.
>> Allocated per VM = 1GB/ overcommit = 512MB. (This is set as the minimum
>> and 1GB is the maximum.)
>> Used = 4* minimum allocated per vm = 2GB.
>> Available = 4-2= 2GB.
>> Value that is visible to admin as available = Available * overcommit
>> ratio =2*2= 4GB.
>> Now if we decrease the overcommit ratio to 1
>> Available capacity =total - used = 4-2= 2GB. (This 2GB will be made
>> available by the XenServer using DMC.)
>> (we can still deploy VMs in this case )
>>
>> Major differences are
>> 1.) In new way we store what we actually allocate in the DB rather than
>> the one in the service offering.
>> 2.) All calculations are done based on the actuals.
>> 3.) Depending on the overcommit values we scale down and then allocate.
>>
>> Advantages
>> 1.) The usage can never go beyond 100% and is independent of changes in
>> overcommit values.
>> 2.) We can deploy more VMs.
>>
>> Also please comment if we need to show actuals on the dashboard or the
>> over provisioned values and why.
>>
>> Regards,
>> Bharat.
>>
>>
>>
>>
>>
>
Re: Regarding Cpu and memory overcommit feature.
Posted by Abhinandan Prateek <Ab...@citrix.com>.
Prachi,
For Hypervisor not supporting overcommit, the cluster of those
hypervisors cannot have a overcommit. It should not affect the current
capacity calculation. Bharat will be able to elaborate on this.
-abhi
On 06/02/13 1:11 AM, "Prachi Damle" <Pr...@citrix.com> wrote:
>Hi Bharat / Abhi,
>
>Even currently we always store actuals in the DB in op_host_capacity
>table. During allocation, the overprovisioning ratios are applied
>dynamically to find the overprovisioned "total" capacity.
>So it's good that even the new way will follow that.
>
>>Major differences are
>>1.) In new way we store what we actually allocate in the DB rather than
>>the one in the service offering.
>>2.) All calculations are done based on the actuals.
>>3.) Depending on the overcommit values we scale down and then allocate.
>
>This is based on the XenServer overcommit support. What will happen for
>rest of the hypervisors, since currently capacity calculation is a
>generic logic?
>
>
>-Prachi
>
>-----Original Message-----
>From: Abhinandan Prateek [mailto:Abhinandan.Prateek@citrix.com]
>Sent: Monday, February 04, 2013 10:44 PM
>To: cloudstack-dev@incubator.apache.org
>Subject: FW: Regarding Cpu and memory overcommit feature.
>
>
>On 01/02/13 4:22 PM, "Bharat Kumar" <bh...@citrix.com> wrote:
>
>>Hi All,
>>
>>I have made changes to the way capacity is calculated in Cloudstack ,
>>please review and comment.
>>
>>I will illustrate this with an example.
>>
>>let us say we have a host with
>>Actual Total capacity=4GB ram,
>>
>>and the overcommit ratio be 2.
>>
>>Current way
>>Total capacity= 4*2= 8GB.
>>Values after deploying 4 VMs with 1GB in service offering.
>>Allocated per vm =1GB.
>>Used=4GB
>>Available=8-4=4GB
>
>>now if we decrease the overcommit ratio to 1 Total Capacity = 4*1=4GB.
>>used Capacity = 4GB.
>>Available = 4-4=0. (implies 100% usage. can also go to more than 100%)
>
>
>We should store the actuals in the db with over commit ratio. And rest of
>the values of available memory and used memory can be calculated form
>that.
>So the new method mentioned below looks consistent.
>
>-abhi
>
>>
>>XenServer uses DMC for memory overcommit, to use this feature we have to
>>set the minimum and maximum ram that we want to allocate.
>>The memory used by the VMs can vary between the minimum and maximum. In
>>case of contention they will be allowed to use the minimum memory
>>allocated
>>to them. Minimum memory is the reserved memory which is guaranteed for
>>the VM.
>>
>>New WAY.
>>Total Capacity= 4GB.
>>Values after deploying 4VMs with 1GB in service offering.
>>Allocated per VM = 1GB/ overcommit = 512MB. (This is set as the minimum
>>and 1GB is the maximum.)
>>Used = 4* minimum allocated per vm = 2GB.
>>Available = 4-2= 2GB.
>>Value that is visible to admin as available = Available * overcommit
>>ratio =2*2= 4GB.
>>Now if we decrease the overcommit ratio to 1
>>Available capacity =total - used = 4-2= 2GB. (This 2GB will be made
>>available by the XenServer using DMC.)
>>(we can still deploy VMs in this case )
>>
>>Major differences are
>>1.) In new way we store what we actually allocate in the DB rather than
>>the one in the service offering.
>>2.) All calculations are done based on the actuals.
>>3.) Depending on the overcommit values we scale down and then allocate.
>>
>>Advantages
>>1.) The usage can never go beyond 100% and is independent of changes in
>>overcommit values.
>>2.) We can deploy more VMs.
>>
>>Also please comment if we need to show actuals on the dashboard or the
>>over provisioned values and why.
>>
>>Regards,
>>Bharat.
>>
>>
>>
>>
>>
>
RE: Regarding Cpu and memory overcommit feature.
Posted by Prachi Damle <Pr...@citrix.com>.
Hi Bharat / Abhi,
Even currently we always store actuals in the DB in op_host_capacity table. During allocation, the overprovisioning ratios are applied dynamically to find the overprovisioned "total" capacity.
So it's good that even the new way will follow that.
>Major differences are
>1.) In new way we store what we actually allocate in the DB rather than
>the one in the service offering.
>2.) All calculations are done based on the actuals.
>3.) Depending on the overcommit values we scale down and then allocate.
This is based on the XenServer overcommit support. What will happen for rest of the hypervisors, since currently capacity calculation is a generic logic?
-Prachi
-----Original Message-----
From: Abhinandan Prateek [mailto:Abhinandan.Prateek@citrix.com]
Sent: Monday, February 04, 2013 10:44 PM
To: cloudstack-dev@incubator.apache.org
Subject: FW: Regarding Cpu and memory overcommit feature.
On 01/02/13 4:22 PM, "Bharat Kumar" <bh...@citrix.com> wrote:
>Hi All,
>
>I have made changes to the way capacity is calculated in Cloudstack ,
>please review and comment.
>
>I will illustrate this with an example.
>
>let us say we have a host with
>Actual Total capacity=4GB ram,
>
>and the overcommit ratio be 2.
>
>Current way
>Total capacity= 4*2= 8GB.
>Values after deploying 4 VMs with 1GB in service offering.
>Allocated per vm =1GB.
>Used=4GB
>Available=8-4=4GB
>now if we decrease the overcommit ratio to 1 Total Capacity = 4*1=4GB.
>used Capacity = 4GB.
>Available = 4-4=0. (implies 100% usage. can also go to more than 100%)
We should store the actuals in the db with over commit ratio. And rest of
the values of available memory and used memory can be calculated form that.
So the new method mentioned below looks consistent.
-abhi
>
>XenServer uses DMC for memory overcommit, to use this feature we have to
>set the minimum and maximum ram that we want to allocate.
>The memory used by the VMs can vary between the minimum and maximum. In
>case of contention they will be allowed to use the minimum memory
>allocated
>to them. Minimum memory is the reserved memory which is guaranteed for
>the VM.
>
>New WAY.
>Total Capacity= 4GB.
>Values after deploying 4VMs with 1GB in service offering.
>Allocated per VM = 1GB/ overcommit = 512MB. (This is set as the minimum
>and 1GB is the maximum.)
>Used = 4* minimum allocated per vm = 2GB.
>Available = 4-2= 2GB.
>Value that is visible to admin as available = Available * overcommit
>ratio =2*2= 4GB.
>Now if we decrease the overcommit ratio to 1
>Available capacity =total - used = 4-2= 2GB. (This 2GB will be made
>available by the XenServer using DMC.)
>(we can still deploy VMs in this case )
>
>Major differences are
>1.) In new way we store what we actually allocate in the DB rather than
>the one in the service offering.
>2.) All calculations are done based on the actuals.
>3.) Depending on the overcommit values we scale down and then allocate.
>
>Advantages
>1.) The usage can never go beyond 100% and is independent of changes in
>overcommit values.
>2.) We can deploy more VMs.
>
>Also please comment if we need to show actuals on the dashboard or the
>over provisioned values and why.
>
>Regards,
>Bharat.
>
>
>
>
>
Re: Regarding Cpu and memory overcommit feature.
Posted by Abhinandan Prateek <Ab...@citrix.com>.
Bharat,
This is a 4.1 feature. Please update the progress and the git commit
sent for review in jira.
-abhi
On 05/02/13 12:14 PM, "Abhinandan Prateek" <Ab...@citrix.com>
wrote:
>
>On 01/02/13 4:22 PM, "Bharat Kumar" <bh...@citrix.com> wrote:
>
>>Hi All,
>>
>>I have made changes to the way capacity is calculated in Cloudstack ,
>>please review and comment.
>>
>>I will illustrate this with an example.
>>
>>let us say we have a host with
>>Actual Total capacity=4GB ram,
>>
>>and the overcommit ratio be 2.
>>
>>Current way
>>Total capacity= 4*2= 8GB.
>>Values after deploying 4 VMs with 1GB in service offering.
>>Allocated per vm =1GB.
>>Used=4GB
>>Available=8-4=4GB
>
>>now if we decrease the overcommit ratio to 1
>>Total Capacity = 4*1=4GB.
>>used Capacity = 4GB.
>>Available = 4-4=0. (implies 100% usage. can also go to more than 100%)
>
>
>We should store the actuals in the db with over commit ratio. And rest of
>the values of available memory and used memory can be calculated form
>that.
>So the new method mentioned below looks consistent.
>
>-abhi
>
>>
>>XenServer uses DMC for memory overcommit, to use this feature we have to
>>set the minimum and maximum ram that we want to allocate.
>>The memory used by the VMs can vary between the minimum and maximum. In
>>case of contention they will be allowed to use the minimum memory
>>allocated
>>to them. Minimum memory is the reserved memory which is guaranteed for
>>the VM.
>>
>>New WAY.
>>Total Capacity= 4GB.
>>Values after deploying 4VMs with 1GB in service offering.
>>Allocated per VM = 1GB/ overcommit = 512MB. (This is set as the minimum
>>and 1GB is the maximum.)
>>Used = 4* minimum allocated per vm = 2GB.
>>Available = 4-2= 2GB.
>>Value that is visible to admin as available = Available * overcommit
>>ratio =2*2= 4GB.
>>Now if we decrease the overcommit ratio to 1
>>Available capacity =total - used = 4-2= 2GB. (This 2GB will be made
>>available by the XenServer using DMC.)
>>(we can still deploy VMs in this case )
>>
>>Major differences are
>>1.) In new way we store what we actually allocate in the DB rather than
>>the one in the service offering.
>>2.) All calculations are done based on the actuals.
>>3.) Depending on the overcommit values we scale down and then allocate.
>>
>>Advantages
>>1.) The usage can never go beyond 100% and is independent of changes in
>>overcommit values.
>>2.) We can deploy more VMs.
>>
>>Also please comment if we need to show actuals on the dashboard or the
>>over provisioned values and why.
>>
>>Regards,
>>Bharat.
>>
>>
>>
>>
>>
>