cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bharat Kumar <bharat.ku...@citrix.com>
Subject Re: Regarding Cpu and memory overcommit feature.
Date Wed, 06 Feb 2013 05:46:27 GMT
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 <Prachi.Damle@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" <bharat.kumar@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.
>> 
>> 
>> 
>> 
>> 
> 


Mime
View raw message