BIND 9.3.2 Memory Leak?
Etienne
for 60-100 hours. It usually happens when I do a rndc reload.
Any of you know how to fix that?
Here is what i can see when it crashes:
# nslookup
> yahoo.com
Server: 127.0.0.1
Address: 127.0.0.1#53
** server can't find yahoo.com: SERVFAIL
> exit
# top
Mem: 525M Active, 256M Inact, 165M Wired, 47M Cache, 111M Buf, 3496K Free
Swap: 2048M Total, 60K Used, 2048M Free
PID USERNAME PRI NICE SIZE RES STATE TIME WCPU CPU COMMAND
67330 root 96 0 516M 515M select 79:50 0.00% 0.00% named
Every other process take no or almost no memory
Then it craps out with those errors:
10:23:05named[: resolver.c:2870: unexpected error:
10:23:05named[: isc_timer_create: out of memory
10:23:20 ruff named[67330]: timer.c:650: unexpected error:
10:23:20 ruff named[67330]: couldn't allocate event
10:26:37named[: isc_timer_create: out of memory
10:30:01named[: dropped command channel from 127.0.0.1#55422: out of memory
10:59:09named[: ifiter_getifaddrs.c:61: unexpected error:
10:59:09named[: getting interface addresses: getifaddrs: Cannot allocate
memory
11:00:00named[: dropped command channel from 127.0.0.1#63784: out of memory
11:00:01named[: cache cleaner could not create iterator: out of memory
11:00:01named[: cache.c:610: unexpected error:
11:00:01named[: cache cleaner: dns_dbiterator_first() failed: out of memory
I had no response on my original post(F.R.A.T.):
"
I have a 2 BIND servers and the second one copies data(zone files) and
reloads it every hour or so.
The version of the BIND is 9.3.2
This always happens after bind runs for 60-100hours. It crashes every time.
11:00:01 server named[20174]: dns_master_load: out of memory
11:00:01 server named[20174]: could not configure root hints
from'named.root': out of memory
11:00:01 server named[20174]: reloading configuration failed: out of memory
Now the weird thing is that I had BIND running with the exact same
configuration on another server and it never crashed.
Also I had the same config on the same server with another version of the OS
and another version of bind and it never crashed.
I browsed other posts about the out of memory issue and it said to change
the datasize variable.
Right now, I have no Datasize variable set in named.conf so the default is
default(from bind's admin book).
It says "default uses the limit that was in force when the server was
started.". Now I have no idea how much that is and how much i should put as
datasize variable.
Do you know how to check the size of the datasize if it's set to default?
Do you guys ever had this problem before and have an idea of a good
datasize?(I guess it depends on what you do with the server and what kind of
server it is...)
----------
6.2.16.9. Operating System Resource Limits
The server's usage of many system resources can be limited. Scaled values
are allowed when specifying resource limits. For example, 1G can be used
instead of 1073741824 to specify a limit of one gigabyte. unlimited requests
unlimited use, or the maximum available amount. default uses the limit that
was in force when the server was started. See the description of size_spec
in Section 6.1.
The following options set operating system resource limits for the name
server process. Some operating systems don't support some or any of the
limits. On such systems, a warning will be issued if the unsupported limit
is used.
coresize
The maximum size of a core dump. The default is default.
datasize
The maximum amount of data memory the server may use. The default is
default. This is a hard limit on server memory usage. If the server attempts
to allocate memory in excess of this limit, the allocation will fail, which
may in turn leave the server unable to perform DNS service. Therefore, this
option is rarely useful as a way of limiting the amount of memory used by
the server, but it can be used to raise an operating system data size limit
that is too small by default. If you wish to limit the amount of memory used
by the server, use the max-cache-size and recursive-clients options instead.
files
The maximum number of files the server may have open concurrently. The
default is unlimited.
stacksize
The maximum amount of stack memory the server may use. The default is
default.
----------
"
Etienne
Ender Alexander Mujica Díaz
fallas en los DNS se debe a que por defecto el caché de la aplicación no
tiene limite para el cache lo cual hace que progresivamente se vaya
consumiendo toda la memoria fisica, luego la virtual hasta que comienza
a tener fallas.
*"BIND keeps growing, and growing, and growing. BIND has no limits on
cache size; it tries to cache every record until the record expires.
Under heavy load, BIND will chew up all your physical memory, start
thrashing, chew up all your virtual memory, and then commit hara-kiri,
if it doesn't dump core first."
"According to the BIND company, BIND 9 stays within a memory resource
limit without crashing. Unfortunately, when the cache fills up, BIND 9
discards /new/ cache entries. Performance drops dramatically. The server
begins failing under moderate loads."*
Para resolver esto lo que haremos es limitar la máxima cantidad de
memoria que usa el cache de BIND al 80% (1.6GB) del total (2GB) en la
sección
"options" a través del parámetro *max-cache-size.*
A continuación la descripción del parámetro:
*max-cache-size* defines the maximum amount of memory to use for the
server's cache, in bytes (case insensitive shortforms of k or m are
allowed). When the amount of data in the cache reaches this limit, the
server will cause records to expire prematurely so that the limit is not
exceeded. In a server with multiple views, the limit applies separately
to the cache of each view. The default is unlimited, meaning that
records are purged from the cache only when their TTLs expire. This
statement may be used in view
<http://www.zytrax.com/books/dns/ch7/view.html> or a global options
<http://www.zytrax.com/books/dns/ch7/options.html> clause.
Ender Alexander Mujica Díaz
Here you can find all about max-cache-size.
http://www.zytrax.com/books/dns/ch7/hkpng.html#max-cache-size
We have this parameter in 80% of the physical memory
http://cr.yp.to/djbdns/blurb/cache.html
Joel Nimety
> Here you can find all about max-cache-size.
>
> http://www.zytrax.com/books/dns/ch7/hkpng.html#max-cache-size
I'm not quit sure how to interpret the statement "In a server with
multiple views, the limit applies separately to the cache of each view".
If I set max-cache-size in global options what does this mean?
1) The cache of all views combined cannot exceed max-cache-size
Or
2) Each view has max-cache-size
>
> We have this parameter in 80% of the physical memory
>
> http://cr.yp.to/djbdns/blurb/cache.html
>
>
> Ender Alexander Mujica Díaz wrote:
--
Joel Nimety
--
The sender of this email subscribes to Perimeter Internetworking's email
anti-virus service. This email has been scanned for malicious code and is
believed to be virus free. For more information on email security please visit:
http://www.perimeterusa.com/malicious_code_defense_content.html
This communication is confidential, intended only for the named recipient(s)
above and may contain trade secrets or other information that is exempt from
disclosure under applicable law. Any use, dissemination, distribution or
copying of this communication by anyone other than the named recipient(s) is
strictly prohibited. If you have received this communication in error, please
delete the email and immediately notify our Command Center at 203-541-3444.
Ender Alexander Mujica Díaz
We are not using the view clause because we do not have multiples views
in our DNSs. We are using de *options* clause and inside it there is
the * max-cache-size *statement in bytes.
http://www.zytrax.com/books/dns/ch7/options.html
The *options* clause group together statements that have global scope -
the statemnts apply to all zones or views unless overridden by the same
statement in a view or zone clause. Only one options clause should be
defined in a named.conf file. The options clause can take a serious list
of statements. Full list of statements
<http://www.zytrax.com/books/dns/ch7/statements.html>.
options Clause Syntax
options {
// statements
};
----------------------------------------------------
Here is a sample for the options parameter
options {
directory "/var/named";
allow-transfer {
ww1.xx1.yy1.zz1;
ww2.xx2.yy2.zz2;
ww3.xx3.yy3.zz3
ww3.xx3.yy3.zz
};
/*
* If there is a firewall between you and nameservers you want
* to talk to, you might need to uncomment the query-source
* directive below. Previous versions of BIND always asked
* questions using port 53, but BIND 8.1 uses an unprivileged
* port by default.
*/
// query-source address * port 53;
//listen-on {
aa.bb.cc.dd;
//
//};
* // This is the 80% from 2GB in bytes
max-cache-size 1717986918;*
// This is the max recursive cliente
recursive-clients 20000;
//this is the max tcpclients
tcp-clients 200;
pid-file "/var/run/named/named.pid";
};
----------------------------------------------------------
from: http://www.zytrax.com/books/dns/ch7/view.html
DNS BIND view Clause
This section describes the view clause available in BIND 9.x. The *view*
clause allows BIND to provide different functionality based on the hosts
accessing it. The view statement can take a serious number of statements
shown below. Full list of statements
<http://www.zytrax.com/books/dns/ch7/statements.html>. A view clause
matches (is invoked) when either or both of its match-clients
<http://www.zytrax.com/books/dns/ch7/view.html#match-clients> and
match-destinations
<http://www.zytrax.com/books/dns/ch7/view.html#match-destinations>
statements match and when the match-recursive-only
<http://www.zytrax.com/books/dns/ch7/view.html#match-recursive-only>
condition is met. If either or both of match-clients and
match-destinations are missing they default to *any* (all hosts match).
All zones supported by each view clause must be defined with the view
clause allowing a view to respond uniquely for each zone if required.
*view Clause Syntax*
view "view_name" [class] {
[ *match-clients* { address_match_list } ; ]
[ *match-destinations* { address_match_list } ; ]
[ *match-recursive-only* { yes | no } ; ]
// view statements
// zone clauses
};
*view_name* (a quoted string) is the arbitrary but unique name of this
view. A view clause matches (is invoked) when either or both of its
match-clients
<http://www.zytrax.com/books/dns/ch7/view.html#match-clients> and
match-destinations
<http://www.zytrax.com/books/dns/ch7/view.html#match-destinations>
statements match and when the match-recursive-only
<http://www.zytrax.com/books/dns/ch7/view.html#match-recursive-only>
condition is met. If either or both of match-clients and
match-destinations are missing they default to *any* (all hosts match).
The zones <http://www.zytrax.com/books/dns/ch7/zone.html> that will be
serviced by this *view* must be contained within this view.
The classic example quoted is an alternate implementation of a *split*
or *stealth* DNS configuration on a single server so we will follow in
well trodden steps (see also stealth examples
<http://www.zytrax.com/books/dns/ch6#stealth>):
'split' DNS using views
view "trusted" {
match-clients { 192.168.23.0/24; }; // our network
recursion yes;
zone "example.com" {
type master;
// private zone file including local hosts
file "internal/master.example.com <http://www.zytrax.com/books/dns/ch6/mydomain-internal.html>";
};
// add required zones
};
view "badguys" {
match-clients {"any"; }; // all others hosts
// recursion not supported
recursion no;
};
zone "example.com" {
type master;
// public only hosts
file "external/master.example.com <http://www.zytrax.com/books/dns/ch6/mydomain-external.html>";
};
// add required zones
};
*Notes:*
1. Depending on the required level of security the above
configuration may be deemed vulnerable. If the file system is
compromised then simple inspection of 'named.conf' will allow
penetration of the 'veil of privacy'.
2. *view* is class dependent but the default class is IN (or 'in' -
not case dependent) and has been omitted.
3. The zone files defined in each view do not need to be the same.
4. The required zone files
<http://www.zytrax.com/books/dns/ch7/index.html#required> may
differ in each view e.g. there is no need to provide localhost
zones in the "badguys" view.
5. The zone files for "example.com" are different allowing 'hiding'
of non-public hosts in the "trusted" view.
6. Recursion has been removed in the "badguys" view for performance
and security reasons.
7. 'slave' servers for each zone will see a single 'zone' based on
their IP address i.e. "trusted" or "badguys". However if you
multi-home or 'alias' the IP address on the 'slave' server you can
get both views.
-----------