I received two good responses. See below. The problem actually went away
on reboot. It is likely to be related to another problem which is proving
somewhat intractable relating to TruCLuster ASE. We will be taking some
of the good advice given below.
+---------------------------------------------------------------------+
| John Miller | Internet Mail - John.Miller_at_jcu.edu.au |
| Computer Centre |
| James Cook University of North Queensland | Phone: +61 7 4781 5447 |
| Townsville, 4811, AUSTRALIA | Fax: +61 7 4781 5230 |
+---------------------------------------------------------------------+
From: Paul A Vixie <paul_at_vix.com>
is anything syslogged? does tcpdump report any tcp/53 traffic?
From: Kevin Oberman <oberman_at_es.net>
This problem is best taken to the BIND folk.
At initialization, BIND 8 forks off a copy of named to read in each
zone file on the local system. I would guess that you have a great
many zones for which you are either master or slave server. When too
many processes are forked, you run out of swap space and the system
grinds to a halt.
I would also guess that you are doing immediate swap space allocation
such that space is preallocated for each process at startup. This
tends to cause exhaustion of swap space when a multiple processes are
forked quickly and the size of the process is large. 'man swapon'
describes this behavior.
To keep BIND and other large processes that fork happy, I recommend
changing from from immediate swap allocation to deferred
allocation. To do this, simply 'rm /sbin/swapdefault' and reboot. The
file is a link to the swap device and may be re-created with the
command 'ln -s /dev/rzxb /sbin/swapdefault', but I doubt you will ever
need to do so.
I run all of my nameservers in deferred mode and have never run out of
swap space. (In fact, I run all systems in deferred mode.) It greatly
reduces the required size of the swap partition(s) at the cost of a
small performance hit when swap space must be allocated on the fly.
In addition, I believe that the transfers-in option may restrict how many
processes may be forked.
R. Kevin Oberman, Network Engineer
Energy Sciences Network (ESnet)
Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab)
E-mail: oberman_at_es.net Phone: +1 510 486-8634
Original problem description:
From: John Miller <John.Miller_at_jcu.edu.au>
To: osfmanagers <alpha-osf-managers_at_ornl.gov>
Subject: bind v8.1.2 keeps creating new named processes
Running Digital Unix V4.0B and bind V8.1.2
When named starts it creates about ten processes of itself and these
keep generating new processes gradually until the system starts running
out of swap space.
It always used to run with a single named process. We can't think what
has changed to cause the new behaviour. Can anyone suggest the reason
please?
Thanks
+---------------------------------------------------------------------+
| John Miller | Internet Mail - John.Miller_at_jcu.edu.au |
| Computer Centre |
| James Cook University of North Queensland | Phone: +61 7 4781 5447 |
| Townsville, 4811, AUSTRALIA | Fax: +61 7 4781 5230 |
+---------------------------------------------------------------------+
Received on Fri Sep 04 1998 - 05:43:06 NZST