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

[Mariano Martinez Peck via Glass]

On Tue, Jun 23, 2015 at 1:33 PM, Dale Henrichs <
dale.henrichs at gemtalksystems.com> wrote:

>
>
> On 06/23/2015 06:51 AM, Mariano Martinez Peck wrote:
>
> Thank you SO MUCH Dale!    So this is what I did for all seaside gems in
> case someone else is interested:
>
>  "This thread is needed to handle the SigAbort exception, when the primary
>  thread is blocked on an accept. Assuming default 60 second
>  STN_GEM_ABORT_TIMEOUT, wake up at 30 second intervals."
>  [
>         | count minutesToForceGemGC |
>         count := 0.
>         minutesToForceGemGC := 30.
>    [ true ] whileTrue: [
>                 (Delay forSeconds: 30) wait.
>                 count := count + 1.
>                 (count \\\ (minutesToForceGemGC * 2)) = 0 ifTrue: [
>                         System _generationScavenge_vmMarkSweep.
>                         Transcript show: 'Gem GC forced'; cr.
>                         count := 0.
>                         ].
>         ].
>  ] forkAt: Processor lowestPriority.
>
>
>  And yeah, it seems to work :)
> And yeah, the GC seems to be super fast :) Good job!
>
> Cool, I'll look at adding this logic to the GemServer scripts ....
>
>
>
Yes, I was about to recommend you that, since the GC seems super fast for
a.. 700MB temp space, and considering it runs every .. 30 mins ,,is more
than fine!


>  *Also.... similar to this great idea, do you have something else in mind
> I can do to minimize memory used when system is mostly "idle" ?*
>
>  I ask because I did not noticed much of a change if I shutdown all
> seaside gems and start them again. However.....if I shut down all stones
> and start them again (with all seaside gems again), then the memory used
> decreases A LOT. While this may be obvious, it is not fully clear to me
> why. As a first thought I would guess the main difference is the SPC.
> However, SPC is a segment/shared and that memory is reserved from the very
> beginning. So I don't expect that to change wether I reset the stone or
> not.
>
>  So...if it is not the SPC.... they are not the seaside gems, they are
> not the admin/reclaim gc (those use very little temp space), what else
> could be such a difference if memory consumption when I reset the stone?
>
>  Have you noticed any differences in the `ps` output? Also do you see the
> memory use grow over time .. even with an idle system?
>
>
I am not sure if it increases with a fully fully idle system, but it does
increase with barely  (only a couple of requests a day) idle system.


> It is very likely that the SPC is the culprit ... the shrpcmonitor
> regularly scans pages in the SPC, while it doesn't touch all of the pages,
> it touches maybe half so that could account for differences between a
> freshly started system and one that has run for awhile... off hand I don't
> know how often it does it's scan ... I think you should be able to plot
> memory consumption as compared to other things going on in the system by
> starting up that statmonitor (use the -A option to statmonitor to collect
> system stats) ...
>


I just did a "ps -aux" after a bit of usage (the barely usage) and then the
comparison after stoping and starting stone again and all seaside gems.
By far, the biggest difference was pgsvrmain which ps showed me like 300MB
and after stone restart was nothing.... The second process that decreased
quite a bit is pagemanager. Also.. the reclaimgcgem decreased quite a bit
too.

Is there a way to decrease those if the system is mostly "idle" ?  anything
interesting here?

Thanks in advance!


>
>
> Dale
>
>


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