Open MiKing233 opened 1 year ago
Could you try the latest Beta release? We have replaced the /etc/hosts
mechanism there, and the new one should be faster and more correct.
Could you try the latest Beta release? We have replaced the
/etc/hosts
mechanism there, and the new one should be faster and more correct.
Hi, after a period of testing, I have obtained some of the following results
On v0.108.0-b.44 may seem faster, but I still don't think it should be this speed
But I noticed some details: For these high latency PTR queries, they all come from the device running ADGH itself (127.0.0.1), while devices from br-lan, such as me using my LAPTOP to execute command
nslookup 10.128.20.102
The following results were obtained:
PS C:\Users\MiKing233> nslookup 10.128.20.102
服务器: NanoPiR4S-Gateway
Address: 10.128.20.2
名称: MiKing233-iPhone12Pro
Address: 10.128.20.102
In the DNS query log of ADGH, the latency is as follows Request from my LAPTOP(10.128.20.101), delay is normal
If the entry in/etc/hosts is called through ping, there is no problem with latency, This will be a Class A DNS query
At present, there is only so much information I can know. In short, the problem of high DNS request latency lies in PTR requests
Supplementary explanations to the above
On v0.108.0-b.44 this issue does not seem to occur frequently, But I am certain that this issue has been occurring continuously at v0.107.36
But besides this issue, I also discovered a new one, Also only exists in PTR queries The results in the query log will be returned x3
@MiKing233, doesn't the /etc/hosts
file contain this entry three times? Or perhaps this hostname mentioned in three records?
@MiKing233, doesn't the
/etc/hosts
file contain this entry three times? Or perhaps this hostname mentioned in three records?
No, there is only one record corresponding to this IP address and host name in the/etc/hosts file
for the same /etc/hosts file On v0.107.36 I confirm the query logs in ADGH like this:
响应细节
状态: 重写项
耗时: 0.09 毫秒
响应代码: NOERROR
规则:
10.128.20.1 Mi-BE10GbE-Router
系统主机文件
响应:
PTR: Mi-BE10GbE-Router. (ttl=10)
I'm not quite sure but I might have the same Issue in a similar manner. I need to restart the docker frequently (at least once a day) as the reolving times go up to several hundret ms per request. After restarting the docker the times go down to under 100ms.
The low entries are after the restart, the high values are before the restart. So it seems that this behaviour builds up hour by hour until the requests are getting so slow that surfing the net is nearly impossible anymore.
192.168.0.1 is the router 192.168.0.21 is the device running AGH on it
@MiKing233, unfortunately, we can't reproduce this slowdown. Could you please collect verbose log for us? There are few actions we'd like to see captured:
A
DNS request for some host specified in hosts;PTR
request for some IP address specified in hosts;You may send it to devteam@adguard.com.
@MiKing233, unfortunately, we can't reproduce this slowdown. Could you please collect verbose log for us? There are few actions we'd like to see captured:
- Update the hosts file to make AdGuardHome reload it;
- An
A
DNS request for some host specified in hosts;- A
PTR
request for some IP address specified in hosts;You may send it to devteam@adguard.com.
對於PTR請求高延遲的問題, 我還需要補充一些: 對於我在DNS Server或是在局域網客戶端上手動發起的PTR請求, 通過ADGH查詢是不存在高延遲問題的
然而在我看到的有關PTR請求存在高延遲問題的DNS請求, 都不是我手動進行查詢的, 這似乎是來自於這臺設備的系統本身
我的設備運行OpenWrt作爲局域網内Gateway之用途, 同時運行ADGH提供DNS查詢 Openwrt-18.06-Linux5.4.203 在我觀察到, 每當OpenWrt運行一段時間, 它會對hosts中的條目進行一次完整的PTR查詢, 而這個動作則會讓ADGH查詢的延遲變得不正常的高, 我注意到ADGH在1秒内處理了近30條查詢, 可能是我設備效能的問題, 又或者是I/O效能的問題? 晚些時候我會排查這個問題, 不過我的/etc/hosts條目只存在47行, 大小為1.5K, 我不太懷疑是設備本身的效能導致的.
@MiKing233,我可以肯定地说,在大量请求导致的高负载时间内,这些请求的平均处理速度会比正常情况下慢。 这与机器资源的平均分配有关。 您能否尝试将配置文件中的 max_goroutines
设置设为 0
,看看情况是否有所改善,处理时间是否变得更均匀?
@MiKing233,我可以肯定地说,在大量请求导致的高负载时间内,这些请求的平均处理速度会比正常情况下慢。 这与机器资源的平均分配有关。 您能否尝试将配置文件中的
max_goroutines
设置设为0
,看看情况是否有所改善,处理时间是否变得更均匀?
Hi @EugeneOne1 ,抱歉讓您久等了, 我使用dnsperf工具對迸發解析速度進行了測試, 發現DNS解析速度過慢的問題的確是由於短時間内需要處理大量的DNS請求造成的, 并且這個問題不是僅存在於PTR請求, 但我對此仍有疑問:
我使用了
dnsperf -d testfile.lan -s 10.128.20.2 -p 53
來對ADGH進行測試, 在testfile.lan文件中, 完整包含/etc/hosts中的41個條目, 就像這樣"Mi-BE10GbE-Router A", 解析速度如下圖 但我并不認爲這是設備性能導致的問題 此設備的CPU信息如下"AArch64 / Rockchip RK3399 / Dual-core Cortex-A72 up to 2.2GHz and Quad-core Cortex-A53 up to 1.8GHz", 在41條DNS迸發請求下設備的loading並不高
另外, 此時我的ADGH使用的上游伺服器為10.128.20.2:54, 是OpenWrt自帶的Dnsmasq, 所以這是否意味著可能是Dnsmasq對高迸發請求的回應速度過慢, 而不是ADGH的問題呢
# root @ OpenWrt in ~ [22:15:58]
$ netstat -ntulp | grep 54
tcp 0 0 127.0.0.1:54 0.0.0.0:* LISTEN 14476/dnsmasq
tcp 0 0 10.128.20.2:54 0.0.0.0:* LISTEN 14476/dnsmasq
此外例如對Mi-BE10GbE-Router的A類請求, 實際是來自上游Dnsmasq的回應, 爲此我更改了上游DNS伺服器為8.8.8.8, 希望借此來測試ADGH的性能, 但發現此時ADGH根本無法回應來自/etc/hosts的條目, 這直接導致ADGH回應了一個NXDOMAIN...
我覺得現在有些混亂, 在繼續測試下去前, 我覺得還是應該向您確認一下, ADGH是否支援解析來自/etc/hosts的A類記錄?, 目前我只發現PTR記錄是由ADGH進行rewrite的, 但是對與A類請求, 在我目前測試下, ADGH作爲DNS伺服器似乎對於域名不會先檢查/etc/hosts文件而直接將DNS的A類請求丟給上游DNS伺服器
Prerequisites
[X] I have checked the Wiki and Discussions and found no answer
[X] I have searched other issues and found no duplicates
[X] I want to report a bug and not ask a question or ask for help
[X] I have set up AdGuard Home correctly and configured clients to use it. (Use the Discussions for help with installing and configuring clients.)
Platform (OS and CPU architecture)
Linux, ARM64
Installation
Custom package (OpenWrt, HomeAssistant, etc; please mention in the description)
Setup
On one machine
AdGuard Home version
v0.107.36
Action
In my DNS resolution log, I noticed that the resolution speed of rewritten items from the hosts file is not normal, and they appear too slow
I correspond the device names in my domain to the IP addresses through the hosts file of this Gateway
In my /etc/hosts, there are approximately over 30 records, and file size is 1.5KB
Expected result
I think the DNS resolution speed of hosts files should be like this, or even faster than them
Actual result
But the actual parsing speed is very slow, with an average of over 100ms or even higher (毫秒=ms)
Additional information and/or screenshots
This issue has a lower priority as the impact is not actually felt