22 Pro
2013
22 Pro
'13
18:34
Hi Knot developers,
I'm testing Knot 1.4.0-rc2, which is configured with 5167 zones, all
slaves. When I start Knot, it has to bootstrap all of them. It manages
to bootstrap 4331 of them, but for the other 832, I get SERVFAIL from
the master. Knot schedules retries for them within a 5-minute period,
with some jitter. But with 832 zones, they keep coming up for AXFR
continuously, and Knot keeps trying continuously.
I'd like to request an improvement to Knot's scheduler so that it tries
failing zones less and less frequently, to avoid being stuck in a retry
cycle. How about some kind of exponentail back-off with a sane maximum
of something like 24 hours?
Before anyone asks why those 832 zones are SERVFAILing, I'll tell you.
They're not under my direct control, and I can't get the operators to
fix that easily, but I'm stuck with them, so I have to deal with them.
Regards,
Anand Buddhdev
RIPE NCC
22 Pro
22 Pro
19:06
Hi there,
it is progressive at the moment, but it probably doesn't suit well for
this issue.
The progression is set to random 0-30s increments up to 10 minutes maximum.
The question is now what is sane, I'd like to avoid another configurable here.
To start the ball rolling, the attached patch tweaks the settings to
double the previous interval plus jitter (30s).
I think it is a good compromise that allows relatively fast few tries
(about 3 in a few subsequent minutes) and spins
into hours in about 7 tries. Interval cap is set at the 24 hours, it
seems reasonable as the zone can be always refreshed using knotc. The
cut-off could be a bit more aggressive probably, that's the open
question.
Marek
On 22 December 2013 22:34, Anand Buddhdev <anandb(a)ripe.net> wrote:
Hi Knot developers,
I'm testing Knot 1.4.0-rc2, which is configured with 5167 zones, all
slaves. When I start Knot, it has to bootstrap all of them. It manages
to bootstrap 4331 of them, but for the other 832, I get SERVFAIL from
the master. Knot schedules retries for them within a 5-minute period,
with some jitter. But with 832 zones, they keep coming up for AXFR
continuously, and Knot keeps trying continuously.
I'd like to request an improvement to Knot's scheduler so that it tries
failing zones less and less frequently, to avoid being stuck in a retry
cycle. How about some kind of exponentail back-off with a sane maximum
of something like 24 hours?
Before anyone asks why those 832 zones are SERVFAILing, I'll tell you.
They're not under my direct control, and I can't get the operators to
fix that easily, but I'm stuck with them, so I have to deal with them.
Regards,
Anand Buddhdev
RIPE NCC
_______________________________________________
knot-dns-users mailing list
knot-dns-users(a)lists.nic.cz
https://lists.nic.cz/cgi-bin/mailman/listinfo/knot-dns-users
19:27
On 22/12/2013 23:06, Marek Vavruša wrote:
Hi Marek,
Thanks for the patch, but it fails to apply against 1.4.0-rc2. I get:
$ patch -p1 < ../../axfr_retry_cutoff.patch
patching file src/knot/server/xfr-handler.c
Hunk #1 FAILED at 321.
1 out of 1 hunk FAILED -- saving rejects to file
src/knot/server/xfr-handler.c.rej
patching file src/knot/server/zones.h
Hunk #1 FAILED at 43.
1 out of 1 hunk FAILED -- saving rejects to file src/knot/server/zones.h.rej
it is progressive at the moment, but it probably
doesn't suit well for
this issue.
The progression is set to random 0-30s increments up to 10 minutes maximum.
The question is now what is sane, I'd like to avoid another configurable here.
To start the ball rolling, the attached patch tweaks the settings to
double the previous interval plus jitter (30s).
I think it is a good compromise that allows relatively fast few tries
(about 3 in a few subsequent minutes) and spins
into hours in about 7 tries. Interval cap is set at the 24 hours, it
seems reasonable as the zone can be always refreshed using knotc. The
cut-off could be a bit more aggressive probably, that's the open
question.
25 Pro
25 Pro
7:02
On 22/12/2013 23:06, Marek Vavruša wrote:
Hi Marek,
To start the ball rolling, the attached patch tweaks
the settings to
double the previous interval plus jitter (30s).
I think it is a good compromise that allows relatively fast few tries
(about 3 in a few subsequent minutes) and spins
into hours in about 7 tries. Interval cap is set at the 24 hours, it
seems reasonable as the zone can be always refreshed using knotc. The
cut-off could be a bit more aggressive probably, that's the open
question.
I've had this backoff patch running for a couple of days now. If I look
at all the failing zones now, their retry period has settled at one of 2
values:
17h23m57s
17h23m58s
This means that the algorithm you've programmed ends up with this
maximum, instead of 24h. It's not a problem for me. 17h is a good enough
retry period. I just wanted Knot to stop trying to refresh these zones
aggressively, and your patch has achieved it.
However, I thought I'd provide this feedback, so that if you wish to
refine the algorithm a bit more, you have some numbers to work with.
Regards,
Anand
4553
days inactive
4556
days old
3 comments
2 participants
participants (2)
-
Anand Buddhdev -
Marek Vavruša