[Glass] Explanation to "too many failed pom_gen scavenges" in this context??
Dale Henrichs via Glass
glass at lists.gemtalksystems.com
Mon Mar 7 14:07:37 PST 2016
On 03/07/2016 11:57 AM, Mariano Martinez Peck wrote:
>
>
> On Mon, Mar 7, 2016 at 3:18 PM, Dale Henrichs via Glass
> <glass at lists.gemtalksystems.com
> <mailto:glass at lists.gemtalksystems.com>> wrote:
>
> Mariano,
>
> The handler for AlmostOutOfMemory relies on being able to resume
> after a successful commit, but a GemStone vm will sometimes cross
> the threshol in the middle of a "random C code" called by a
> primitive ... in these cases we have to defer the signalling of
> AlmostOutOfMemory until we reach a point where we can safely
> resume .... The implication is that depending upon the details of
> your call it is possible to physically run out of memory before
> the deferred signaling can take place ...
>
> If you lower the threshold, you should be able to find a limit
> that gives you room to finish the memory hungry primitive call and
> get the deferred AlmostOfOfMemory exception signalled.
>
>
> Yes,*but I am already running the threshold with 10% with a 700MB temp
> space*... how less than that should it be? mmmm
>
This implies that you are doing something that consumes quite a bit of
memory while in a primitive .... a stack trace would be helpful ... but
it is likely that the only way to get a stack trace in this situation is
to set the env vars as suggested by Richard ...
Dale
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gemtalksystems.com/mailman/private/glass/attachments/20160307/04f18852/attachment.html>
More information about the Glass
mailing list