[ovirt-users] 3.4: VDSM Memory consumption

[Daniel Helgenberger]

Hello Francesco,

-- 
Daniel Helgenberger 
m box bewegtbild GmbH 

P: +49/30/2408781-22
F: +49/30/2408781-10
ACKERSTR. 19 
D-10115 BERLIN 
www.m-box.de  www.monkeymen.tv 

> On 29.09.2014, at 22:19, Francesco Romani <fromani at redhat.com> wrote:
> 
> ----- Original Message -----
>> From: "Daniel Helgenberger" <daniel.helgenberger at m-box.de>
>> To: "Francesco Romani" <fromani at redhat.com>
>> Cc: "Dan Kenigsberg" <danken at redhat.com>, users at ovirt.org
>> Sent: Monday, September 29, 2014 2:54:13 PM
>> Subject: Re: [ovirt-users]    3.4: VDSM Memory consumption
>> 
>> Hello Francesco,
>> 
>>> On 29.09.2014 13:55, Francesco Romani wrote:
>>> ----- Original Message -----
>>>> From: "Daniel Helgenberger" <daniel.helgenberger at m-box.de>
>>>> To: "Dan Kenigsberg" <danken at redhat.com>
>>>> Cc: users at ovirt.org
>>>> Sent: Monday, September 29, 2014 12:25:22 PM
>>>> Subject: Re: [ovirt-users]    3.4: VDSM Memory consumption
>>>> 
>>>> Dan,
>>>> 
>>>> I just reply to the list since I do not want to clutter BZ:
>>>> 
>>>> While migrating VMs is easy (and the sampling is already running), can
>>>> someone tell me the correct polling port to block with iptables?
>>>> 
>>>> Thanks,
>>> Hi Daniel,
>>> 
>>> there is indeed a memory profiling patch under discussion:
>>> http://gerrit.ovirt.org/#/c/32019/
>>> 
>>> but for your case we'll need a backport to 3.4.x and clearer install
>>> instructions,
>>> which I'll prepare as soon as possible.
>> I updated the BZ (and are now blocking 54321/tcp on one of my hosts).
>> and verified it is not reachable. As  general info: This system I am
>> using is my LAB / Test / eval setup for a final deployment for ovirt
>> (then 3.5) in production; so it will go away some time in the future (a
>> few weeks / months). If I am the only one experiencing this problem then
>> you might be better of allocating resources elsewhere ;)
> 
> Thanks for your understanding :)
> 
> Unfortunately it is true that developer resources aren't so abundant,
> but it is also true that memleaks should never be discarded easily and without
> due investigation, considering the nature and the role of VDSM.
> 
> So, I'm all in for further investigation regarding this issue.
> 
>>> As for your question: if I understood correctly what you are asking
>>> (still catching up the thread), if you are trying to rule out the stats
>>> polling
>>> made by Engine to this bad leak, one simple way to test is just to shutdown
>>> Engine,
>>> and let VDSMs run unguarded on hypervisors. You'll be able to command these
>>> VDSMs using vdsClient or restarting Engine.
>> As I said in my BZ comment this is not an option right now, but if
>> understand the matter correctly IPTABLES reject should ultimately do the
>> same?
> 
> Definitely yes! Just do whatever it is more convenient for you.
> 
As you might have already seen in the BZ comment the leak stopped after blocking the port. Though this is clearly no permanent option - please let me know if I can be of any more assistance! 

> -- 
> Francesco Romani
> RedHat Engineering Virtualization R & D
> Phone: 8261328
> IRC: fromani
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/users/attachments/20140929/6679b573/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2035 bytes
Desc: not available
URL: <http://lists.ovirt.org/pipermail/users/attachments/20140929/6679b573/attachment-0001.p7s>