nsd users - Aug 2006 - regular statistics dumps getting out of sync

The BIND8 like STATS in nsd are of great help, so I have a nameserver (2.3.3)
running with "-s 60" to dump those statistics every minute. The data
is
read, processed and fed into rrdtool to provide some query graphs.

Now it turns out that every now and then an interval doesn't last 60 seconds
but 61 instead. This may happen since alarm() doesn't guarantee instant
delivery. It would be nice, though, if the alarm restart tried to resync
the interval.

Instead of 

#ifdef BIND8_STATS
          alarm(nsd.st.period);
#endif

I'd like to propose that nsd set the alarm to
	nsd->st.period - (time(NULL) - nsd->st.boot) % nsd->st.period
that is, the remaining time for a multiple of the "-s" interval.

Even better for rrdtool use, the first dump would occur on a predictable
boundary, e.g. for 60 second intervals it would be written on the first
full minute, so the initial value would read

	nsd->st.period - nsd->st.boot % nsd->st.period

There's still a potential race condition, of course. And you wouldn't
want
to try "-s 1".

Opinions?

-Peter

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi Peter,

Although we could resync the interval, you keep the race condition. You
are trying to run two processes, both at 1 minute intervals and want to
keep them synchonised. I think that a solution that avoids race
conditions altogether (and keeps NSD feature-clean :) ) is to signal
rrdtool when STATS appear.

I do not know exactly how you are feeding the data into rrdtool, but the
docs I could find say that rrdtool can take date from any time point,
even if you want to see it on the minute (it interpolates).

You can start a shell script, to
	tail -f $nsd_logfile | grep '[XN]STATS' | while read; do kill -HUP
$rrdtool_pid; done &
So that when STATS appear in the logfile, the $rrdtool_pid is signalled.

So tail will be blocking on a read on the logfile, and when the file is
written it unblocks and your PID of choice is sent a signal. It HUPs
twice, for NSTATS and XSTATS, not sure if rrdtool likes that.

Hope this helps,

Best regards,
   Wouter

Peter Koch wrote:
> The BIND8 like STATS in nsd are of great help, so I have a nameserver
(2.3.3)
> running with "-s 60" to dump those statistics every minute. The
data is
> read, processed and fed into rrdtool to provide some query graphs.
> 
> Now it turns out that every now and then an interval doesn't last 60
seconds
> but 61 instead. This may happen since alarm() doesn't guarantee instant
> delivery. It would be nice, though, if the alarm restart tried to resync
> the interval.
> 
> Instead of 
> 
> #ifdef BIND8_STATS
>           alarm(nsd.st.period);
> #endif
> 
> I'd like to propose that nsd set the alarm to
> 	nsd->st.period - (time(NULL) - nsd->st.boot) % nsd->st.period
> that is, the remaining time for a multiple of the "-s" interval.
> 
> Even better for rrdtool use, the first dump would occur on a predictable
> boundary, e.g. for 60 second intervals it would be written on the first
> full minute, so the initial value would read
> 
> 	nsd->st.period - nsd->st.boot % nsd->st.period
> 
> There's still a potential race condition, of course. And you
wouldn't want
> to try "-s 1".
> 
> Opinions?
> 
> -Peter
> _______________________________________________
> nsd-users mailing list
> nsd-users at NLnetLabs.nl
> http://open.nlnetlabs.nl/mailman/listinfo/nsd-users
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iD8DBQFE1zMAkDLqNwOhpPgRAr85AJ9i/zTSKGKzGNFwu+0zGhOkUcYWVwCfYKN7
VvcaTjXqJgCpcGhLPG+cpxg=NAc3
-----END PGP SIGNATURE-----