performance of jailed processes
Eirik Oeverby
ltning at anduin.net
Tue Mar 30 12:22:38 PST 2004
Hi there,
and I thought I was using jails on a 'big' scale... 400 jails on one
single box, that's pretty amazing! What kind of jails are these, i.e.
what are they used for? Encapsulating single processes/tasks only, or
more complex things too? And what hardware are you on, CPU and memory-wise?
/Eirik
Dag-Erling Smørgrav wrote:
> Robert Watson <rwatson at freebsd.org> writes:
>
>>- DNS -- I know you mentioned it, but I'd check anyway. Especially if
>> resolv.conf has bad DNS servers in it in the jails, etc. You might try
>> writing a trivial gethostbyname() test app and timing it in and out of
>> the jail. Also look at the reverse lookup done by the MySQL server.
>> The impact of the source IP address might be particularly interesting.
>
>
> Packet traces already show that there is no delay between query and
> reply, the reply just takes a long time to transmit.
>
>
>>- It would be interesting to know if applications outside the jail bound
>> to various IP addresses see performance differences depending on the IP
>> used. We have hashed IP address lookup, but there are some operations
>> in the stack that require walking the list of addresses, etc. If the
>> non-jailed software always uses the first address because they're all in
>> the same subnet, that might conceivably make a difference. Taking jail
>> out of the picture in some basic micro-benchmarks might help here also.
>
>
> Non-jailed software always uses the first IP address, which is in its
> own subnet. The jails draw from a pool of ~1000 IP addresses on the
> same interface, but in a different subnet. The jail I've been testing
> in is about a quarter of the way down the list.
>
>
>>Can you identify any micro-benchmarks rather than macro-benchmarks that
>>reflect a significant difference?
>
>
> haven't had much luck with that... fetch, for instance, doesn't seem
> to suffer, but with mysql the difference is dramatic:
>
> (outside jail)
> 1 row in set (0.01 sec)
>
> (inside jail)
> 1 row in set (13.20 sec)
>
> note that 13 seconds is far too short for a DNS issue, and that the
> time reported is measured *after* login (i.e. after any DNS lookup)
>
> DES
More information about the freebsd-current
mailing list