[rrd-users] Graphing COUNTER values absolutely
linux at thehobsons.co.uk
Wed Mar 19 13:22:23 CET 2008
Felix Castillo Sanchez wrote:
> > > I'm storing Oracle performance values that are continuously increasing.
>> > problem is that a user cannot handle a per second rate because we're
>> > about centiseconds within 5 minutes. So how do I explain an end user
>> > sub-microseconds of wait time can be a performance bottleneck?!
>> Why do you think that it is easier to explain when you multiply
>> the number by some arbitrary value?
>I don't want an arbitrary value - I want to have the rate per second
>multiplied by the seconds that lie between the data points.
Do you mean between fixed intervals (eg every 5 minutes), or between
arbitrary points (eg last changes occurred at 12:04:01, 12:04:07,
If it's the former, then simply multiply the stored rate by 300 and
you have '<somethings> per 5 minute period'.
If it's the latter then rrd is not the right tool for the job.
To expand on that a bit.
Taking the fixed intervals case, suppose that you last samples were
0, 5, 10, and 15 - all at exactly 300 second intervals. The rate is
'5/300 <somethings>/second', or '300 * 5/300 <somethings>/5minute
Taking the second case, then I think what you are looking at is a
bunch of <somethings> happened at 12:04:01 then nothing until
12:04:07 when another bunch of <somethings> happened. Then a gap
until 10:10:57 when another bunch happened. You then want to be able
to show a user that "you did <x>, the result was that <y somethings>
happened while the system was processing job <x>". RRD will NOT store
this information<period> It isn't what it's designed to do.
If each bunch was 5 events, and an update was triggered at each
event, and the step size was 5 minutes, then in the period 12:00:00
to 12:05:00 it would store :
- whatever came before 12:04:01 (we'll assume zero for now)
- plus 5 events between 12:04:01 and 12:04:07
- plus 53/(53+300+57) * 5 between 12:04:07 and 12:05:00
All this combined would store a rate of 5.64634145/300s or 0.018821138/s
for 10:05:00 to 12:10:00 it would store a rate of 300/(53+300+57) * 5
or 3.6585366/300s or 0.012195122/s
the remaining 57/(53+300+57)*5 would go into the 12:10:00 to 12:15:00
bin together with a fraction of future updates.
See the tutorials on data normalisation (see the rrdtool website) for
More information about the rrd-users