Jail to jail network performance?

Robert Watson rwatson at FreeBSD.org
Wed Sep 14 03:04:39 PDT 2005


On Wed, 14 Sep 2005, Lyndon Nerenberg wrote:

> On Sep 13, 2005, at 11:59 PM, Uwe Doering wrote:
>
>> Now, for security reasons jails normally are confined in separate 
>> filesystems, or at least in separate parts of a common one.  So in case 
>> of MySQL you would have to use TCP sockets to communicate between 
>> jails.  This socket type typically consumes more CPU because of TCP's 
>> protocol overhead. However, whether you would actually notice any 
>> difference in speed basically depends on how much excess CPU power 
>> there is available on that server.
>
> Ignoring security (or filesystem namespace issues) I will just note that 
> using named sockets for local IPC is a Good Thing.  When I worked at 
> Messaging Direct I taught sendmail to speak LMTP over named sockets, and 
> our local delivery rate (to our IMAP server) went up by a factor of 10.
>
> It would be really cool if we could figure out a way to do AF_UNIX 
> between jails, but I confess to not having thought about any of the 
> implications ... (Maybe netgraph can help here?)

There are several ways you can do it, but they generally fall into two 
classes of activies:

(1) Modifying the name space exclusion assumption for jails, so that the
     file system name spaces overlap.  One way to do this is with nullfs.

(2) Having a daemon or tool that runs outside of the jail and brokers
     communication between the jails.  One example might be a daemon that
     inserts a UNIX domain socket into both jails and then provides
     references to shared IPC objects between the two "by request".
     Another example might be a daemon or tool that responds to a request
     and creates a hard link from a socket/fifo endpoint visible in one
     jail to a name visible in another jail, perhaps when setting up the
     jail.  The former requires more infrastructure, but the latter is less
     flexible.

Robert N M Watson


More information about the freebsd-stable mailing list