Optimising rndc reload times on a slave server with 50,000 zones

Dennis Perisa dennis.perisa at gmail.com
Sun Feb 27 06:15:48 UTC 2011


Thanks Doug.  Yes, helps a lot.  And yes, this is to handle adding new
zones.

Glad I'm on the right track :)  I should point out that those ideas came
from trawling this and many other forums!

I should also point out that when I said "short-term fix", I meant these
were changes we could implement relatively quickly compared to upgrading
hardware.  These fixes would certainly remain in place for the long term.

600,000 zones!!  Can I ask what type of hardware you were using?  We are
unfortunately running on old h/w and o/s - hp dl380 g4 with FreeBSD 6.  So
any other tips for optimisation would be greatly appreciated.

DP

On Sun, Feb 27, 2011 at 3:22 PM, Doug Barton <dougb at dougbarton.us> wrote:

> On 02/26/2011 18:56, Dennis Perisa wrote:
>
>> Hi folks,
>>
>> I'm looking for suggestions to substantially improve reload times on a
>> slave that is serving 50,000 zones (mostly customer zones).
>>
>> 'rndc reload' is being executed on the slave every 15 minutes.
>>
>
> Yeah, don't do that. :)  Is this being done to handle updates to customer
> zones? If so, you're much better off to reload them individually (rndc
> reload zonename), or better yet use dynamic updates. If you're doing this
> for other reasons you need to expand.
>
>
>  Due to
>> the large number of zones to trawl through, the reload process is
>> causing intermittent outages and/or significant delays to zone transfers.
>>
>
> Familiar problem.
>
>
>  Here are some ideas I have:
>> - use rndc reconfig instead
>>
>
> This sounds like you're trying to handle _adding_ new customer zones. In
> that case, yes you're much better off with reconfig.
>
>
>  - separate zone files into separate dirs to improve O/S performance
>> (currently, all zone files are in a single dir)
>>
>
> Depending on your OS this can help quite a bit. 10k files in one directory
> is the point where you can start to see problems, so 50k is likely well past
> this point. I had a structure with one level based on the first character of
> the domain, and the next level based on the first 2 characters. That way you
> should be able to keep all the directories down to less than 5k files (due
> to uneven distribution of first characters in domain names).
>
>
>  Are these viable options?  Any other thoughts/suggestions?
>>
>
> I did all 3 of these things in the past to handle over 600,000 zones, so
> you're definitely on the right track.
>
>
>  This is expected to be a short-term fix while we consider brute force
>> approach of throwing more cpu/mem/IO at this.
>>
>
> Depending on how much you plan to grow going forward you probably shouldn't
> consider these short-term steps.
>
>
> hth,
>
> Doug
>
> --
>
>        Nothin' ever doesn't change, but nothin' changes much.
>                        -- OK Go
>
>        Breadth of IT experience, and depth of knowledge in the DNS.
>        Yours for the right price.  :)  http://SupersetSolutions.com/
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20110227/a816186e/attachment.html>


More information about the bind-users mailing list