我们正在运行一个通过服务器上的某些Docker容器承载的服务。这些容器中的应用程序向大约300台机器的本地集群发出一些非常频繁的请求。有两个本地DNS服务器(主服务器和辅助服务器)运行bind9,托管本地计算机的区域文件。主服务器似乎无法处理负载,一些DNS查询似乎正在超时并溢出到辅助服务器。在辅助服务器上,我们在querylog中看到一个恒定的缓慢查询流。
我试图增加主服务器上的线程数,但这似乎没有帮助。在Docker容器中没有DNS缓存,我们试图避免接触Docker图像来添加任何缓存机制。DNS服务器运行在两个有64 of的六核处理器上。硬件似乎不是这里的瓶颈。我们想知道是否有一个明显的调优参数是我们缺少的绑定。
我们正在运行Ubuntu 18.04。
绑定版本:BIND 9.11.3-1ubuntu1.9-Ubuntu (Extended Support Version) <id:a375815>
named.conf.options:
options {
directory "/var/cache/bind";
forwarders {
8.8.8.8;
8.8.4.4;
};
dnssec-validation auto;
auth-nxdomain no; # conform to RFC1035
listen-on-v6 { any; };
};发布于 2020-05-04 20:02:41
因此,我完成了我的调查,并找到了一个令人满意的答案,我们所观察到的行为,在我们的环境。当我注意到辅助DNS服务器上的DNS查询时,我假设主DNS服务器存在性能问题。我一直在研究这个假设,继续努力提高性能,或者找出主服务器的问题。
但在深入研究之后,我发现系统解析的工作方式是,一旦“当前”服务器出现延迟/打嗝,它就会立即切换DNS服务器。然后,它将坚持在较新的服务器,直到有一个小插曲,然后再旋转回到原来的服务器。这种流量是UDP,并且有这么多的请求和客户端,有很多丢弃的数据包和服务器被旋转的机会。这似乎并没有造成太多的性能问题,实际上最终导致了跨多个服务器的负载分散。所以我就把它留在这里。
尽管在systemd:https://github.com/systemd/systemd/issues/5755中有关于这种行为的热烈讨论
此外,在我挖掘BIND服务器时,为了获得更好的性能,我遇到了一些可能很方便的资源:
https://askubuntu.com/questions/1234116
复制相似问题