[Webteam] Re: [squeak-dev] What are we leaking in the www.squeak.org process?

Ken Causey ken at kencausey.com
Fri Oct 15 20:05:19 UTC 2010


On Thu, 2010-10-14 at 19:00 -0700, Ken Causey wrote:
> > -------- Original Message --------
> > Subject: Re: [Webteam] Re: [squeak-dev] What are we leaking in the
> > www.squeak.org process?
> > From: Igor Stasenko <siguctua at gmail.com>
> > Date: Thu, October 14, 2010 8:45 pm
> > To: The general-purpose Squeak developers list
> > <squeak-dev at lists.squeakfoundation.org>
> > 
> > 
> > On 15 October 2010 04:10, Ken Causey <ken at kencausey.com> wrote:
> > > Another update with more data conflicting somewhat with my last report:
> > >
> > > Shown by ps: 214560KB RSS
> > > Shown by vmParameters (2,3): 64.6MB/67.4MB
> > >
> > > A discrepancy of some 150MB.
> > 
> > My understanding is, that Squeak VM cannot shrink a memory which were
> > commited (due to peak growth),
> > to give it back to OS.
> > 
> > So, if at some peak, VM comitted 150 MB, and OS sees it as 150M,
> > while VM after GC actually using just 64M.
> 
> No, I don't believe this is true.  The RSS does go both down as well as
> up.  I thought I made that clear in my original comments.
> 
> Although I suppose it is possible that drops in the RSS figure are due
> to paging out to swap.  I'm not sure how to really check that.
> 
> Ken

For example, another data point:

Shown by ps: 167344KB RSS
Shown by vmParameters (2,3): 62.9MB/65.8MB

The process has not been restarted but the RSS has dropped.

Ken

> > 
> > >
> > > Ken
> > >
> > > On Thu, 2010-10-14 at 17:31 -0500, Ken Causey wrote:
> > >> An update as things may not be quite as I originally described them.  It
> > >> seems the values reported by vmParameters 2 and 3 are not as constant as
> > >> I had been lead to believe.  I noticed that just a short while after
> > >> sending the image the RSS had jumped up to 165800KB.  I still had VNC
> > >> open on the image so I checked what is shown there and I see
> > >> 145.6MB/147.7MB so there is still a discrepancy, but not perhaps as wide
> > >> as I indicated.
> > >>
> > >> I also did not mention that in addition to restarting Swazoo every 15
> > >> minutes there is other cleanup that is done once a day related to
> > >> statistics gathering that goes on.  My understanding is that this
> > >> cleanup is meant to return things very close to the starting state.
> > >> Perhaps Janko can comment on that more fully.
> > >>
> > >> Ken
> > >>
> > >> On Thu, 2010-10-14 at 16:55 -0500, Ken Causey wrote:
> > >> > For some time now I've been bugging Janko about the memory usage of the
> > >> > process that serves http://www.squeak.org/ .  I've gathered a bit more
> > >> > info today and I'd like to see if anyone here has any thoughts.
> > >> >
> > >> > First while there is some variation most of the Squeak processes that
> > >> > serve squeak.org sites (source.squeak.org, map.squeak.org,
> > >> > wiki.squeak.org) have a more or less constant and reasonable memory
> > >> > usage.  Let me clarify that what I am talking about here is RSS
> > >> > (Resident Set Size) as reported by ps/top on Linux.  Swiki as the oldest
> > >> > of the group is the clear winner at just under 30MB, squeakmap is around
> > >> > 47MB, and source.squeak.org is around 59MB.
> > >> >
> > >> > In contrast immediately after starting it www.squeak.org is using about
> > >> > 70MB and it grows from there.  Now a bit more than an hour since the
> > >> > last restart it is already up to about 85MB.  I have seen it over 300MB
> > >> > before, and it commonly uses 140-250MB.  It doesn't simply grow and
> > >> > grow, it does shrink occasionally.
> > >> >
> > >> > First, there is a known issue with Swazoo that it does not close sockets
> > >> > correctly and Janko has addressed this by having Swazoo automatically
> > >> > restarted every 15 minutes.  So using netstat for example I can watch
> > >> > the socket count for the process continually grow and then it drops to
> > >> > zero and this repeats.  In contrast for all the other process (all
> > >> > running some variation of Kom/Comanche I believe) I'm hard pressed to
> > >> > even catch a single open socket at any time (not counting the listener
> > >> > that is).
> > >> >
> > >> > Secondly, since I've been complaining about this issue for a long time
> > >> > Janko has running a little morph that shows current memory usage.  What
> > >> > this shows is the values of SmalltalkImage current vmParameterAt: 2 and
> > >> > 3.  These numbers are quite stable.  For example at this moment these
> > >> > are 68.3MB and 71.0MB respectively.  Whereas ps shows the RSS at
> > >> > 85752KB.  Where is the discrepancy here?
> > >> >
> > >> > My current theory is that the vmParameters are not reflecting incidental
> > >> > memory use by the VM and plugins or that we are simply misinterpreting
> > >> > the values.  Is it possible that Swazoo is failing to release something
> > >> > that is causing the VM to use more memory than it should?
> > >> >
> > >> > Note that the same VM is used by all of these processes.  It is
> > >> >
> > >> > 3.8a-1 #1 Sun May  1 19:46:46 EDT 2005 gcc 3.3.5
> > >> >
> > >> > Yes, I know it's old, but 'if it ain't broke, don't fix it' has been the
> > >> > motto and with the possible exception of Swazoo/www.squeak.org it has
> > >> > been working wonderfully for a long time now.
> > >> >
> > >> > Your thoughts would be greatly appreciated,
> > >> >
> > >> > Ken
> > >>
> > >> _______________________________________________
> > >> Webteam mailing list
> > >> Webteam at lists.squeakfoundation.org
> > >> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/webteam
> > >
> > >
> > >
> > >
> > >
> > 
> > 
> > 
> > -- 
> > Best regards,
> > Igor Stasenko AKA sig.
> 
> 
> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 190 bytes
Desc: This is a digitally signed message part
Url : http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20101015/334acd5b/attachment.pgp


More information about the Squeak-dev mailing list