Re: bind-users Digest, Vol 2842, Issue 2
>> In article , > >> "Darcy Kevin (FCA)" wrote: > >> > >> > Other than the master server(s), where there is no choice but to be > >> > authoritative, at one end of the spectrum, and border resolvers, for > >> > which > >> > there is no choice but to be non-authoritative (since it's not > practical > >> > to > >> > replicate data for the vast diversity of namespaces on the Internet in > >> > which > >> > to resolve queries), at the other end of the spectrum, there is a > middle > >> > ground, where there is a real *choice* as to whether to be > authoritative > >> > (i.e. a slave, possibly a "stealth slave") for internal zones or not. > >> > The > >> > decision of whether to be authoritative or not, is driven by a number > of > >> > factors, such as worst-case-query-performance sensitivity, > availability > >> > requirements, query-frequency-versus-refresh-overhead, available > >> > bandwidth, > >> > DNSSEC, etc. It is perfectly reasonable, architecturally, for a given > >> > DNS > >> > instance to be a stealth slave for some zones and to either delegate, > >> > stub > >> > and/or forward for other zones, or for the default to be one or the > >> > other > >> > (auth-server as default implies having an internal root). Different > >> > zones > >> > have different requirements, different use cases, query patterns, etc. > >> > so why > >> > wouldn't a choice of different configurations for different zones be > >> > appropriate? > >> > >> Being authoritative for your own zones, and recursive for everything > >> else, is generally not a big problem. > >> > >> The problemat case is service providers being authoritative for customer > >> domains and using the same servers for caching. What often happens is > >> that a customer switches to another DNS provider, but doesn't inform > >> their old provider. As a result, all the other customers who use these > >> caching servers continue to get the obsolete version of this customer's > >> domains. > >> > >> When I worked at an ISP a couple of decades ago, I wrote a script that > >> periodically checked the delegations of all the domains we hosted, to > >> make sure they still pointed to us. > >> > >> -- > >> Barry Margolin > >> Arlington, MA > >> > >> > >> -- > >> > >> Message: 4 > >> Date: Wed, 21 Feb 2018 19:02:24 + > >> From: "PENG, JUNAN" > >> To: "bind-users@lists.isc.org" > >> Subject: Help > >> Message-ID: > >> > >> < > c1ce7b7db557e547bde88e3a45cb26fed93...@cafrfd1msgusrjf.itservices.sbc.com> > >> > >> Content-Type: text/plain; charset="us-ascii" > >> > >> Hi > >> > >> I encountered a weir performance issue: > >> > >> > >> Virtual DNS running in VM - (Flavor 4 vCPU), in theory, the named > process > >> can reach to 400% > >> > >> Query Log is On: > >> > >> When Traffic is 35KQPS, Named Process CPU usage can reach to maximum > 260% > >> . but , Even if I increase the traffic to 70KQPS, the named process > CPU > >> usage can't be more than 260% (lot of failure). - still 260% CPU usage, > >> which impact DNS performance significantly. > >> Is there any parameter which impact the performance of DNS? -- No > >> recursive query during my performance test. > >> > >> > >> Query Log is off: > >> Named Process CPU usage can be more than 260%. > >> > >> > >> Why Query log off/on feature is impacting named CPU Usage ? > >> > >> > >> rndc status > >> version: BIND 9.10.5-S1 (Unknown) > >> boot time: Tue, 13 Feb 2018 06:12:53 GMT > >> last configured: Tue, 13 Feb 2018 06:12:53 GMT > >> CPUs found: 4 > >> worker threads: 4 > >> UDP listeners per interface: 3 > >> number of zones: 102 > >> debug level: 0 > >> xfers running: 0 > >> xfers deferred: 0 > >> soa queries in progress: 0 > >> query logging is OFF > >> recursive clients: 0/900/1000 > >> tcp clients: 0/15000 > >> server is up and running > >> > >> > >> BR > >> Michael > >> -- next part -- > >> An HTML attachment was scrubbed... > >> URL: > >> <https://lists.isc.org/pipermail/bind-users/ > attachments/20180221/c27d2c7a/attachment-0001.html> > >> > >> -- > >> > >> Message: 5 > >> Date: Wed, 21 Feb 2018 19:09:27 + > >> From: Tony Finch > >> To: "PENG, JUNAN" > >> Cc: "bind-users@lists.isc.org" > >> Subject: Re: Help > >> Message-ID: > >> Content-Type: TEXT/PLAIN; charset=US-ASCII > >> > >> PENG, JUNAN wrote: > >> > > >> > Why Query log off/on feature is impacting named CPU Usage ? > >> > >> It has to serialize query processing in order to write to the log, and > >> that serialization barrier limits the parallelism that it can achieve > >> (due to Amdahl's law). > >> > >> Tony. > >> -- > >> f.anthony.n.finchhttp://dotat.at/ - I xn--zr8h > >> punycode > >> South Utsire: Northerly or northeasterly 4 or 5, becoming variable 3 or > 4. > >> Slight or moderate. Fair. Good. > >> > >> > >> -- > >> > >> Subject: Digest Footer > >> > >> ___ > >> bind-users mailing list > >> bind-users@lists.isc.org > >> https://lists.isc.org/mailman/listinfo/bind-users > >> > >> > >> -- > >> > >> End of bind-users Digest, Vol 2842, Issue 2 > >> *** > > > > > > > > ___ > > 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 > > > > > > -- > I don't think the execution is relevant when it was obviously a bad > idea in the first place. > This is like putting rabid weasels in your pants, and later expressing > regret at having chosen those particular rabid weasels and that pair > of pants. >---maf > ___ 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: bind-users Digest, Vol 2842, Issue 2
;> > other >> > (auth-server as default implies having an internal root). Different >> > zones >> > have different requirements, different use cases, query patterns, etc. >> > so why >> > wouldn't a choice of different configurations for different zones be >> > appropriate? >> >> Being authoritative for your own zones, and recursive for everything >> else, is generally not a big problem. >> >> The problemat case is service providers being authoritative for customer >> domains and using the same servers for caching. What often happens is >> that a customer switches to another DNS provider, but doesn't inform >> their old provider. As a result, all the other customers who use these >> caching servers continue to get the obsolete version of this customer's >> domains. >> >> When I worked at an ISP a couple of decades ago, I wrote a script that >> periodically checked the delegations of all the domains we hosted, to >> make sure they still pointed to us. >> >> -- >> Barry Margolin >> Arlington, MA >> >> >> -- >> >> Message: 4 >> Date: Wed, 21 Feb 2018 19:02:24 + >> From: "PENG, JUNAN" >> To: "bind-users@lists.isc.org" >> Subject: Help >> Message-ID: >> >> >> >> Content-Type: text/plain; charset="us-ascii" >> >> Hi >> >> I encountered a weir performance issue: >> >> >> Virtual DNS running in VM - (Flavor 4 vCPU), in theory, the named process >> can reach to 400% >> >> Query Log is On: >> >> When Traffic is 35KQPS, Named Process CPU usage can reach to maximum 260% >> . but , Even if I increase the traffic to 70KQPS, the named process CPU >> usage can't be more than 260% (lot of failure). - still 260% CPU usage, >> which impact DNS performance significantly. >> Is there any parameter which impact the performance of DNS? -- No >> recursive query during my performance test. >> >> >> Query Log is off: >> Named Process CPU usage can be more than 260%. >> >> >> Why Query log off/on feature is impacting named CPU Usage ? >> >> >> rndc status >> version: BIND 9.10.5-S1 (Unknown) >> boot time: Tue, 13 Feb 2018 06:12:53 GMT >> last configured: Tue, 13 Feb 2018 06:12:53 GMT >> CPUs found: 4 >> worker threads: 4 >> UDP listeners per interface: 3 >> number of zones: 102 >> debug level: 0 >> xfers running: 0 >> xfers deferred: 0 >> soa queries in progress: 0 >> query logging is OFF >> recursive clients: 0/900/1000 >> tcp clients: 0/15000 >> server is up and running >> >> >> BR >> Michael >> -- next part -- >> An HTML attachment was scrubbed... >> URL: >> <https://lists.isc.org/pipermail/bind-users/attachments/20180221/c27d2c7a/attachment-0001.html> >> >> -- >> >> Message: 5 >> Date: Wed, 21 Feb 2018 19:09:27 + >> From: Tony Finch >> To: "PENG, JUNAN" >> Cc: "bind-users@lists.isc.org" >> Subject: Re: Help >> Message-ID: >> Content-Type: TEXT/PLAIN; charset=US-ASCII >> >> PENG, JUNAN wrote: >> > >> > Why Query log off/on feature is impacting named CPU Usage ? >> >> It has to serialize query processing in order to write to the log, and >> that serialization barrier limits the parallelism that it can achieve >> (due to Amdahl's law). >> >> Tony. >> -- >> f.anthony.n.finchhttp://dotat.at/ - I xn--zr8h >> punycode >> South Utsire: Northerly or northeasterly 4 or 5, becoming variable 3 or 4. >> Slight or moderate. Fair. Good. >> >> >> -- >> >> Subject: Digest Footer >> >> ___ >> bind-users mailing list >> bind-users@lists.isc.org >> https://lists.isc.org/mailman/listinfo/bind-users >> >> >> -- >> >> End of bind-users Digest, Vol 2842, Issue 2 >> *** > > > > ___ > 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 > -- I don't think the execution is relevant when it was obviously a bad idea in the first place. This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. ---maf ___ 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: bind-users Digest, Vol 2842, Issue 2
ilure). - still 260% CPU usage, > which impact DNS performance significantly. > Is there any parameter which impact the performance of DNS? -- No > recursive query during my performance test. > > > Query Log is off: > Named Process CPU usage can be more than 260%. > > > Why Query log off/on feature is impacting named CPU Usage ? > > > rndc status > version: BIND 9.10.5-S1 (Unknown) > boot time: Tue, 13 Feb 2018 06:12:53 GMT > last configured: Tue, 13 Feb 2018 06:12:53 GMT > CPUs found: 4 > worker threads: 4 > UDP listeners per interface: 3 > number of zones: 102 > debug level: 0 > xfers running: 0 > xfers deferred: 0 > soa queries in progress: 0 > query logging is OFF > recursive clients: 0/900/1000 > tcp clients: 0/15000 > server is up and running > > > BR > Michael > ------ next part -- > An HTML attachment was scrubbed... > URL: <https://lists.isc.org/pipermail/bind-users/ > attachments/20180221/c27d2c7a/attachment-0001.html> > > -- > > Message: 5 > Date: Wed, 21 Feb 2018 19:09:27 + > From: Tony Finch > To: "PENG, JUNAN" > Cc: "bind-users@lists.isc.org" > Subject: Re: Help > Message-ID: > Content-Type: TEXT/PLAIN; charset=US-ASCII > > PENG, JUNAN wrote: > > > > Why Query log off/on feature is impacting named CPU Usage ? > > It has to serialize query processing in order to write to the log, and > that serialization barrier limits the parallelism that it can achieve > (due to Amdahl's law). > > Tony. > -- > f.anthony.n.finchhttp://dotat.at/ - I xn--zr8h > punycode > South Utsire: Northerly or northeasterly 4 or 5, becoming variable 3 or 4. > Slight or moderate. Fair. Good. > > > -- > > Subject: Digest Footer > > ___ > bind-users mailing list > bind-users@lists.isc.org > https://lists.isc.org/mailman/listinfo/bind-users > > > -- > > End of bind-users Digest, Vol 2842, Issue 2 > *** > ___ 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
