More than 100 instances of named-xfer.exe running in slave server .

Danny Mayer mayer at gis.net
Tue Jun 19 16:17:11 UTC 2001


Fernando Nerio Fernández wrote:

> Hi Dany,
>         Every single instance (of 120) of named-xfer.exe is consuming in
> average 0.5 to 1% of CPU time, if a start killing some of these instances
> the ones that are still running increase their use of CPU time,  keeping the
> CPU usage at 100% (this happens even when just one instance is running),
> when every single instance of named-xfer.exe is killed , the CPU usage drops
> to 20%.
>
>         I have found the same behaviour in another slave server that I set
> up just for testing.
>
>         Changing from AXFR to IXFR doesn´t make a difference. I am serving
> around 3000 zones on this box.
>
> If no instance of named-xfer.exe is running then the slave would not be able
> to transfer any zone right?

Not exactly.  named-xfer processes get created by the named service as
necessary for each zone that it needs to transfer from the master. When the
transfer is complete, the process should exit and named then picks up the
transferred zone information.  Are you seeing .ixfr.tmp files in your etc.
directory? Are you running the 8.2.4-NT2 version?  If not, upgrade to
that version as there was a zone transfer bug that got fixed.  I don't think
that it's related to your problem, but let's make sure.

    Is the master close by, network-wise, and is it having problems transferring

the zone? Can you take a look at what's going on on the master and see if
the transfers are complete or still going on?  What version is the master
running
and what's the O/S?

    What did you set transfers-per-ns to?  The default is 2.
    What did you set transfers-in to?  The default is 10.
    What did you set max-transfer-time-in to? The default is 2 hours.

  All of these parameters affect your ability to transfer zones.  Try removing
them
and see how it runs.  You need to be very careful about using these parameters
and you should adjust them in small amounts one at a time to see how things
perform first before changing them again.

    Danny



More information about the bind-users mailing list