VM and jailed processes
Andrew
andrew.chace at gmail.com
Sun May 14 11:07:06 PDT 2006
On Sun, 2006-05-14 at 07:45 -0400, Chuck Swiger wrote:
> Andrew wrote:
> > It's my understanding that if there is more than one instance of a
> > specific application running, then portions of the code are shared in
> > memory. I would assume that would apply to dynamically linked
> > applications as well; i.e. if two different applications are linked
> > against the same library, the given code exists in only one location in
> > memory. Is this correct?
>
> Yes. The details are more complicated, but the portion of an executable
> which contains code and does not change can be shared between many
> processes from only one copy in physical RAM, and likewise for shared
> libraries loaded by dynamic or runtime linking.
>
> > The second portion of my question is, how does this apply to jailed
> > processes? Looking through the architecture handbook, I did not see any
> > references to VM, which leads me to believe that the standard rules
> > apply to jails as well. So, for instance, if I was to provide a hosting
> > service with numerous instances of Apache running in individual jails,
> > could I assume that base memory usage (ie idle, not serving requests)
> > would increase at a roughly linear rate.
> >
>
> The same thing applies to jails, and the static portions of apache/httpd
> will only appear once in RAM, however, you are going to see roughly
> linear increase in memory usage depending on the number of children
> running, because there's anywhere from 1MB to 25MB or so of dynamic
> memory being used per httpd which is specific to that process, depending
> on which modules you're using and whether you are loading perl or PHP
> scripts....
>
Hi Chuck,
Thank you for the clarifications. It seems as though this will work
quite well; the hosting setup, that is. I would have to assume that this
has been done many times before, but it's always fun to have an idea pan
out the way that you expected it to!
-Andrew
More information about the freebsd-questions
mailing list