Downgraded to BIND 9.9.6, the leak is gone, using the same named.conf,
same HW, same environment.
It is highly likely there is really a memory leak problem in Bind 9.10.
--
S pozdravem,
Daniel Ryšlink
System Administrator
Dial Telecom a. s.
Křižíkova 36a/237
186 00 Praha 3, Česká Republika
Tel
hi ,
I noticed that at peak hours, BIND response time is relatively high for some
servers.non-cached query takes over 700msI set some kernel parameters to tune
the network and sockets for redhat 6 and set some global options to tune the
BIND by modifying the cache settings, but neither I get th
The parameter that is glaringly missing from your list is “recursive-clients”.
Do you have that set at default value (1000) or have you bumped it up higher?
Since you say that this happens at “peak hours”, recursive-clients is the prime
suspect, since it governs how many *simultaneous* recursive
At Mon, 26 Jan 2015 21:50:37 +,
Darcy Kevin (FCA) wrote:
>
>
> The parameter that is glaringly missing from your list is
> “recursive-clients”. Do you have that set at default value (1000) or
> have you bumped it up higher? Since you say that this happens at “peak
> hours”, recursive-clients
my experimental zone (the family site) klam.ca has a KSK and a ZSK.
There appear to be time differences between the records reported by DIG
and the source records on file.
In the case of the ZSK the inactive date-time is a few hours different,
but in the ZSKs case it is 3 months.
Is this a pro
oops!! I swapped the ZSK and KSK in the table.
On January 26, 2015 9:09:40 PM John wrote:
my experimental zone (the family site) klam.ca has a KSK and a ZSK.
There appear to be time differences between the records reported by DIG
and the source records on file.
In the case of the ZSK the inac
Activation/inactivation is when named starts/stops signing with the key.
Inception/expiratioin is the time perion for which the signature is valid.
These are different time periods and are basically unrelated.
The inception will be < inactivation.
The expiratin will be > activation.
After a ke
Hi Daniel
On Mon, Jan 26, 2015 at 02:56:44PM +0100, Daniel Ryšlink wrote:
> Downgraded to BIND 9.9.6, the leak is gone, using the same named.conf,
> same HW, same environment.
>
> It is highly likely there is really a memory leak problem in Bind
> 9.10.
Because many of these reports are on FreeB
I'm using bind-dlz(bind version 9.10) with mysql to store zone data.
According to the dlz official documents I use the compile arguments "
-enable-threads=no".
Now I use dnstop and netstat to monitor the performance,and find there is a
perfomance bottleneck of bind-dlz.
Once the QPS increses
On Tue, Jan 27, 2015 at 02:50:33PM +0800, WXR wrote:
> I'm using bind-dlz(bind version 9.10) with mysql to store zone data.
> According to the dlz official documents I use the compile
> arguments " -enable-threads=no".
If you're on 9.10, the documentation you're using is somewhat out of date.
Reb
10 matches
Mail list logo
