Poor performance bind9

[JINMEI Tatuya / 神明達哉]

>>>>> On Wed, 8 Dec 2004 15:02:52 +0100, 
>>>>> Dirk Janssen <dirk at no.netspam.de> 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 problems (using queryperf from bind contribs):

(snip)

> Can anyone explain what's the problem here? Is this a issue of bind9 or of
> freebsd?

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
      SCOPE_SYSTEM attribute)
    - at least so far, the ULE scheduler doesn't help improve the
      performance (it even performs worse than the normal 4BSD
      scheduler).
    - 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
      penalty though.)
    - 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
FreeBSD 5.3.

> 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).

					JINMEI, Tatuya
					Communication Platform Lab.
					Corporate R&D Center, Toshiba Corp.
					jinmei at isl.rdc.toshiba.co.jp