[dns-operations] BIND performance difference between RHEL 6.4 and FreeBSD 7

Shawn Zhou shawnzhou00 at yahoo.com
Wed Apr 23 17:09:39 UTC 2014



Hi Evan,

Thanks for your response!
It's 9.9.4b1. Adjusting the number of listeners only helped a little bit.
large_recv_buffer.jpeg

 
   large_recv_buffer.jpeg
Shared with Dropbox  
View on www.dropbox.com Preview by Yahoo  

The concern I have it that the drop rate increases linearly with steep slope on RHEL 6.4. Do we need to adjust the number of workers as well? How do we determine a good combination of number of listeners and workers besides running extensive tests to see what gives us the best performance?

The kernel we are running already has the "lockless UDP" changes: https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/6.1_Technical_Notes/kernel.html


On Tuesday, April 22, 2014 3:05 PM, Evan Hunt <each at isc.org> wrote:
 
On Tue, Apr 22, 2014 at 02:40:08PM -0700, Shawn Zhou wrote:
>
>> Our performance tests show that ISC BIND (authoritative only setup)
>> doesn't perform well on RHEL 6.4 in comparison with FreeBSD
>> 7:?bind_perf.png
>
>You didn't specify which version of BIND, but I know that BIND 9.9 and
>higher, when running on Linux, is sensitive to the number of threads
>listening for incoming UDP connections. You can adjust this via the -U
>command line option: If you have 8 processors, I'd try it at -U 4, -U 5,
>-U 6 and -U 7 and see where the peak performance was found.
>
>Older linux kernels had a problematic UDP stack that caused a big
>performance drop relative to BSD or Solaris, essentially reducing it
>to single-thread performance.  I believe all the major Linux distributions
>have switched to lockless UDP by now, but it might be worth checking out.
>
>-- 
>Evan Hunt -- each at isc.org
>Internet Systems Consortium, Inc.
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.dns-oarc.net/pipermail/dns-operations/attachments/20140423/22d814ec/attachment.html>


More information about the dns-operations mailing list