regular statistics dumps getting out of sync

Wouter Wijngaards wouter at NLnetLabs.nl
Mon Aug 7 12:33:05 UTC 2006


-----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-----



More information about the nsd-users mailing list