☰

BIND - 单一接口导致查询响应缓慢

tag-icon • tag-icon domain-name-system performance bind
BIND - 单一接口导致查询响应缓慢

目前，我的名称服务器上的特定接口的查询响应速度很慢。我在一台只有一张网卡的物理服务器上运行 BIND。该网卡由接口 eth0 和虚拟接口 eth0:1 使用。它们都在同一子网中有一个地址。

BIND 正在监听所有 IPv4 接口，并设置了一些非常基本的选项。在任何其他包含的配置文件中均未设置其他与性能/网络相关的选项。

listen-on { any;};
listen-on-v6 port 53 { ::1; };
directory       "/var/named";
dump-file       "/var/named/data/cache_dump.db";
statistics-file "/var/log/named/named.stats";
memstatistics-file "/var/named/data/named_mem_stats.txt";

当我查询主接口 eth0 上的地址时，通常会收到大约三秒或更长的延迟响应。这甚至适用于从盒子本身查询地址（而不是环回）。当查询分配给虚拟接口 eth0:1 的其他私有 IP 地址时，不会遇到性能问题，响应时间始终在一秒之内。

分析性能统计数据，似乎该框未处于负载状态，内存也未达到最大值。我还将另一个名称服务器设置为此名称服务器的从属服务器，它们位于同一网络上，具有几乎相同的网络设置栏寻址，并且查询其主接口时没有性能问题（它也具有具有相同配置的虚拟接口）。我查询的区域是权威的，因此在其他地方查找记录没有延迟。我还可以确认，无论查询来自何处，服务器几乎都会立即收到查询，并且延迟发生在接收查询和发送响应之间（通过 tcpdump 识别）。

如果有任何有用的信息，请不要因为我的帖子中没有提到而给我差评，只需在下面留言即可，我很乐意提供任何有用的详细信息。任何关于如何最好地解决此类问题的建议，或关于潜在原因的想法，都将不胜感激。

BIND 版本是 9.3.6-P1-RedHat-9.3.6-25.P1.el5_11.11。我最近更新到了这个版本，但我不确定这些性能问题是在升级后出现的，还是在升级之前就存在了。

编辑：按要求挖掘输出。删除了正在查询的域名和目标服务器。

还值得注意的是，有时请求会完全超时。这种情况很不常见，偶尔会有两秒内的回复，但大多数情况下会超过三秒，偶尔会出现上述超时。

[root@hugh-host-01 ~]# dig REMOVED @REMOVED

; <<>> DiG 9.9.4-RedHat-9.9.4-38.el7_3 <<>> REMOVED @REMOVED
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 52129
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 3, ADDITIONAL: 4
;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;REMOVED.                      IN      A

;; ANSWER SECTION:
REMOVED.               5       IN      A       REMOVED

;; AUTHORITY SECTION:
REMOVED.               5       IN      NS      REMOVED.
REMOVED.               5       IN      NS      REMOVED.
REMOVED.               5       IN      NS      REMOVED.

;; ADDITIONAL SECTION:
REMOVED.           5       IN      A       REMOVED
REMOVED.           5       IN      A       REMOVED
REMOVED.           5       IN      A       REMOVED

;; Query time: 3633 msec
;; SERVER: REMOVED#53(REMOVED)
;; WHEN: Sat Jan 07 00:49:01 GMT 2017
;; MSG SIZE  rcvd: 155

谢谢你的时间，

休

答案1

这个问题是由于服务器上的 iowait 达到最大值而引起的。它一直以 100% 的速度运行，而导致这个问题的服务是 kjournald。

感谢 Andrew B 的建议，我开始使用 调查 UDP 数据包错误 netstat -su | grep errors。由此，我可以看到每秒大约有 30-50 个数据包激增。这促使我通过运行 检查每个套接字的 UDP 缓冲区netstat -uanp。由此，我能够确认由于缓冲区已满而发生随机延迟和偶尔的超时（丢失）。我通过分析监听相关 IP/端口的 BIND 服务的 Recv-Q 列中的值发现缓冲区已满。

确定缓冲区已满后，增加缓冲区就没有什么意义了，因为毫无疑问它会再次饱和。相反，由于 CPU 负载和 RAM 看起来没问题，我开始怀疑磁盘操作是否会导致处理 UDP 数据包的瓶颈。通过运行命令top并分析 iowait 值，我确认了这一点。

当我确定 CPU 几乎 100% 的时间都在等待 io 操作完成时，我开始使用诸如iotop查找写入磁盘的内容的工具。结果发现 ext3 文件系统的日志系统正在生成所有等待。这让我想到，也许是服务器上的日志记录量过大导致了饱和，因为我知道该/var/log/messages文件每秒都会收到大量拒绝查询日志。

为了测试上述理论，我在日志记录区域中将以下行添加到了 named.conf 中。此行禁用与收到的查询相关的批准/拒绝消息的日志记录。每个查询都有一个日志/var/log/messages，如果您受到客户端的猛烈攻击，日志可能会很多：

category security { null; };

幸运的是，重新启动 BIND 后，我可以看到 iowait 百分比急剧下降。测试查询时，我能够确认它们现在在十分之一秒内得到响应；与以前相比有了显著的改进。

事后看来，我应该一开始就检查一下 iowait 时间。希望这对遇到类似问题的人有所帮助。我现在将研究如何进一步控制日志记录，看看我能对这些被拒绝的消息做些什么。

相关内容