Closed GoogleCodeExporter closed 9 years ago
An overflowed (roll-over) COUNTER ds shouldn't spike at all. Read rrdcreate(1)
man
page about overflow handling.
Is it really happening on COUNTER datasources?
Original comment by fri...@gmail.com
on 13 Nov 2008 at 4:14
Let's take the MySQL network stats graph. "rrdtool dump" mentions two COUNTER
DS.
I still got a spike when I restarted MySQL (following a configuration change).
"man rddcreate" mentions "When the counter over‐flows, RRDtool checks if the
overflow
happened at the 32bit or 64bit border and acts accordingly by adding an
appropriate
value to the result.".
It's worth noting that the reset doesn't happen on 32/64bit border - it just
happens
when MySQL restarts. This could explain the spikes.
Original comment by sylvain....@gmail.com
on 26 Jan 2009 at 10:40
If you compare Cacti's bundled "Interface traffic" traffic and
mysql-cacti-template's
"MySQL network traffic", you'll see that the maximum values aren't the same:
1.0000000000e+07 vs. 1.8446744074e+17, the last one being above the 32bit limit
(where does it come from?). It would probably help to use sane max values in the
different graphs.
Alternatively,
https://lists.oetiker.ch/pipermail/rrd-users/2006-May/011188.html
suggests using DERIVE with a minimum value of 0 - not sure about this though.
Original comment by sylvain....@gmail.com
on 30 Jan 2009 at 3:43
It is a sane max value. MySQL's counters are 64-bit (on 64-bit platforms;
there is
an option to generate 32-bit templates) and are not the same as the OS network
counters. I'll have to look into DERIVE with 0.
Original comment by baron.schwartz
on 30 Jan 2009 at 7:18
> [1.8446744074e+17] is a sane max value
Hmmm, do you often get 184 PetaB/s traffic peaks? ;)
Original comment by sylvain....@gmail.com
on 3 Feb 2009 at 9:08
You don't understand max value. It's max value total, not per second. It's
the max
incoming value allowed from the data input.
Original comment by baron.schwartz
on 3 Feb 2009 at 1:07
Dunno, just reading rrdcreate(1):
"Note that min and max always refer to the processed values of the DS. For a
traffic-COUNTER type DS this would be the maximum and minimum data-rate
expected from
the device."
Original comment by sylvain....@gmail.com
on 6 Feb 2009 at 5:58
Sorry for the long delay on this... I just haven't had much time to work on all
this.
I think you are right and I am wrong :)
Original comment by baron.schwartz
on 7 May 2009 at 1:48
No sure if it helps, but when I restart MySQL, most graphs report values show
14.3M.
I am pretty sure I am not performing 14.3M selects, 14.3M Insert, 14.3M Update,
14.3M
Deletes etc all at the same time.
Original comment by pas...@gmail.com
on 11 Jun 2009 at 8:38
The COUNTER data source understands a "reset counter" to be a rollover, no
matter
what your intent was. Thus, if the maximum of the DS is defined as 2^64 - 1
(as is
normal for a 64-bit counter), you're going to see a spike when you restart your
mysql
daemon, as the counters are reset.
The solution is to use a data source of type DERIVE. A rollover is going to
cause a
NaN (or a U) to be inserted into the DS. The only risk in using a DERIVE DS is
if
you should ever happen to go over 2^64, as you will have a gap in your graph.
Original comment by thomas.s...@gmail.com
on 7 Jul 2009 at 3:17
I tested DERIVE instead of COUNTER, and it works fine. I will update the
templates
and release a new version when I have time.
Original comment by baron.schwartz
on 19 Nov 2009 at 4:52
This is committed in r336.
Original comment by baron.schwartz
on 13 Dec 2009 at 5:04
Original issue reported on code.google.com by
baron.schwartz
on 8 Nov 2008 at 4:40