This is a discussion on Re: Poor performance bind9 - DNS ; >>>>> On Wed, 8 Dec 2004 15:02:52 +0100, >>>>> Dirk Janssen said: > I've compiled in threads to bind9.3.0 (src from isc not ports) using a dual > procssor machine (2xIntel XEON) with 5.3-STABLE and I encounter serious > performance ...
>>>>> On Wed, 8 Dec 2004 15:02:52 +0100,
>>>>> Dirk Janssen
> I've compiled in threads to bind9.3.0 (src from isc not ports) using a dual
> procssor machine (2xIntel XEON) with 5.3-STABLE and I encounter serious
> performance problems (using queryperf from bind contribs):
> Can anyone explain what's the problem here? Is this a issue of bind9 or of
As far as I know, the most dominant factor that affects the
performance for FreeBSD (5.3) is OS-specific issues. Here are what I
know through my experiences:
- we need to set the PTHREAD_SCOPE_SYSTEM attribute in worker
threads. Otherwise, the pthreads scheduler implementation won't
allow multiple threads to run on multiple processors
concurrently. (Note that BIND 9.3.0 does not specify the
- at least so far, the ULE scheduler doesn't help improve the
performance (it even performs worse than the normal 4BSD
- the SMP support in the kernel performs very well in terms of UDP
input/output on a single socket.
- mutex contents are VERY expensive (looks like much much more
expensive than other OSes), while trying to get a lock without
a content is reasonably cheap. (Almost) whenever a user thread
blocks due to a lock contention, it is suspended with a system
call, probably causing context switch. (I'm not really sure if
the system call overhead is the main reason of the performance
- some standard libraries internally call pthread_mutex_lock(),
which can also make the server slow due to the expensive
contention tax. Regarding BIND9, malloc() and arc4random() can
be a heavy bottleneck (the latter is called for every query if
we use the "random" order for RRsets).
As a result, there is no good reason for enabling BIND9 threads on
> Any suggestions how I can use the two processors of my box
> without running two (non multithreading) instances of bind listening on
> different IPs?
The only alternative I can think of right now is to use a different OS
that runs on the same hardware spec with a better thread support.
My past experiences showed Linux is much better than FreeBSD in this
area, while a 2-thread named process on Linux still ran just as fast
as a non-threaded process on the same OS and the same box (i.e., it
was no better than the non-threaded version).
Communication Platform Lab.
Corporate R&D Center, Toshiba Corp.