[Glass] RcIdentityBag holding deleted objects via instVar "components"?

Mariano Martinez Peck via Glass glass at lists.gemtalksystems.com
Thu Aug 27 06:43:38 PDT 2015


On Thu, Aug 27, 2015 at 7:10 AM, Otto Behrens <otto at finworks.biz> wrote:

> Can you tell if we need a workaround? We have a big problem with
> seaside service gems eating up RAM:
> GEM_PRIVATE_PAGE_CACHE_KB = 960KB;
> GEM_TEMPOBJ_CACHE_SIZE = 400000KB;
> GEM_TEMPOBJ_MESPACE_SIZE = 0KB;
> GEM_TEMPOBJ_OOPMAP_SIZE = 0;
> GEM_TEMPOBJ_SCOPES_SIZE = 2000;
> GEM_TEMPOBJ_POMGEN_SIZE = 0KB;
> GEM_TEMPOBJ_POMGEN_PRUNE_ON_VOTE = 50;
> GEM_TEMPOBJ_POMGEN_SCAVENGE_INTERVAL = 1800;
> STN_PRIVATE_PAGE_CACHE_KB = 2000KB;
> SHR_PAGE_CACHE_SIZE_KB = 2000000KB;
>
>
Hi Otto,

I think in your case it was something related to the processes you called
from System performOnServer: wasn't it?
400MB of TEMP space doesn't seem much. And I imagine you do not have that
many service VMs. What about the seaside VMs temp space?

What I explain below is just MY understanding. For the real and precise
words you should read the thread were we discuss this.
Anyway...what I found out reading the docs is that the mark and sweep in
the temp space of a gem is run ONLY upon memory pressure. So imagine it
runs (I am doing an example, don't know exactly when) only when temp space
reaches 90% of used. So if you have gems running whose temp space is
occupied a 70% or a 80% or .. they won't be mark and sweeped until they
reach that 90%. So if the gems are not used much, they can be like that for
many hours or days and so they may use unnecessary memory.

So the workaround we found with Dale is to simply run mark and sweep (this
is very very fast so no impact) every 1 minute or so. I am doing this for
all my seaside gems. That way, I found out that I could minimize memory
usage for idle gems.

The thread in question is: "GC on Gems only fired when temp space is over?"

Good luck,




> Thanks
>
> On Wed, Aug 26, 2015 at 6:40 PM, Mariano Martinez Peck via Glass
> <glass at lists.gemtalksystems.com> wrote:
> >
> >
> > On Wed, Aug 26, 2015 at 12:34 PM, itlists at schrievkrom.de
> > <itlists at schrievkrom.de> wrote:
> >>
> >> Am 26.08.2015 um 16:26 schrieb Mariano Martinez Peck:
> >>
> >> >
> >> > BTW.... I also found that Gemstone by default does NOT enable native
> >> > code generation (JIT). I do enable it in all my gems and the
> difference
> >> > in performance is huge. So you may want to enable if you don't have it
> >> > ;)   (GEM_NATIVE_CODE_ENABLED=TRUE)
> >> >
> >>
> >> Reading the documentation I think, that this is enabled per default
> >> (SysAdminGuide 3.2 page 278 - default = 2 means jit enabled)
> >>
> >
> >
> > OK, it changed then between gemstone 3.1 and 3.2.
> > If you tell me the SPC and temp space config I can tell you if it would
> make
> > sense a workaround we did with Dale so that "idle" gems use less memory.
> >
> >
> > --
> > Mariano
> > http://marianopeck.wordpress.com
> >
> > _______________________________________________
> > Glass mailing list
> > Glass at lists.gemtalksystems.com
> > http://lists.gemtalksystems.com/mailman/listinfo/glass
> >
>



-- 
Mariano
http://marianopeck.wordpress.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gemtalksystems.com/mailman/private/glass/attachments/20150827/7bad9a0d/attachment.html>


More information about the Glass mailing list