Heap size of Broker in r567764 on Fedora 7

[Andrew Stitcher <as...@redhat.com>]

Running trunk C++:
	perftest --listen --publish
against a trunk version of the c++ broker:
	qpidd -d --worker-threads 1

Every time I run the test it appears that the heap space of the broker
gets bigger, up to a point then it gets smaller again. I think this is
expected as the I think the glibc allocator doesn't try to coalesce and
reclaim allocated and freed memory very often.

However the heap space used never seems to drop below 100Mb This is
derived from a line in /proc/xxx/maps like:
	0060c000-076c7000 rw-p 0060c000 00:00 0         [heap]
Which is just after a heap coalescence in an idle broker and shows usage
of over 110Mb which seems a little high for a broker doing nothing.

Andrew

Re: Heap size of Broker in r567764 on Fedora 7

[Alan Conway <ac...@redhat.com>]

On Tue, 2007-08-21 at 00:59 +0100, Andrew Stitcher wrote:
> Running trunk C++:
> 	perftest --listen --publish
> against a trunk version of the c++ broker:
> 	qpidd -d --worker-threads 1
> 
> Every time I run the test it appears that the heap space of the broker
> gets bigger, up to a point then it gets smaller again. I think this is
> expected as the I think the glibc allocator doesn't try to coalesce and
> reclaim allocated and freed memory very often.
> 
> However the heap space used never seems to drop below 100Mb This is
> derived from a line in /proc/xxx/maps like:
> 	0060c000-076c7000 rw-p 0060c000 00:00 0         [heap]
> Which is just after a heap coalescence in an idle broker and shows usage
> of over 110Mb which seems a little high for a broker doing nothing.
> 
> Andrew
> 

Is that worse than previously? I would expect heap use to have decreased
with AMQBody being moved onto the stack. The google heap profiler shows
us using about 50% of the heap compared to before the change.

Cheers,
Alan..

.