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: KVM memory overprovision breaking me
Date Tue, 28 Jan 2014 09:10:46 GMT
Hi Marcus, 

if you want to get what is assigned in the service offering then we can simply disable the
overcommit feature.

Thanks,
Bharat.

On 28-Jan-2014, at 12:37 pm, Marcus Sorensen <shadowsor@gmail.com> wrote:

> They're both very specific. As mentioned, ballooning only works if
> you're basically just making vms for yourself. And even then you have
> to add your own script to make it work, hence my suggestion to enable
> it via agent.properties.
> 
> Again, my main concern is that it messes with the service offering,
> you don't get what you see in the offering. It's downright painful for
> system vms.
> 
> On Mon, Jan 27, 2014 at 11:44 PM, Bharat Kumar <bharat.kumar@citrix.com> wrote:
>> Hi Marcus,
>> 
>> KSM or memory de-duplication on KVM can only be used when the memory pages are identical.
>> IMO this is a huge constraint which is true only for specific use cases. using KSM
to implement overprovisioning
>> will limit this feature to a specific use case and hence memory ballooning was chosen
which is more generic.
>> 
>> Thanks,
>> Bharat.
>> 
>> On 28-Jan-2014, at 11:58 am, Marcus Sorensen <shadowsor@gmail.com> wrote:
>> 
>>> Yeah, I'm a little disappointed that the functional spec doesn't
>>> really address memory deduplication, which is the real version of
>>> overcommit, IMO.  Since it looks like the feature is already fully
>>> implemented, I'm not sure I have much of a leg to stand on in trying
>>> to change it. I'll just patch it out of our builds. Thanks for the
>>> input.
>>> 
>>> On Mon, Jan 27, 2014 at 11:13 PM, Bharat Kumar <bharat.kumar@citrix.com>
wrote:
>>>> Hi Marcus,
>>>> 
>>>> in case of KVM the guest memory is not dynamically adjusted by hypervisor,
this is a hypervisor limitation.  we have documented this in the FS in prerequisites for KVM.
>>>> https://cwiki.apache.org/confluence/display/CLOUDSTACK/CPU+and+RAM+Overcommit
>>>> 
>>>> One way to make this work automatically is to use a script to monitor the
memory pressure in the guest VM and adjust the memory using cgroups.
>>>> one such script is Memory over commit manager.
>>>> more info here http://aglitke.wordpress.com/2011/03/03/automatic-memory-ballooning-with-mom/
>>>> 
>>>> Thanks,
>>>> Bharat.
>>>> 
>>>> 
>>>> 
>>>> On 28-Jan-2014, at 11:23 am, Marcus Sorensen <shadowsor@gmail.com<mailto:shadowsor@gmail.com>>
wrote:
>>>> 
>>>> Yeah, that's not overprovisioning, though. That's scaling. The way
>>>> it's implemented now is just ... provisioning. It allocates exactly
>>>> what's available at the host.
>>>> 
>>>> Also, the vm in your example can't go to 4GB. There is nothing that
>>>> changes it's 'currentMemory' setting. Without a scaling feature it's
>>>> simply always stuck at 2GB.
>>>> 
>>>> On Mon, Jan 27, 2014 at 10:32 PM, Harikrishna Patnala
>>>> <harikrishna.patnala@citrix.com<mailto:harikrishna.patnala@citrix.com>>
wrote:
>>>> Hi,
>>>> I think the way it was done is to guarantee minimum memory to that VM and
upon demand it can get upto the memory defined in service offering.
>>>> Say a vm with service offering 4Gb is deployed with overprovisioing factor
2, we guarantee that vm should get minimum of 2GB (4GB/2) and if that VM is overloaded then
it can get memory unto max 4GB.
>>>> This is what it is showing vm definition
>>>> <memory unit='KiB’>4GB</memory>
>>>> <currentMemory unit='KiB’>2GB</currentMemory>
>>>> "memory unit” is what it can get maximum.
>>>> 
>>>> -Harikrishna
>>>> 
>>>> 
>>>> On 28-Jan-2014, at 7:46 am, Marcus Sorensen <shadowsor@gmail.com<mailto:shadowsor@gmail.com>>
wrote:
>>>> 
>>>> Its an easy fix on the KVM side, just waiting to hear any objections.
>>>> On Jan 27, 2014 6:11 PM, "Nux!" <nux@li.nux.ro<mailto:nux@li.nux.ro>>
wrote:
>>>> 
>>>> On 28.01.2014 00:49, Marcus Sorensen wrote:
>>>> 
>>>> So... I tried to use memory overcommit on KVM this week, and it blew
>>>> up in my face. Apparently it's configured such that if I have a
>>>> Service Offering of 4G, and I set memory overprovisioning to 2:1, the
>>>> guest only actually gets configured with 2G. That's not how
>>>> overprovisioning is supposed to work, IMO.
>>>> 
>>>> Here's a vm definition with a 3:1 mem overprovision setting, which
>>>> ensures that system vms don't work:
>>>> 
>>>> <memory unit='KiB'>262144</memory>
>>>> <currentMemory unit='KiB'>87040</currentMemory>
>>>> 
>>>> Note currentMemory needs to be manually tuned if I ever want the vm to
>>>> use/see more. This is more for live scaling (which is also broken
>>>> because the guest could just rmmod virtio-balloon and see everything).
>>>> 
>>>> I'd like to just rip out the code that is setting ballooning feature
>>>> based on overprovisioning factor, but perhaps there was a reason this
>>>> was done. From my point of view, if I give someone a service offering
>>>> that says 4G, it should provide 4G, and if I can do memory
>>>> deduplication on the backend to overprovision that's up to me to do.
>>>> Overprovisioning should not be a divider on all service offerings.
>>>> 
>>>> 
>>>> Wow! I also thought, heck, KSM & thin qcows for the win! If
>>>> overprovisioning really "works" as you described then it can't possibly be
>>>> used for any commercial offering ...
>>>> This needs to get fixed.. Too late to see this in 4.3?
>>>> 
>>>> --
>>>> Sent from the Delta quadrant using Borg technology!
>>>> 
>>>> Nux!
>>>> www.nux.ro<http://www.nux.ro>
>>>> 
>>>> 
>>>> 
>> 


Mime
View raw message