Resetting Stats

[John Zalesak]

Currently we reset stats every 12 hours.  I would like to change to resetting stats once per month.

I just checked a busy thread.  In 12 hours we got in 2,611 messages and 3,013,340 bytes.

1) Is there a danger in resetting stats only once per month?

2) Can the numbers in the stats get too big???

Thanks – all comments are appreciated.

Topic

[Jim Kosloskey]

John,

There is probably a point of overflow – but I do not know what that might be.

If you want to make sure a monthly reset will still allow for valid data, try working your way up to it.

For example, keep your stat reset at 12 hours for a day and save off those stats so you can use them for comparison; then change the reset to 24 hours for a day.

Dump the stats for the second day and compare the data to the first day to make sure you are not losing any resolution.

If the resolution is OK, move to every 2 days and re-evaluate the resolution.

Assuming that is OK, reset after a week and re-evaluate the resolution.

If that is OK do 2 weeks, etc. until you reach one month.

You also could simply get your basis at the 12 hour period, then reset after one month and evaluate the resolution.

I am curious what you are utilizing the stats for?

Keep in mind the some of the stats are skewed by situations.

For example the ib and ob latency stats are skewed by arrival rates and response rates, the Xlate times are affected by the loading of the caches the first time a particular Xlate is referenced (first message causing the Xlate to be invoked).

Thus long reset times can skew the ib and ob latency numbers if the duration includes periods of low activity.

Likewise, if resetting and evaluation of the stats take place relatively close to when caches are cleared the Xlate times could be skewed.

As I recall, there are other impacts to be considered in deciding when to reset and evaluate the stats but they do not leap to mind at this time.

email: jim.kosloskey@jim-kosloskey.com 29+ years Cloverleaf, 59 years IT - old fart.

[John Zalesak]

Jim,

Thanks for your reply.

Here is what I am doing with the stats.  I am using the last read time in a Tcl proc that is called for a last received alert.  The Tcl proc bounces the connection if the last recieved time is too long.  I have a counter that counts the number of bounces.  If the number “consecutive” bounces gets to high, I send and email to a blackberry that will wake someone up.  When I say”consecutive” I mean bounces with no messages since the last bounce.  If the last read = a current time -> reset counters.  If last read = epoch -> increment counter.  I also get the time of the last start (bounce) just for info.

Here is my Proc, it might explain it better.  Go easy on me, I just took the Tcl class in Nov.  I tried to write it to be general and flexible.

Code:

[Author]

Replies