[Pdns-users] High latency on recursion without cache
cyruspy at gmail.com
Tue Jan 27 16:45:44 UTC 2015
2015-01-27 13:21 GMT-03:00 Ciro Iriarte <cyruspy at gmail.com>:
> 2015-01-27 6:59 GMT-03:00 bert hubert <bert.hubert at powerdns.com>:
> On Sun, Jan 25, 2015 at 10:33:34AM -0300, Ciro Iriarte wrote:
>> > Also, the test traffic was stopped, so the trace file should be complete
>> > and cleaner!.
>> I don't see anything that is wrong here. From a cold cache, it takes 11
>> queries to resolve 2.centos.pool.ntp.org.
>> Your network used up the following amounts of time on those queries:
>> in 266ms
>> in 226ms
>> in 184ms
>> in 226ms
>> in 233ms
>> in 267ms
>> in 223ms
>> in 201ms
>> in 224ms
>> in 51ms
>> in 199ms
>> Which together is around 2 seconds.
>> If there is a problem, the problem is that your network is pretty far away
>> from most servers it appears.
>> If you redo your query with the latest PowerDNS test version (3.7.0-RC1)
>> you'll get slightly better timing output with --trace, which perhaps could
>> tell you a little more.
>> On a high-latency network (and your fastest response to anything in this
>> trace was 51ms, even if I look at the other queries too), having a warm
>> cache is super important.
>> Good luck!
> Hi Bert, thanks for the analysis!. I double checked all the configuration
> (routing/pdns/linux) and everything seems to be OK. It's obviously not a
> PDNS thing as a trace using dig still gives pretty bad times
> ; <<>> DiG 9.8.2rc1-RedHat-9.8.2-0.30.rc1.el6 <<>> +trace
> ;; Received 241 bytes from 184.108.40.206#53(220.127.116.11) in 1317 ms <---
> this goes to localhost for recursion
> ;; Received 441 bytes from 18.104.22.168#53(22.214.171.124) in 5628 ms
> ;; Received 153 bytes from 126.96.36.199#53(188.8.131.52) in 2881 ms
> ;; Received 189 bytes from 184.108.40.206#53(220.127.116.11) in 8346 ms
> ;; Received 187 bytes from 18.104.22.168#53(22.214.171.124) in 644 ms
> Complete trace:
> What I find weird is that a query to the server 126.96.36.199 takes more
> than 5 seconds, but a plain ping request gives a RTT of about 177ms. Maybe
> the servers are overloaded and I'm over-reacting :P
> --- 188.8.131.52 ping statistics ---
> 5 packets transmitted, 5 received, 0% packet loss, time 4187ms
> *rtt min/avg/max/mdev = 177.556/178.459/181.044/1.334 ms*
> The same goes for the other destinations:
> --- 184.108.40.206 ping statistics ---
> 5 packets transmitted, 5 received, 0% packet loss, time 4183ms
> *rtt min/avg/max/mdev = 177.125/177.302/177.644/0.565 ms*
> --- 220.127.116.11 ping statistics ---
> 5 packets transmitted, 5 received, 0% packet loss, time 4194ms
> *rtt min/avg/max/mdev = 187.530/188.211/189.673/0.931 ms*
> --- 18.104.22.168 ping statistics ---
> 5 packets transmitted, 5 received, 0% packet loss, time 4276ms
> *rtt min/avg/max/mdev = 265.467/269.252/272.820/2.637 ms*
> The only other thing I could think of is some kind of QoS issue and to
> blame the carrier. It's time to poke the networking guys...
> Ciro Iriarte
For the record, a second query for the same fqdn responds a lot faster
which implies there's some cache involved now.
; <<>> DiG 9.8.2rc1-RedHat-9.8.2-0.30.rc1.el6 <<>> +trace
;; Received 241 bytes from 22.214.171.124#53(126.96.36.199) in 7 ms
;; Received 441 bytes from 188.8.131.52#53(184.108.40.206) in 204 ms
;; Received 153 bytes from 220.127.116.11#53(18.104.22.168) in 183 ms
;; Received 189 bytes from 22.214.171.124#53(126.96.36.199) in 187 ms
;; Received 187 bytes from 188.8.131.52#53(184.108.40.206) in 478 ms
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Pdns-users