[Glass] Explanation to "too many failed pom_gen scavenges" in this context??

Mariano Martinez Peck via Glass glass at lists.gemtalksystems.com
Mon Mar 7 12:39:22 PST 2016


Also...I do not get the instance count written neither in object log (could
be the bug I mentioned in previous email), nor in the gem file
log...shouldn't I get that? At least I remember getting that once upon a
time.

Thanks!

On Mon, Mar 7, 2016 at 5:11 PM, Mariano Martinez Peck <marianopeck at gmail.com
> wrote:

> BTW Dale.... I think the line of "System *_vmInstanceCounts:* 3"  in
> #installAlmostOutOfMemoryStaticHandler: is wrong and instead it should
> be (System *_vmInstanceCountsReport:* 3)  and it also will fail the
>
>   sort: [ :a :b | (a value at: 2) > (b value at: 2) ]
>
> Was this fixed somewhere after 3.2.9 ???
>
>
> Cheers,
>
>
>
>
> On Mon, Mar 7, 2016 at 4:57 PM, Mariano Martinez Peck <
> marianopeck at gmail.com> wrote:
>
>>
>>
>> On Mon, Mar 7, 2016 at 3:18 PM, Dale Henrichs via Glass <
>> 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
>>
>>
>>> It is also possible that your temp obj cache is filling with objects
>>> that have not yet been connected to the persistent root ...
>>>
>>>
>> mmm OK  I will check this. But now I get this same error in another cron
>> job. Both were running correctly a few weeks/months ago.
>>
>>
>>> If you want to see what's happening with respect to the exceptions that
>>> are being signaleed, you could add logging to MCPlatformSupport
>>> class>>installAlmostOutOfMemoryStaticHandler: ...
>>>
>>>
>> mmmm I am a bit lost there. Which kind of log could I add?
>>
>> Thanks in advance,
>>
>>
>>
>>
>>
>>> Dale
>>>
>>>
>>>
>>> On 03/07/2016 08:35 AM, Mariano Martinez Peck via Glass wrote:
>>>
>>> Hi guys,
>>>
>>> I am running some code that processes a huge csv file and inserts
>>> persistent data to gemstone. This is a GemStone 3.2.9 with 1GB of SPC,
>>> GEM_TEMPOBJ_CACHE_SIZE of 700MB and GEM_TEMPOBJ_POMGEN_PRUNE_ON_VOTE  at
>>> 100.
>>>
>>> What is funny is that my code runs inside commitOnAlmost...
>>>
>>> I have this method:
>>>
>>> FAGemStoneCompatibility >> commitOnAlmostOutOfMemoryDuring: aBlock
>>> threshold: aThreshold
>>>   [
>>>   MCPlatformSupport installAlmostOutOfMemoryStaticHandler: aThreshold.
>>>   aBlock value ]
>>>     ensure: [ MCPlatformSupport uninstallAlmostOutOfMemoryStaticHandler ]
>>>
>>> And this is how I use it:
>>>
>>>                System commitTransaction.
>>> FACompatibilityUtils current
>>> commitOnAlmostOutOfMemoryDuring: [
>>>     *WhateverClass whateverThingThatNeedsMemory.*
>>>                         ]
>>>                         threshold: 10.
>>> System commitTransaction.
>>>
>>>
>>> And even with a threshold of 10...  I am getting a
>>>
>>> *VM temporary object memory is full *
>>> *, too many failed pom_gen scavenges*
>>>
>>>
>>> Any idea what could be going on?
>>>
>>> Thanks in advance,
>>>
>>> --
>>> Mariano
>>> http://marianopeck.wordpress.com
>>>
>>>
>>> _______________________________________________
>>> Glass mailing listGlass at lists.gemtalksystems.comhttp://lists.gemtalksystems.com/mailman/listinfo/glass
>>>
>>>
>>>
>>> _______________________________________________
>>> Glass mailing list
>>> Glass at lists.gemtalksystems.com
>>> http://lists.gemtalksystems.com/mailman/listinfo/glass
>>>
>>>
>>
>>
>> --
>> Mariano
>> http://marianopeck.wordpress.com
>>
>
>
>
> --
> Mariano
> http://marianopeck.wordpress.com
>



-- 
Mariano
http://marianopeck.wordpress.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gemtalksystems.com/mailman/private/glass/attachments/20160307/9ff73b8f/attachment-0001.html>


More information about the Glass mailing list