Re: Generic reasons for recursive performance not to peg CPU?
Thanks for the response, but you're answering a different question than I asked. :) The question I'm interested in is, Why is the recursive server not pegging the CPU? I should have quoted Sten's context. If the recursive answer contains additional data, that may contributing to the time spent awaiting bandwidth for the delivery of outbound packets. On Sunday, January 12, 2014 6:11 PM, Doug Barton do...@dougbarton.us wrote: Thanks for the response, but you're answering a different question than I asked. :) The question I'm interested in is, Why is the recursive server not pegging the CPU? I'm aware that there will be a difference in qps between auth-only and recursive, but the recursive server seems to be working a lot less hard than the auth server, and I can't figure out why. Doug On 01/12/2014 06:07 PM, Leonard Mills wrote: Are you allowing long answers when authoritative? Performance measurements with and without additional data in responses is measurable (imo around 12% more network traffic from the replies on auth-only servers). ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Generic reasons for recursive performance not to peg CPU?
On 12.01.14 17:16, Doug Barton wrote: Without going into too much detail, doing some performance testing and am seeing a weird result. On the same systems authoritative queries will happily peg the CPU. However when running recursive queries (with a small zone, all data cached before testing) the CPU never gets above 80%. The disk is nearly inactive on both systems, and there is no swapping. Using BIND 9.9.4. Is there perhaps something obvious I'm overlooking here? Any suggestions are welcome. Besides the zone and recursion definitions, the same configuration? DLZ in use by any way ? -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. Support bacteria - they're the only culture some people have. ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Generic reasons for recursive performance not to peg CPU?
On 13/01/14 01:16, Doug Barton wrote: Howdy, Without going into too much detail, doing some performance testing and am seeing a weird result. On the same systems authoritative queries will happily peg the CPU. However when running recursive queries (with a small zone, all data cached before testing) the CPU never gets above 80%. The disk is nearly inactive on both systems, and there is no swapping. Using BIND 9.9.4. Is there perhaps something obvious I'm overlooking here? Any suggestions are welcome. I'm wondering if it's something tediously low-level like scheduler, issues relating to concurrency/locking of the cache, and so on. Presumably bind has some method to protect the cache from simultaneous updates that requires some degree of locking - perhaps you're loading it to a degree that you're bumping into lock waiting? What's the (relative) size of the auth vs. pre-loaded recursive cache? A generic CPU tracing tool (e.g. perf under Linux) might be able to tell you the hotspots in the two cases, and any differences might be instructive. ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Generic reasons for recursive performance not to peg CPU?
Howdy, Without going into too much detail, doing some performance testing and am seeing a weird result. On the same systems authoritative queries will happily peg the CPU. However when running recursive queries (with a small zone, all data cached before testing) the CPU never gets above 80%. The disk is nearly inactive on both systems, and there is no swapping. Using BIND 9.9.4. Is there perhaps something obvious I'm overlooking here? Any suggestions are welcome. Doug ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Generic reasons for recursive performance not to peg CPU?
Wild guess: network bandwidth runs out before CPU? Why the difference, I have no clue. On 13/01/14 02.16, Doug Barton wrote: Howdy, Without going into too much detail, doing some performance testing and am seeing a weird result. On the same systems authoritative queries will happily peg the CPU. However when running recursive queries (with a small zone, all data cached before testing) the CPU never gets above 80%. The disk is nearly inactive on both systems, and there is no swapping. Using BIND 9.9.4. Is there perhaps something obvious I'm overlooking here? Any suggestions are welcome. Doug ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users -- Best regards Sten Carlsen No improvements come from shouting: MALE BOVINE MANURE!!! ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Generic reasons for recursive performance not to peg CPU?
Thanks for the response, but that's not it. The auth-only responses are generating a lot more traffic than the recursive. Doug On 01/12/2014 05:21 PM, Sten Carlsen wrote: Wild guess: network bandwidth runs out before CPU? Why the difference, I have no clue. On 13/01/14 02.16, Doug Barton wrote: Howdy, Without going into too much detail, doing some performance testing and am seeing a weird result. On the same systems authoritative queries will happily peg the CPU. However when running recursive queries (with a small zone, all data cached before testing) the CPU never gets above 80%. The disk is nearly inactive on both systems, and there is no swapping. Using BIND 9.9.4. Is there perhaps something obvious I'm overlooking here? Any suggestions are welcome. ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Generic reasons for recursive performance not to peg CPU?
Are you allowing long answers when authoritative? Performance measurements with and without additional data in responses is measurable (imo around 12% more network traffic from the replies on auth-only servers). hth, Len On Sunday, January 12, 2014 5:54 PM, Doug Barton do...@dougbarton.us wrote: Thanks for the response, but that's not it. The auth-only responses are generating a lot more traffic than the recursive. Doug On 01/12/2014 05:21 PM, Sten Carlsen wrote: Wild guess: network bandwidth runs out before CPU? Why the difference, I have no clue. On 13/01/14 02.16, Doug Barton wrote: Howdy, Without going into too much detail, doing some performance testing and am seeing a weird result. On the same systems authoritative queries will happily peg the CPU. However when running recursive queries (with a small zone, all data cached before testing) the CPU never gets above 80%. The disk is nearly inactive on both systems, and there is no swapping. Using BIND 9.9.4. Is there perhaps something obvious I'm overlooking here? Any suggestions are welcome. ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Generic reasons for recursive performance not to peg CPU?
Thanks for the response, but you're answering a different question than I asked. :) The question I'm interested in is, Why is the recursive server not pegging the CPU? I'm aware that there will be a difference in qps between auth-only and recursive, but the recursive server seems to be working a lot less hard than the auth server, and I can't figure out why. Doug On 01/12/2014 06:07 PM, Leonard Mills wrote: Are you allowing long answers when authoritative? Performance measurements with and without additional data in responses is measurable (imo around 12% more network traffic from the replies on auth-only servers). ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
RE: Generic reasons for recursive performance not to peg CPU?
Wouldn't it be something along the lines about recursive using cache-in-memory where the authoritative is using lookups of zone-in-memory? The algorithms are probably different. I've not looked at the code though. Stuart -Original Message- From: bind-users-bounces+stuart.browne=ausregistry.com...@lists.isc.org [mailto:bind-users-bounces+stuart.browne=ausregistry.com...@lists.isc.org] On Behalf Of Doug Barton Sent: Monday, 13 January 2014 1:11 PM To: Leonard Mills; bind-users@lists.isc.org Subject: Re: Generic reasons for recursive performance not to peg CPU? Thanks for the response, but you're answering a different question than I asked. :) The question I'm interested in is, Why is the recursive server not pegging the CPU? I'm aware that there will be a difference in qps between auth-only and recursive, but the recursive server seems to be working a lot less hard than the auth server, and I can't figure out why. Doug On 01/12/2014 06:07 PM, Leonard Mills wrote: Are you allowing long answers when authoritative? Performance measurements with and without additional data in responses is measurable (imo around 12% more network traffic from the replies on auth-only servers). ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Generic reasons for recursive performance not to peg CPU?
In article mailman.2014.1389579103.20661.bind-us...@lists.isc.org, Doug Barton do...@dougbarton.us wrote: Thanks for the response, but you're answering a different question than I asked. :) The question I'm interested in is, Why is the recursive server not pegging the CPU? I'm aware that there will be a difference in qps between auth-only and recursive, but the recursive server seems to be working a lot less hard than the auth server, and I can't figure out why. If the answer isn't already in cache, the server has to fire off the recursive query, and then doesn't have to do anything until the response arrives. But an auth-only server doesn't spend any time waiting for responses. -- Barry Margolin Arlington, MA ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Generic reasons for recursive performance not to peg CPU?
On 01/12/2014 07:30 PM, Barry Margolin wrote: In article mailman.2014.1389579103.20661.bind-us...@lists.isc.org, Doug Barton do...@dougbarton.us wrote: Thanks for the response, but you're answering a different question than I asked. :) The question I'm interested in is, Why is the recursive server not pegging the CPU? I'm aware that there will be a difference in qps between auth-only and recursive, but the recursive server seems to be working a lot less hard than the auth server, and I can't figure out why. If the answer isn't already in cache, The answers are all in cache. We're pre-loading the data, and only running queries for data that we're pre-loading. Doug ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
