我有一个caching，只有DNS服务器，每秒钟约3k查询。 这里是规格：
Xeon dual-core 2,8GHz 4GB of RAM Centos 5x (kernel 2.6.18-164.15.1.el5PAE) bind 9.4.2 rndc状态：recursion客户端：666/4900/5000
每秒约300个新的查询（不在caching中）。
绑定总是在单线程configuration的一个核心上使用100％。 在我重新编译到multithreading后，它在两个核心上使用了近200％:(没有iowait，只有sys和user）我四处search，但是没有看到关于如何绑定使用CPU的信息，为什么会成为瓶颈？
还有一件事，这里是RAM的使用情况：
cat /proc/meminfo MemTotal: 4147876 kB MemFree: 1863972 kB Buffers: 143632 kB Cached: 372792 kB SwapCached: 0 kB Active: 1916804 kB Inactive: 276056 kB
我已经设置max-cache-size为0，以确保绑定可以使用尽可能多的RAM，但它总是停在〜2GB。 因为每秒我们都没有caching查询，所以理论上RAM必须耗尽，但事实并非如此。
你有什么主意吗？
TIA，
-gk
你正在使用哪个版本的BIND？ Bind 9.5之前的版本已知高负载的可伸缩性问题，请参阅https://www.dns-oarc.net/files/dnsops-2007/Graff-BIND9-cache.pdf 。
除了：
我build议你用dnscache执行dnscache的小testing，安装需要10分钟，调整和维护非常简单，性能可预测。
有趣的问题…从来没有看到bind使用100％的CPU，但快速search成为一个非常有趣的网页 ，可能会帮助您解决问题…让我知道它是如何结果。 我有兴趣知道结果。
对于该类服务器来说，3k qps在原始I / O和内存带宽方面的体积相对较低 – 如果是权威服务器，我预计能够接近20k。
也就是说，BIND 9.4.2是旧的 。 如果您可以推出自己的产品，或者使用非RHEL RPM，那么您应该尝试使用BIND 9.7.x来查看是否解决了性能问题。
此外，要使用2GB以上的内存，您需要以64位模式运行在x64上，而不是使用x86。
Unbound你可能会获得更好的性能。 如果您仅将BIND用作cachingrecursion服务器而没有特别的configuration，则切换到Unbound将非常容易。