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