[Glass] Explanation to "too many failed pom_gen scavenges" in this context??
Dale Henrichs via Glass
glass at lists.gemtalksystems.com
Mon Mar 7 13:49:24 PST 2016
You are not getting a report written to the object log or gem log
because the code `System _vmInstanceCount: 3` is obviously not being
triggered ...
It used to be (back in 2.4 days) that instance count reports were
unconditionally written to the gem log, then somewhere along the way
that behavior was changed in favor of the environment variables that
Richard mentions ... so those env vars need to be set in the shell
before you start your netldi so that they'll be available to the gems
and then when you get a 4067 error, the instance count information will
be written to the gem log ..
Dale
On 03/07/2016 01:28 PM, Mariano Martinez Peck wrote:
> Dale, this is the gem log I get:
>
>
> topaz>
> topaz> display oops
> topaz> iferror where
> topaz> login
> successful login
> fileformat is now utf8
> sourcestringclass is now Unicode16
> topaz 1>
> topaz 1> run
>
> Transcript disableLoggingToObjectLogForSession.
> Transcript enableLoggingToGemLogFileForSession.
> 12350651905 asObject sessionId: ( (System descriptionOfSession:
> System session) at: 10 ).
> System commit.
> System _cacheName: (#BackgroundProcess asString, 12350651905 asString ).
> *12350651905 asObject runInForeground*
> %
> -----------------------------------------------------
> GemStone: Error Fatal
> VM temporary object memory is full
> , too many failed pom_gen scavenges
> Error Category: 231169 [GemStone] Number: 4067 Arg Count: 1 Context :
> 20 exception : 20
> Arg 1: 20
> topaz > exec iferr 1 : where
> WHERE can't be used prior to logging in.
> topaz>
> topaz>
>
>
> This is a "background job" gem and the code is actually invoked via
> "*12350651905 asObject runInForeground".*
> *
> *
> Anyway, as you can see, there is NOTHING printed in the gem log, nor
> there is in the object log. So I cannot even get a list instances...
>
> Any clues?
>
> Thanks
>
>
>
> On Mon, Mar 7, 2016 at 5:39 PM, Mariano Martinez Peck
> <marianopeck at gmail.com <mailto:marianopeck at gmail.com>> wrote:
>
> 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 <mailto: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 <mailto:marianopeck at gmail.com>> 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
>
> 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 list
>> Glass at lists.gemtalksystems.com
>> <mailto:Glass at lists.gemtalksystems.com>
>> http://lists.gemtalksystems.com/mailman/listinfo/glass
>
>
> _______________________________________________
> Glass mailing list
> Glass at lists.gemtalksystems.com
> <mailto: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
>
>
>
>
> --
> Mariano
> http://marianopeck.wordpress.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gemtalksystems.com/mailman/private/glass/attachments/20160307/52a486ad/attachment-0001.html>
More information about the Glass
mailing list