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

[Dale Henrichs via Glass]

On 06/23/2015 06:02 PM, Mariano Martinez Peck wrote:
>
>
> On Tue, Jun 23, 2015 at 1:33 PM, Dale Henrichs 
> <dale.henrichs at gemtalksystems.com 
> <mailto: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!
I've submitted Issue #34 for this[1].

[1] https://github.com/GsDevKit/gsApplicationTools/issues/34
>
>>     *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?
>

I imagine that the memory consumption here is largely related to pages 
in the SPC as those three processes do most of their work in shared 
memory ... I've pinged engineering to see if anyone has additional 
information...

Dale
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gemtalksystems.com/mailman/private/glass/attachments/20150624/a8f2881d/attachment-0001.html>