we use nsd version 2.3.3 with currently 53000 active zones. Within nsd.zones - file we have 9000 commented zones, so that our nsd.zones keeps 62000 entrys. The size is 3,5 Mb. All active zones together have 400000 records.
The application "zonec" needs 5-6 minutes to rebuild nsd.database (current size: 15Mb) on a Sun Fire 280 Ultrasparc III 900MHz with 1GB Ram.
The load of Maschine keeps 0.1-0.2 while zonec rebuilds nsd.database.
My questions are:
- Do you also need this time to rebuild nsd.database?
- Why keeps the load at such low level?
- Is it possible to accelerate the rebuild process?
The load is very low? zonec will basically read through the nsd.zones
file and read each of the zone files in turn, read it into memory.
When it is completely done it will write the nsd.database file.
Since the load is low it must be waiting on something. It could be
waiting for the disk - to access the zone files. Zonec does nothing else.
You could try and see how long it takes to access the files - in the
order they are listed in nsd.zones, and cat them to dev null. That
should give the same random access pattern.
If load includes processes waiting for the disk (disk IO), then it must
be waiting on something else, perhaps it is swapping to disk (it reads
the entire database into memory first, 15-30Mb I guess). But you have a
gig of memory, so I guess not.
To accelerate the build process, reordering the names in nsd.zone could
possibly help. Zonec can also build your database by invoking
cat allzonefiles/* | zonec -f nsd.database -o example.net -
(zonefiles need $ORIGIN statements), for zonec this makes little
difference in operation, but the disk access is done by cat.
This _might_ be a problem of keeping too many files in one folder.
One registry I know had great problems when all entries were in speparate files in one folder to build one zone file.
Some speed up was gained by using 26 (ish) separate folders for the first letter of each entry. Further speedup was gained when using four layers of folders to greatly reduce the number of inodes in the directory (not the inodes in the directory entries!)
thank you very much for all your answers.
I make some tests on two different systems to realize the problem.
The first Maschine is like already called Sun Fire 280, the second one
an AMD Opteron with 2GHz.
Command 1:
time xargs cat < nsd.zones > /dev/null 2> /dev/null
Maschine 1 (Sun):
real 0m13.410s
user 0m4.430s
sys 0m5.300s
Maschine 2 (Opteron):
real 0m1.321s
user 0m0.830s
sys 0m0.490s
Command 2:
The second command is quite more interesting:
time rndc rebuild
Maschine1 (Sun):
real 9m8.578s
user 0m23.090s
sys 0m13.770s
Maschine 2(Opteron):
real 3m3.095s
user 2m41.320s
sys 0m7.200s
The user process of zonec on the Sun Maschine just runs with 10% cpu
load. On Opteron it takes 90% cpu load.
Maybe we here have a maschine problem.
Regards,
Irenäus Becker
Hi,
This _might_ be a problem of keeping too many files in one folder.
One registry I know had great problems when all entries were in
speparate files
in one folder to build one zone file.
Some speed up was gained by using 26 (ish) separate folders for the
first letter
of each entry. Further speedup was gained when using four layers of
You don't mention operating system, but if Solaris, you can effectively
move the files into a memory file system by doing any/all file-io work
in /tmp; or create a new swapfs filesystem to do similar.
Under linux, you can do the same with /dev/shm
In either case this will help hugely if you are disk-io bound, and have
spare memory to play with.
Just don't forget to copy the files back out.
We've done similar: linking Oracle database files from disk to their own
swapfs as part of an initial system load. Shrank an 8 hour load down to
~6 minutes; 4-way Sun V440's with 16Gb ram => 10Gb swapfs. YMMV.
BTW, if Solaris, grab and install a copy of the SEToolkit if < Solaris
10. Great for quickly discovering where bottlenecks are. Use DTrace if 10.
HTH?
- Steve
on 13/06/2006 3:40 AM Irenäus Becker said the following:
