[bind10-dev] zonemgr / notify out questions
Jerry Scharf
scharf at isc.org
Tue Sep 14 05:32:10 UTC 2010
I don't have old code to look at, but I suspect the jitter constant
predates BIND 9 and quite possibly BIND 8. It has also probably been
copied to many other code bases. Think of it as similar to the
instructions for the holy hand grenade.
On 9/13/2010 7:26 PM, Likun Zhang wrote:
>> Jeremy,
>>
>> Re: 19
>>
>> jitter is a server operation detail rather than a protocol issue.
>>
>> It is there to ease the following problem: someone updates a whole bunch
>> of zones that each have a bunch of slaves. Without jitter, every refresh
>> cycle from then on, at the refresh expire time all of the slaves will
>> ask the master for an XFR of every zone at exactly the same time. You
>> get a huge spike in the load on the master processing all the transfer
>> requests.
>>
>> With jitter, this gets spread out and the master doesn't fall over. It's
>> one of those operational details that was hard earned learning. So it
>> belongs there at some point and is necessary to call it production
>> level, but a server can ship without it and still be useful. Almost any
>> implementation that meets the general goal is fine. I would guess that
>> 25% range spread (refresh/4) was chosen at a dart board one day. :)
>>
>> hope that helps,
>> jerry S
>>
>>
>>> 19) Is random Refresh jitter defined in any specification? I see it uses
>>> between (zone_refresh_time - ((1 * zone_refresh_time) / 4)) and
>>> zone_refresh_time.
> This is what bind9 does now,
>
> - When bind9 starts, jitter for refresh time is rand() % (retry * 3 / 4),
> - Refresh fails, jitter for next refresh time is rand() % (retry / 4)
> - Refresh successes, jitter for next refresh time is rand() % (refresh/4)
>
> Likun
>
>
>
>
>
More information about the bind10-dev
mailing list