qpid-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Keith Chow" <keith.c...@xml-asia.org>
Subject Re: Java M3 Qpid broker memory consumption
Date Mon, 03 Nov 2008 09:55:42 GMT

We were using auto-acknowledge with the test setup.

Broker heap size: 8gb. jmap shows most of the heap were consumed by byte

 num     #instances         #bytes  class name
   1:        419537      5866139296  [B
   2:          14619        121224752  [I
   3:            9753         39901232  [Ljava.util.HashMap$Entry;
   4:         762581         36603888
   5:         186553         31796120  [C
   6:         199897         27185992

(Full histogram is included as attachment)

Running jmap's heapdump through a profiler showed MemoryMessageStore and
InMemoryMessageHandle were holding huge map of messages (3GB+ and 1GB+).
This result was somewhat expected since we have not yet configured any max
message age, max queue depth, etc. and some of the clients were slower than
the rest. But the strange thing is we think we also saw high memory usage
with mostly empty queues but forgot to take a heap dump for analysis.

Is there an easy way to set global limit for all queues by broker config?
What is the recommend way to deal with slow or fluctuating client using qpid



On Mon, Nov 3, 2008 at 12:16 AM, Robert Greig <robert.j.greig@gmail.com>wrote:

> 2008/11/1 Keith Chow <keith.chow@xml-asia.org>:
> > With broker running close to heap limit, jconsole showed none of the
> queues
> > has any message built up. So we were wondering what could be referencing
> > these uncollectable objects in memory. Profiling the broker is the next
> item
> > on our checklist. Has anyone experience similar issue with the java
> broker?
> Are you using transactional sessions or auto ack?
> One thing that would be useful to help debug this would be to run jmap
> on the process to extract a histogram of the classes, e.g.
> jmap -histo <pid of broker>
> jmap is provided as part of the JDK. This is quicker and simpler than
> full profiling. If you can send the output to this mailing list, I am
> sure someone will be able to offer some insight.
> If that doesn't help, you can use jmap -dump:format=b to extract a
> heap dump then the mat tool (http://www.eclipse.org/mat/) is an
> excellent free tool that is particularly good for tracking down
> potential leaks.
> Thanks,
> Robert

View raw message