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

John M McIntosh johnmci at smalltalkconsulting.com
Wed Oct 20 19:21:59 UTC 2010


Ahhhh.  

All the source code exists, so let's look. Since WikiServer had to run with 50MB and people wanted to upload/download 50MB documents via the seaside server, I've had to chase this issue at length.

So first you must figure out what binary and when it was  created because the source code does change from time to time. 
Second   you should review the documentation you possibly could find at. 
http://isqueak.org/sqAllocateMemory
http://isqueak.org/sqGrowMemoryBy
http://isqueak.org/sqShrinkMemoryBy

In looking at the unix code base (current) which might no have relationship to whatever old binary you are running you will find 
sqUnixMemory.c -- dynamic memory management

Assuming you are using the MMAP logic which is choose or not based on startup parms, then it does
heap= mmap(0, heapLimit, MAP_PROT, MAP_FLAGS, devZero, 0)

Please note the 
/* Note:
 * 
 *   The code allows memory to be overallocated; i.e., the initial
 *   block is reserved via mmap() and then the unused portion
 *   munmap()ped from the top end.  This is INHERENTLY DANGEROUS since
 *   malloc() may randomly map new memory in the block we "reserved"
 *   and subsequently unmap()ped.  Enabling this causes crashes in
 *   Croquet, which makes heavy use of the FFI and thus calls malloc()
 *   all over the place.
 *   
 *   For this reason, overallocateMemory is DISABLED by default.
 *   
 *   The upshot of all this is that Squeak will claim (and hold on to)
 *   ALL of the available virtual memory (or at least 75% of it) when
 *   it starts up.  If you can't live with that, use the -memory
 *   option to allocate a fixed size heap.
 */

But this of course thru bitter experiences has been a moving target and your binary might have different behaviour, but let's assume you run the current one which will never give memory once seized. So if you take the default of allocating 512MB of memory then the Squeak VM gets 512MB+  

Now for the end of memory pointer we just move that pointer within the block of mmap.   Also past the end of squeak VM oops memory we 
allocate memory for the CG to do the compacting run, but the numbers reported by the VM parms just indicate where the end of oops memory is, not the amount of mmap memory, which is a constant set by default or your override. 

Now from the Operating systems viewpoint and I'll only talk about BSD related ones, linux may or may not be the same you would have to ask, is that you might ask for 2 trillion bytes but if you only use 200MB then that is what will show. You must touch the memory to actually make the operating system understand you aren't lying. Hence on my mac here it cheerfully says I've 184.98 GB of virtual memory allocated, but lies are lies given it only has a 100GB hard disk.  Mmm actually it only has < 3GB of memory actually used. 

So where DOES the memory monster come from? Well from my past experiences with WikiServer I know that the HTTP servers are setup to SUCK in complete files.   Got a 100MB MC file? Well you will need 100MB or 200MB to make that pass thru the image.

I note you can configure the various http servers to say they should do streaming, but I found the various authors actually have never done an end to end test so even if they promise to stream which you set on the HTTP server, they accidentally do things like x := "stream contents foobar"  Although in the summer of 09 I did manage to fix both http servers and feed results back to authors so that I could upload or download a 50MB file to wikiserver.

To test this you should configure a VM with a hard upper memory limit. Likely via a command line parm asking for just a 50MB block of memory? Then pass thru a MC project that requires 50MB file and see where in the http server or seaside or mc that it's making an in-memory copy of the entire file. 

I note once the squeak VM has touched the 200MB the operating system will say that 200MB are used by the app, even if the VM now is only using 40MB.  The other 160MB (actually less) is now idle....   The operating system virtual memory logic will at some point if needed apply the rules about recently used pages to decide to push those pages to some backing store in order to free up the RAM page for use by someone who has more immediate needs.  

Noting that on this mac, the Squeak VM running says 38.9 MB in use, 286.9MB virtual memory in use. Yet I know I asked for 512MB so it doesn't even report the fact it should be 512+ correctly either. But this might be an optimization and it's decided that it could supply 286.9-38.9 immediately 

Mmm foo := ByteArray new: 200*1024*1024
Ya, 236.1 mb,   414.9mb Virtual memory.   203.01 GB total... 

I'd go check your httpserver configuration for streaming, then see who is sucking in entire MC files in a go.. 


On 2010-10-19, at 10:35 PM, Ken Causey wrote:

> To add a bit more data to this.  I surveyed the rest of the VM
> Parameters.   (1-25, above 25 I was getting primitive failures and I
> don't believe any of those are relevant, let me know if I am mistaken.)
> And I can't find any data there that explains the discrepancy reported
> between VM Parameter 3 (end of memory) and the resident set size of the
> process as reported by the operating system.
> 
> Ignoring those entries that are clearly counts of GC iterations and GC
> runtimes and such all of the rest of the values that seem like they
> might be related to memory usage summed up does not come close the
> current discrepancy of about 70MB.
> 
> I would really really appreciate some guidance here.
> 
> Ken

--
===========================================================================
John M. McIntosh <johnmci at smalltalkconsulting.com>   Twitter:  squeaker68882
Corporate Smalltalk Consulting Ltd.  http://www.smalltalkconsulting.com
===========================================================================




-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3829 bytes
Desc: not available
Url : http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20101020/5547b058/smime.bin


More information about the Squeak-dev mailing list