From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6)
Description of problem:
Firstly, a bit of background.
We run a Very Large Nameserver(tm). The specification of the box alone
is a dual Intel P4 Xeon 2GHz, hyperthreading enabled so appears as 4
CPUs, 4GB of memory and 9GB of swap space. We thought this would be...
more than capable of doing it's job, given it's predecessor running
bind 8. But we're encountering one very big problem.
The nameserver has 567,849 zones in it's configuration file. Once
loaded (a lengthy process), it consumes around 1.7GB of memory. After
a few hours of running, the usage goes up to around 2.7GB. Originally,
the box was equipped with 1GB of memory and a measly amount of swap,
so we went out and purchased a further 3GB of memory to compensate.
At first, we started with a bog standard 2.4.22-1.2174.nptlsmp kernel
(i686 build). Aware that the memory limit for this kernel is 4GB, we
grabbed the source RPM and edited the spec to build a bigmem
(HIGHMEM64G) kernel with 64GB limit. Enabled the swap space and restarted.
No matter what happens now, with both 2.4.22-1.2174.nptlsmp and
2.4.22-1.2174.nptlbigmem, whenever we issue "rndc reload", leave the
box about 10 minutes and we get:
Mar 16 06:37:15 <hostname> named: reloading configuration failed:
out of memory
...which we get the feeling shouldn't happen with 13GB of available
combined memory and swap.
We're getting around the issue at the moment by once per day stopping
the named process completely and starting it again.
Is there something we've missed? Should it be failing to reload?
Any insights you have would be very gratefully received :)
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Start nameserver completely.
2. Leave to run for 2-3 hours.
3. Issues 'rndc reload' from root shell and watch /var/log/messages
for "out of memory" message.
Actual Results: named process continues to run but with old
configuration and zone data.
Expected Results: It should have reloaded the configuration, new
zones and updated zones.
Kernel packages used:
davej informs me that this is most likely due to the per-process
memory limit, namely 1G kernel/3G process. So as such this isn't a
problem with bind.
I should most likely close this then. Sorry to trouble you!