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?

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?

Keep in mind that if you set up jails the cononical way, each jail instance
will have it's own installation of Apache.  Even if each of these
installations are _identical_, they're still seperate, and the kernel
has now way of knowing that /jail1/usr/bin/httpd and /jail2/usr/bin/httpd
are the same execution image (Unless you're doing symlinks or hardlinks).

So getting that kind of memory sharing will require some extra work on
your part, above and beyond what is normally done for a jail.


Hi Bill,

I'm thinking of using mount_nullfs(8) to provide read-only mounts for
all the executables in each jail. I've been doing some reading, 'man
rtld(1)', and it seems that the linker will take of sharing non-writable
code between processes, even if the executables are loaded from
different mount-points/file-systems.

You should also look at ezjail... it uses the same tricks to reduce the size of individual jail systems. I haven't used it, but keep meaning too (next server :)

http://erdgeist.org/arts/software/ezjail/
_______________________________________________
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Reply via email to