[Glass] GC on Gems only fired when temp space is over?

[Dale Henrichs via Glass]

On 06/19/2015 02:28 PM, Mariano Martinez Peck via Glass wrote:
> Hi guys,
>
> I wanted to know if the following assumption is correct... Imagine I 
> have a stone/gems that I do not use frequently. There is 1 stone and 4 
> seaside gems. I do understand that when local temp memory of a gem is 
> running out of space, a scavenge is done so that young objects can 
> die, then move survivors, maybe flash out to disk persistent objects 
> not referenced anymore etc etc.  Now.. imagine that I have a .. .700MB 
> temp object space. And since I have 4 gems, I may randomly use a 
> different one for each request (I have no session affinity). So 
> imagine that now my temp space for my gems are all around 500MB. The 
> memory is not yet filled and there is yet some more space.
>
> The question is...imagine I do not use this stone/gems for some 
> time...a couple of days. The question is...are these 500MB of memory 
> retained by the gems until I use it again and I run out of space? 
> Isn't the scavenge run every some time besides the "run on running out 
> of memory that would trigger a scavenge"?
scavenges and mark sweep are only triggered under memory pressure, so it 
is possible for idle gems to consume "too much memory"
>
> What things could I do here to improve this scenario?
>
> 1) make temp space smaller..but that would impact when I DO use it
It is a good question as to why you need such a large TOC ... if your 
working set occasionally balloons to require that much space then you 
need that much space ...
> 2) maybe use session affinity so that at least I fill up less gems? 
> (if there are little concurrent sessions)
>

You could schedule a periodic scavenge and mark sweep in your seaside 
vms ... Once an hour or so would make sure that your idle seaside gems 
are using the bare minimum of memory ... it may tak a mark sweep for the 
vm to return memory pages ... BTW, I assume that you are running on 
linux. On the mac the full memory footprint is allocated in memory ...

Dale