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 地址時，沒有遇到性能問題，響應始終在 1 秒以下。

分析性能統計數據，似乎該盒子沒有處於負載之下，並且記憶體沒有被最大化。我還設置了另一個名稱伺服器作為該名稱的從屬伺服器，在同一個網路上具有幾乎相同的網路設置欄地址，並且在查詢它的主界面時沒有性能問題（它也有一個具有相同配置的虛擬界面） . 我要查詢的區域是權威的，因此在其他地方查找記錄不會有任何延遲。我還能夠確認伺服器幾乎立即接收到查詢，無論它來自何處，並且在收到查詢和發送響應之間發生延遲（通過 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

謝謝你的時間，

休

這個問題是由伺服器上的 iowait 被最大化引起的。它始終以 100% 的速度執行，而 kjournald 作為導致它的服務。

感謝 Andrew B 的建議，我開始使用 netstat -su | grep errors. 從這裡，我可以看到它大約每秒增加 30 到 50 個數據包。這導致我通過執行檢查每個套接字的 UDP 緩衝區netstat -uanp。由此，我能夠確認由於緩衝區已滿而發生了隨機延遲和偶爾的超時（丟棄）。我通過分析 Recv-Q 列中的值發現緩衝區已滿，該列中的 BIND 服務正在偵聽相關 IP/埠。

在確定緩衝區已滿後，增加它沒有多大意義，因為它無疑會再次變得飽和。相反，當 CPU 負載和 RAM 看起來還不錯時，我開始懷疑磁碟操作是否會導致處理 UDP 數據包的瓶頸。這已通過執行命令top並分析 iowait 值得到確認。

一旦我確定 CPU 幾乎 100% 的時間都在等待 io 操作完成，我就開始使用諸如iotop查找寫入磁碟的內容之類的工具。原來 ext3 文件系統的日誌系統正在生成所有的等待。這讓我想到，可能是伺服器上的大量日誌記錄可能導致飽和，因為我知道該/var/log/messages文件每秒都會收到大量被拒絕的查詢日誌。

測試上述理論，我在日誌區域內的 named.conf 中添加了以下行。此行禁用與收到的查詢相關的批准/拒絕消息的日誌記錄。每個查詢都有一個日誌/var/log/messages，如果您被客戶攔截，可能會很多：

category security { null; };

幸運的是，在重新啟動 BIND 後，我可以看到 iowait 百分比急劇下降。測試查詢，我能夠確認它們現在在十分之一秒內得到了很好的回答；比以前有了顯著的改善。

事後看來，我最初應該檢查 iowait 時間。希望這可以幫助任何遇到類似問題的人。我現在將研究更多地控制日誌記錄，看看我可以對這些被拒絕的消息做些什麼。

引用自：https://serverfault.com/questions/824687