[ovirt-users] VM "hot" RAM memory decrease

[nicolas at devels.es]

Hi Martin,

I do, I'm attaching it. I merged the full day's log into one. 
Significant hours start at 11:24:57 (log time). The interesting machine 
is called jbaspre01, and as per what I can deduce, the values in log are 
correct (it never goes under the threshold of 1GB, which is its 
minimum). However, my colleagues and I are 100% sure we saw this machine 
having about 600K KiB when running top.

This machine has:
Memory size: 8196 MB
Minimal guaranteed memory: 1024 MB

If you need additional information don't hesitate to ask.

Regards.

El 2017-03-29 09:44, Martin Sivak escribió:
> Hi Nicolas,
> 
> KiB Mem tells you how much memory the host has. I am actually more
> interested in the VM. Do you still have the mom.log from the time this
> happened? We keep the logs for some time (they are rotated).
> 
> Best regards
> 
> Martin
> 
> On Wed, Mar 29, 2017 at 10:28 AM,  <nicolas at devels.es> wrote:
>> El 2017-03-28 15:33, Martin Sivak escribió:
>>>> 
>>>> min guaranteed should be respected, adding mom maintainer Martin
>>> 
>>> 
>>> I can't really help without the mom.log and the virsh dumpxml output
>>> of that VM in the final state (all memory ballooned).
>>> 
>>> Min guaranteed should be respected, but the question is how the
>>> physical memory was measured (which number from top was used).
>>> 
>>> --
>>> Martin Sivak
>>> SLA / oVirt
>>> 
>> 
>> Hi Martin,
>> 
>> I tried to reproduce the issue again and I was unable to. I had a host 
>> with
>> ~90% of RAM utilization and in mom.log I could see that ballooning was
>> indeed happening, but I couldn't see a VM going under its minimum 
>> guaranteed
>> threshold (at least not significantly).
>> 
>> On top, I was using the 'KiB Mem' value to compare. I know this is in 
>> KiB
>> and that oVirt has its values as MB in the webadmin, but when I sent 
>> this
>> message the difference was quite more significant (1024MB of minimum
>> guaranteed and about 640K KiB on the VM).
>> 
>> It's also true that meanwhile we upgraded from 4.0.2 to 4.1.1 and this 
>> time
>> I couldn't reproduce it anymore.
>> 
>> If at some point I am able to reproduce it again, I'll send detailed 
>> logs of
>> the issue.
>> 
>> Thanks.
>> 
>> 
>>> On Tue, Mar 28, 2017 at 4:29 PM, Michal Skrivanek
>>> <michal.skrivanek at redhat.com> wrote:
>>>> 
>>>> 
>>>>> On 27 Mar 2017, at 23:15, Nicolás <nicolas at devels.es> wrote:
>>>>> 
>>>>> Hi,
>>>>> 
>>>>> I don't really know if this question is suitable on this list, as I
>>>>> doubt it's an oVirt bug, neither I know if it shall be considered a 
>>>>> bug.
>>>>> 
>>>>> We recently run a VM on a host that was memory over-used (around 
>>>>> 80% of
>>>>> usage). The VM booted correctly, then we run "top" and saw how 
>>>>> physical RAM
>>>>> started decreasing every two seconds. At first it was 4GB, then 
>>>>> less and
>>>>> less until it stabilized at around 600MB.
>>>>> 
>>>>> Based on this (correct me if I'm wrong), we believe this is an 
>>>>> effect of
>>>>> having this VM with ballooning enabled, as it does exactly this: It
>>>>> adds/removes RAM depending on host decision. Thing is that this VM 
>>>>> had a
>>>>> minimal guaranteed RAM of 1GB, so even if this happened due to 
>>>>> ballooning,
>>>>> I'm not sure if it should have honored the minimum guaranteed RAM.
>>>>> 
>>>>> When this happened, we run a 'ps' to see with what options the qemu
>>>>> process was invoked, and parameters seemed correct (that's why I 
>>>>> don't know
>>>>> if it should be posted here or even if it's a bug).
>>>> 
>>>> 
>>>> It does belong here, it’s a different component doing it 
>>>> “externally” to
>>>> the qemu process- mom.
>>>> 
>>>>> 
>>>>> Is this the expected behavior?
>>>> 
>>>> 
>>>> min guaranteed should be respected, adding mom maintainer Martin
>>>> 
>>>> Thanks,
>>>> michal
>>>> 
>>>>> 
>>>>> Thanks.
>>>>> _______________________________________________
>>>>> Users mailing list
>>>>> Users at ovirt.org
>>>>> http://lists.ovirt.org/mailman/listinfo/users
>>>>> 
>>>>> 
>>>> 
>> 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ballooning.tar.gz
Type: application/x-gzip
Size: 394956 bytes
Desc: not available
URL: <http://lists.ovirt.org/pipermail/users/attachments/20170329/2657f6a1/attachment-0001.gz>