On 02/29/2012 07:07 PM, Fraser Adams wrote:
Hi All,
I think that we may have stumbled across a potential memory/resource leak.
We have one particular set up where we have a C++ producer client (using
qpid::client - don't ask, it's a long story.....) this writes to a 0.8
broker hosted on the same server. That broker is then federated via a
queue route to amq.match on another (0.8) broker. The queue route is a
source route set up via qpid-route -s
We've been having all sorts of fun and games with respect to
performance, which we've narrowed down to some dodgy networking.
However one of the other effects that we've noticed is that the broker
co-located with the producer client eats memory. The queue for the queue
route is 1GB but qpidd eventually grows to ~35GB and sends the whole set
up into swap.
So with respect to the network problem we're suspecting a dodgy switch
somewhere, what is interesting is that when we checked with ethtool the
NIC was reporting half duplex had been negotiated - ouch!!! hence why we
suspect a dodgy switch somewhere.
Now when the NIC was explicitly set to 100 base/T full duplex our
performance rocketed and the broker on the producer system appears
(touch wood) to have stable memory performance.
What I'm suspecting is that the dodgy network link has been causing
connection drop-outs and the broker is automatically reconnecting (logs
are confirming this) and I'm thinking that there is a resource leak
somewhere during the reconnection process.
https://issues.apache.org/jira/browse/QPID-3447 perhaps? Though I
wouldn't have expected that to cause such a large growth in memory.
Your sure there is no backed up queue anywhere?
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:[email protected]
