qpid-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gordon Sim <g...@redhat.com>
Subject Re: C++ broker memory leak in federated set-up???
Date Fri, 09 Mar 2012 14:22:42 GMT
On 03/09/2012 10:04 AM, Fraser Adams wrote:
> I don't suppose anyone has had any more thoughts on this.
>
> Unfortunately sorting out our network problem hasn't resolved this
> issue, it does take a lot longer for the broker memory to grow but
> unfortunately it still does.

Can you (or have you) tracked the queue depth, connection and session 
stats for the broker exhibiting the problem? Anything you can think of 
that might correlate with the rate of growth (e.g. does it look like its 
per message)?

> As I say below we've got a 0.8 qpid::client producer delivering to
> amq.match on a broker co-located on the same host which is federated to
> another 0.8 broker (all brokers are c++) via a source queue route.

That is all that's happening on the problem broker?

> One weird thing: As an experiment we kept the general topology the same
> but we moved the first broker on to its own host "just to see", so we've
> got the producer on one host writing to amq.match on a broker now on a
> different host with that broker federated to the core broker as before.
> We've had that running for days now and the brokers all seem to be
> stable!!!
>
> Has anyone seen circumstances that could cause brokers to appear to leak
> memory when co-located with a producer but be fine when run on a
> separate host??

No.

> I don't believe that there are any significant differences in the
> dependent libraries on each host, but I couldn't swear to it is anyone
> aware of stability issues say with particular versions of boost and qpid
> or indeed any other library.
>
> Annoyingly I've never noticed things like this in my set up at home,
> just at work where it matters more and I've got deadlines to meet :-(
>
> Can anyone think of a good way to "profile" our hosts to verify that
> they should be able to run qpid with no issues? I always build from
> source at home (that has its own issues on Ubuntu!!!!) but at work I
> believe qpid had been installed from RPMs I'm not clear on the
> provenance of the RPMs though I'm a bit suspicious of them they don't
> appear to have many dependency checks (for example it didn't barf when
> SASL wasn't present but that seems necessary even with --auth no).
>
> So one possibility for the carnage I'm seeing is some hosts might have
> slightly different versions of dependent libraries hence why I'd like to
> know in a systematic manner what to check for.

rpm -qv <name> will give you the versioned name of the rpms which may 
shed some light...

I can't think of any known bug that could explain this. Its just 
possible that some combination of versions on federation result in 
mismatched expectations I suppose.

> On a related note is anyone aware of any differences in behaviour
> relating to hardware/chipset? All of our hosts are running RHEL but they
> are a mix of hardware - all Intel but varying numbers of cores and
> chipsets.

Nothing that should cause leaks... are you running any RHEL6?

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org


Mime
View raw message