Hello Doug,

>> No, you have it backwards.  With Ruby, the shared portion between
>> processes ends up being quite small.  The Ruby interpreter itself is
>> pretty lightweight, and that is the only code that is shared.  All of
>> the code that is loaded afterwards is duplicated per process.  So the
>> RSS of each process ends up being within a few mb of the total RAM
>> usage, approximately.

DB> ah, you're right, i sometimes forget that the requires are at runtime.

DB> from what eric mentioned earlier, it sounds like fcgi is spawning new
DB> ruby processes instead of forking from a master ruby process. my fcgi
DB> knowledge is pretty rusty, but if there was a way to do the fork model,
DB> then we could get fcgi rails installs to use less memory.  that said,
DB> since it's fcgi, you're already using a lot less memory, since you're
DB> running a handful of rails fcgi processes fronted by a pool of httpds,
DB> versus the normal cgi model where each httpd loads and runs their own
DB> cgis.  so maybe it's a case of diminishing returns...

How should a forking modell help with memory here ?

The first time you get a GC run (and that happens very often) ruby walks
the whole memory and sets flags in data and code (ruby code nodes are also
collected by the GC). At this time the MMU of the CPU will do
a copy on write. So only if you have a lot of large strings or
read only arrays then you will win something. But i doubt that this is
the usual case.

-- 
 Best regards,                        emailto: scholz at scriptolutions dot com
 Lothar Scholz                        http://www.ruby-ide.com
 CTO Scriptolutions                   Ruby, PHP, Python IDE 's