On 27.8.2015 3.08, Steve Shipway wrote: > Thanks for this information; it would be useful to have more details > on the Monitor interface in the next version of the manual?
Noted, thanks. > This is what we call the <ClientListSQL> section; sorry for the > confusion. All of our node/client definitions are in a separate > database table which is externally managed. Ok, I thought it might be SQL client list but was not sure since RefreshPeriod has been around for a while. > Checking the (latest version of the) manual, I see that a SIGHUP > causes the table to be re-read, though it also seems to reset the > statistics which is still a problem for constant monitoring since, as > you noted, the statstics really need a baseline of ~100 samples to be > accurate, and during quiet periods this can take some time. We > re-read the clients every 30min to catch updates, which causes odd > statistics outside of busy times. Yes, I can see the problem here. If the stats are read just after reload, you'll see spikes and odd hiccups. The same problem happens with RefreshPeriod too, as you were already thinking might happen. A quick look indicates it should be possible to carry over the client stats during SIGHUP or periodic SQL reload for the unchanged clients. I do not yet know when this might happen, but I've made a ticket to request this. Thanks! Heikki -- Heikki Vatiainen <h...@open.com.au> Radiator: the most portable, flexible and configurable RADIUS server anywhere. SQL, proxy, DBM, files, LDAP, NIS+, password, NT, Emerald, Platypus, Freeside, TACACS+, PAM, external, Active Directory, EAP, TLS, TTLS, PEAP, TNC, WiMAX, RSA, Vasco, Yubikey, MOTP, HOTP, TOTP, DIAMETER etc. Full source on Unix, Windows, MacOSX, Solaris, VMS, NetWare etc. _______________________________________________ radiator mailing list radiator@open.com.au http://www.open.com.au/mailman/listinfo/radiator
