Re: Outrigger memory leak?

Greg Trasuk wrote:
> Hi Dan:
>
>       Thanks for responding; see interspersed comments.
>
>       I noted your web page entry regarding Blitz's caching strategy, and the
> fact that running with reduced heap size will subvert it, so you have to
> match the cache size to heap size.  However I can't see any mention of a

Yes, the idea is that you decide how much heap you can afford and then
tweak Blitz to work within that limit.

> similar requirement with Outrigger.
>

To the best of my knowledge there isn't one.  Blitz has the ability to
swap/page entry's hence it's cache driven architecture - Outrigger
doesn't do this stuff and thus has no knobs to tweak in this respect.

>       I take it you haven't seen this type of thing before (at least with
> Blitz)?
>

When I have it's been due to a genuine leak! :)

Actually I've seen a few cases where the permanent generation gets
exhausted due to classloader usage in certain apps - never seen that on
Blitz though and I suspect the way it does things means that won't be a
problem (I also suspect Outrigger would be similar in that regard).  It
might be worth giving your Harvester/Outrigger plugin a check though as
that may be causing issues.

I routinely run soak and thrash tests to spot leaks before I do a
release and I use visual gc to monitor for that stuff and a profiler if
I think there's a leak that needs isolating.

> Cheers,
>
> Greg.
>
> On Wed, 2007-01-03 at 14:01, Dan Creswell wrote:
>> Gregg Wonderly wrote:
>>> Greg Trasuk wrote:
>>>>         Am I missing something in the configuration?  The problem is
>>>> independent of whether Outrigger is run under Harvester or from the
>>>> Launch-All script in the starter kit.  I haven't found any other bug
>>>> reports, and I find it hard to believe I've found a bug in a mature
>>>> product.  Any suggestions?
>>> Can you try the same application with Blitz to see if there is any
>>> difference?
>>> I'd guess that you are not using enough heap.  Are you configuring
>>> -mx512m on
>>> the command line, or how are you starting the JVM that you think has a
>>> 512M heap?
>>>
>> Well, I was thinking about that tactic myself but you'd need to setup
>> Blitz's cache sizes and stuff to make sure it all fits into available
>> memory.
>>
>> Otherwise you could see what looks like a leak but is just being
>> provoked by mis-configuration.
>>
>> I can help out with that but:
>>
>> "the Outrigger instance runs out of heap after
>> about 2100 iterations with a payload size of 250e3 bytes."
>>
>
> Betraying my engineering roots; read the above as 250,000 bytes.

Ah, okay.  Are you running persistent or transient Outrigger?

>
>> I wasn't sure if that is a size in hex or a typo?????
>>
>> It could be heap but I'm not clear why as a quick look at the code
>> suggests there's not a huge number of entry's lying around in the space
>> at any moment.  Unless of course we've got some backlog of entry's
>> forming somehow which I didn't think was likely for this case.
>>
>
> That's exactly my issue; the Space is being used for communications
> rather than storage, so I would expect very little sustained memory
> usage, no matter how big the entries are.  I'd expect the VM to grow
> (i.e soak memory from the operating system) as needed for burst
> capacity, but the actual heap used should stay relatively small.
>

Okay, well the only way to get the backlog is for takers to be slower
than writers which didn't seem probable with your simple test case.

Dan.

===========================================================================
To unsubscribe, send email to [email protected] and include in the body
of the message "signoff JAVASPACES-USERS".  For general help, send email to
[email protected] and include in the body of the message "help".

To view past JAVASPACES-USERS postings, please see:
http://archives.java.sun.com/archives/javaspaces-users.html