> It would be difficult, and possibly impossible, to continue to
> process queries and format a report on queries simultaneously
> without losing information in the report. To have a separate
> thread creating the report, it might have to stop query
> processing, take a snapshot of the data at tha
-Original Message-
From: bind-users [mailto:bind-users-boun...@lists.isc.org] On Behalf Of
Havard Eidnes
Sent: Wednesday, September 6, 2017 8:40 AM
To: m...@conundrum.com
Cc: bind-us...@isc.org
Subject: Re: Strange recursor response time pattern
>> Is that pulling the old-style stats file,
>> Is that pulling the old-style stats file, or the HTTP-based stats channel?
As should be evident from my other message, this is using the
HTTP-based stats channel.
> If the latter... the zone list (and by extension the root
> document) seems to take a long time to process, and involves
> some s
>> The stats channel output relating to running tasks and memory contexts
>> is very extensive.
>
> Either way I would not have expected use of the statistics
> channel to negatively impact the query performance. Is the query
> channel processed with "no-delay", so that a thread doesn't get
> stuc
>> some further local discussion has made me aware that us running
>> "collectd" for monitoring BIND may be contributing to the
>> problem; collectd fetches data each 10s by using the BIND-
>> configured statistics-channel, thus BIND is processing a TCP
>> connection to deliver the statistics data.
On 5 September 2017 at 11:56, Havard Eidnes wrote:
> Hmm...
>
> some further local discussion has made me aware that us running
> "collectd" for monitoring BIND may be contributing to the
> problem; collectd fetches data each 10s by using the BIND-
> configured statistics-channel, thus BIND is pr
On 05/09/2017 16:56, Havard Eidnes wrote:
> Hmm...
>
> some further local discussion has made me aware that us running
> "collectd" for monitoring BIND may be contributing to the
> problem; collectd fetches data each 10s by using the BIND-
> configured statistics-channel, thus BIND is processing a
Hmm...
some further local discussion has made me aware that us running
"collectd" for monitoring BIND may be contributing to the
problem; collectd fetches data each 10s by using the BIND-
configured statistics-channel, thus BIND is processing a TCP
connection to deliver the statistics data.
It's
On 05.09.17 16:44, Havard Eidnes wrote:
It seems that every 10s, "on the clock", BIND will temporarily
increase the query response time rather drastically for a short while,
only to settle down to normal behaviour until the next 10s event.
Any idea what might be causing this? Anything I can d
9 matches
Mail list logo