Re: failed: out of memory
> You'll want to use max-cache-size to enforce a hard limit on the size
> of your cache.
> http://www.zytrax.com/books/dns/ch7/hkpng.html#max-cache-size
>
> /Tim
>
> ---
> Tim Krzywonos
> e:: t...@krzywonos.ca
Thanks for reminding me of that. Now that I have some confidence
that the problem is the cache and not some funny memory leak, I
think I can rely on setting a limit. I still find it strange that
when I dumped the cache, the resulting file was only 6 MB in size.
The process size had grown to 257 MB, up form an initial size of
36 MB. It does not make sense
> On 2014-07-21 10:57, sch...@adi.com wrote:
Have you tried an rndc flush? You can also dump the contents of
>>> the
cache to find the (approximate) size of the cache. If related to
>>> cache,
you can tweak parameters to cache, most namely max-cache-size.
>>> IIRC,
the cache doesn't have a size limit by default.
/Tim
>>> I did an rndc dumpdb -cache and the size of the named_dump.db that
>>> resulted is 5927042. Not all that big condidering how it is
>>> formatted.
>>> Late last night I did a rndc flush. At that time the size of named
>>> was 31305 pages of 8192 bytes. As of now (13 hours later) the size
>>> is still 31305. I will see what happens.
>>
>> See below for our named.conf and then my original description of the
>> problem.
>>
>> As of this morning (3 days 12 hours later) named is still at 31305
>> pages.
>> So it appears that the continuous growth that I was seeing is due to
>> the
>> cache.
>>
>> Unfortunately my investigation has not been very methodical. I should
>> have noted the size of the named process when I was getting the out
>> of
>> memory errors. I also should have noted the rate of growth of
>> 9.9.5-P1
>> before trying 9.9.6b1. I am going to switch back to 9.9.5-P1 for a
>> few
>> days and see if the rate of growth is about the same or if it is much
>> worse. (The initial size was 4734 pages and jumped to 7666 within
>> 5 minutes). Assuming that the cache cleaning is working correctly, it
>> may be that a 32 bit process is just not viable these days. I have
>> now
>> built a 64 bit named and will switch to that in a few days.
>>
>> A big problem is that I will be going on vacation at the end of the
>> week
>> and I really want to make sure that named does not shut down while I
>> am
>> away. There is really not enough time to do enough testing to make
>> sure of that. I may set up a cron job to do a daily rndc flush while
>> I
>> am away.
>>
>>>
>>> I was asked off list for our named.conf. Here it is.
>>> options {
>>> directory "/var/named";
>>> acache-enable yes;
>>> auth-nxdomain no;
>>> transfer-format many-answers;
>>> dnssec-enable yes;
>>> dnssec-validation yes;
>>> dnssec-lookaside auto;
>>> };
>>> managed-keys {
>>> dlv.isc.org. initial-key 257 3 5 .;
>>> };
>>> managed-keys {
>>> "." initial-key 257 3 8 ...;
>>> };
>>>
>>> view "internal" {
>>> match-clients { !192.168.3.95; !192.168.3.150;
>>> !192.168.4.0/24; localnets;
>>> };
>>> sortlist {
>>> { 192.168.2.0/24; { 192.168.2.0/24; 192.168.3.0/24;
>>> }; };
>>> { 192.168.3.0/24; { 192.168.3.0/24; 192.168.2.0/24;
>>> }; };
>>> };
>>> zone "." {
>>> type hint;
>>> file "named.root";
>>> };
>>>
>>> zone "adi.com" {
>>> type master;
>>> file "adi.com.hosts.int";
>>> check-names ignore;
>>> notify explicit;
>>> also-notify {
>>> 192.168.2.95;
>>> 192.168.2.150;
>>> };
>>> };
>>>
>>> zone "130-157.245.100.75.in-addr.arpa" {
>>> type master;
>>> file "75.100.245.130-157.revhosts";
>>> notify explicit;
>>> also-notify {
>>> 192.168.2.95;
>>> 192.168.2.150;
>>> };
>>> };
>>>
>>> zone "2.168.192.in-addr.arpa" {
>>> type master;
>>> file "192.168.2.revhosts.int";
>>> notify explicit;
>>> also-notify {
>>> 192.168.2.95;
>>> 192.168.2.150;
>>> };
>>> };
>>>
>>> zone "3.168.192.in-addr.arpa" {
>>> type master;
>>> file "192.168.3.revhosts.int";
>>> notify explicit;
>>> also-notify {
>>> 192.168.2.95;
>>> 192.168.2.150;
>>> };
>>> };
>>>
>>> zone "4.168.192.in-addr.arpa" {
>>> type master;
>>> file "192.168.2.revhosts.int";
>>> notify explicit;
>>> also-notify {
>>>
Retrying failed zone transfer
Hi! I have a Bind 9.9.5 running as slave. The master is not configured correctly and rejects the zone transfer. It seems that if Bind has never received the zone yet, it tries endlessly to fetch the zone (see below), ~3 times per second. It would be nice if Bind for example retries only every minute or so. Is it possible to configure Bind for such a behavior? Thanks Klaus Jul 22 13:45:34 zone example.it/IN (unsigned): Transfer started. Jul 22 13:45:35 transfer of 'example.it/IN (unsigned)' from 11.22.142.96#53: connected using 33.44.34.24#53814 Jul 22 13:45:35 transfer of 'example.it/IN (unsigned)' from 11.22.142.96#53: failed while receiving responses: NOTAUTH Jul 22 13:45:35 transfer of 'example.it/IN (unsigned)' from 11.22.142.96#53: Transfer completed: 0 messages, 0 records, 0 bytes, 0.031 secs (0 bytes/sec) Jul 22 13:45:35 zone example.it/IN (unsigned): Transfer started. Jul 22 13:45:35 transfer of 'example.it/IN (unsigned)' from 11.22.142.96#53: connected using 33.44.34.24#42776 Jul 22 13:45:35 transfer of 'example.it/IN (unsigned)' from 11.22.142.96#53: failed while receiving responses: NOTAUTH Jul 22 13:45:35 transfer of 'example.it/IN (unsigned)' from 11.22.142.96#53: Transfer completed: 0 messages, 0 records, 0 bytes, 0.031 secs (0 bytes/sec) Jul 22 13:45:35 zone example.it/IN (unsigned): Transfer started. Jul 22 13:45:35 transfer of 'example.it/IN (unsigned)' from 11.22.142.96#53: connected using 33.44.34.24#44017 Jul 22 13:45:35 transfer of 'example.it/IN (unsigned)' from 11.22.142.96#53: failed while receiving responses: NOTAUTH Jul 22 13:45:35 transfer of 'example.it/IN (unsigned)' from 11.22.142.96#53: Transfer completed: 0 messages, 0 records, 0 bytes, 0.031 secs (0 bytes/sec) Jul 22 13:45:35 zone example.it/IN (unsigned): Transfer started. Jul 22 13:45:35 transfer of 'example.it/IN (unsigned)' from 11.22.142.96#53: connected using 33.44.34.24#60674 Jul 22 13:45:35 transfer of 'example.it/IN (unsigned)' from 11.22.142.96#53: failed while receiving responses: NOTAUTH Jul 22 13:45:35 transfer of 'example.it/IN (unsigned)' from 11.22.142.96#53: Transfer completed: 0 messages, 0 records, 0 bytes, 0.031 secs (0 bytes/sec) Jul 22 13:45:36 zone example.it/IN (unsigned): Transfer started. Jul 22 13:45:36 transfer of 'example.it/IN (unsigned)' from 11.22.142.96#53: connected using 33.44.34.24#33693 Jul 22 13:45:36 transfer of 'example.it/IN (unsigned)' from 11.22.142.96#53: failed while receiving responses: NOTAUTH Jul 22 13:45:36 transfer of 'example.it/IN (unsigned)' from 11.22.142.96#53: Transfer completed: 0 messages, 0 records, 0 bytes, 0.031 secs (0 bytes/sec) ___ 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
