On 8/13/07, Jano Svitok <jan.svitok / gmail.com> wrote:
> On 8/13/07, Matt Harvey <matt / teamdawg.org> wrote:
> > This paragraph is motivation. While my question is not Rails-specific, I am
> > asking it because of Rails. I've been investigating the memory footprint of
> > my Mongrels. It is nice that they share the .so libraries from ImageMagick
> > as well as other C libraries. However, each one still has about 20MB in
> > [heap]. My theory is that a lot of this is coming from ActiveRecord and
> > friends getting loaded again and again for each Mongrel, which seems to me
> > entirely unnecessary. My "marginal cost of Apache" is 1376kB. My "marginal
> > cost of Mongrel" is 27528kB, with the code I wrote. It seems that the latter
> > could be reduced a lot by sharing some Ruby libraries.
> >
> > The question is as follows: if I require 'library' in one instance of Ruby
> > and then require 'library' again in another instance of Ruby, then do I get
> > duplicate copies of library's code in two chunks of my RAM? (I'm thinking I
> > do.) Why?
>
> I suppose the main problem is that Rails (or ActiveRecord, I don't
> know exactly) is not thread-safe. That means you cannot share most of
> its the data. That is the reason why you have to run more mongrels
> compared to a one multi-threaded mongrel.

It's actually what Wayne mentioned.  Since all Ruby classes can be
modified at runtime, it would be very scary to share them across
separate process instances unless you explicitly wanted that behavior.

As a naive example, consider this:

>> require "set"
=> true

>> class Set
>>   def icanhasset
>>     puts "Oh hai, I is an instance method"
>>   end
>> end

>> Set[].icanhasset
Oh hai, I is an instance method

Imagine this shared across separate processes running different types
of code.  Any modifications would be shared, and that means that you
couldn't meaningfully modify any classes without expecting problems or
weird bugs.  Takes away half of the fun (and utility) of Ruby right
there. :)

-greg