[squeak-dev] What is meant by 'shrink' in the VM parameters?

Ken Causey ken at kencausey.com
Fri Oct 22 21:48:03 UTC 2010


On Fri, 2010-10-22 at 13:40 -0700, Colin Putney wrote:
> On Fri, Oct 22, 2010 at 1:31 PM, Ken Causey <ken at kencausey.com> wrote:
> > Thanks for the info John.  We'll take this and watch things for a while.
> >
> > You are quite probably right about my reading too much into the RSS
> > value.  I've felt like on the occasions when the RSS does go down that
> > it is because it is moving into swap.  What has triggered my concern is
> > when free memory is down to single digit megabytes and swap is half
> > used.
> 
> Hi Ken,
> 
> Would you remind us what the original problem was? If I understand
> your recent messages on the subject, it seems that a) Squeak isn't
> using large amounts of memory and b) the memory used isn't creeping up
> over time. Is it just that the RSS is significantly larger than what
> the VM reports it's using for the object memory, and you're wondering
> why the kernel leaving stuff paged in?
> 
> Colin

This is a good question as I am bouncing all over the place here.

This really starts with my concern about our limited available
resources, in this case a lot of services in not a lot of RAM.  Judging
from the output of ps  the www.squeak.org process appears to be a major
offender.  So that's where this starts and ultimately where it ends.
I'm not too concerned about occasional peaks in memory usage, I'm more
concerned with the long term level.

So from there, on the operating system side, I perceive large RSS values
that seem to be always increasing and rarely decreasing.  From the
webteam's very reasonable view, based on what the VM reports, they see
occasional peaks but a reasonable, if a little high, base level of
memory usage, considerably below the RSS values I see.

At that point I then begin to try to figure out why this discrepancy
occurs.  My first, probably incorrect thought, was that the VM
statistics were reporting only part of the memory costs, the garbage
collected heap, and that the VM internally or a plugin was using extra
memory, possibly as a result of a mistake or unusual usage in the code
for the website.  I now think this is almost certainly wrong.

Next I begin to suspect there is something wrong in the memory handling
of the VM such that it fails to return memory back to the OS even when
it shrinks the garbage collected heap.  At the moment, given the data
that I have seen, this still seems to be the case.  But John has
reasonably argued that it's not this simple, that the OS can reclaim the
memory and if it doesn't appear to be doing so right now it will at the
point the memory is needed.  And he has pointed to some places I can
look for evidence of this as well as suggestions on diagnosing what is
being used in the peak memory instances.

The status at this point is that we will watch things with this
information in mind and perhaps come back with more questions or
observations.

I can at least report a couple of changes in the image that have
resulted from all this observation.  One of these was a URL, related to
internal statistics, that robots should not have been able to access
primarily because of the cost of generating the content; this has now
been closed.

Thanks,

Ken
-------------- 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/20101022/bf135c55/attachment.pgp


More information about the Squeak-dev mailing list