[rrd-users] Updating more than once per second using rrdcached
marthter
marthter at yahoo.ca
Wed Nov 28 21:59:31 CET 2012
On 12-11-28 02:39 PM, Tobias Oetiker wrote:
> On 28.11.2012, at 19:53, Rick Jones <rick.jones2 at hp.com> wrote:
>> On 11/28/2012 10:17 AM, Martin Muc wrote:
>>> I've been googling this for hours... how to use rrdtool to store data, for
>>> example, at 10 samples per second, 100 ms apart. It does not seem possible, is
>>> this correct?
>>>
>>> So, although you say the update timestamp can have millisecond precision, there
>>> still cannot be more that one update per second, is this correct?
>> At the risk of typing into Tobi's keyboard, the sub-second updates can
>> be done with "direct" rrdtool but not while going through an rrdcached.
>>
>> I make use of the sub-second updates in a couple of my netperf scripts -
>> which do not use rrdcached.
>> http://www.netperf.org/svn/netperf2/trunk/doc/examples/
> there is a fix for that problem already in the repository (not sure if in 1.4 or only in master)
>
> cheers
> tobi
Yeah, sorry, I sort of highjacked an rrdcached question for an rrdtool
question. And thanks for the prompt replies.
I've got the package-managed version of rrdtool as it is in Ubuntu 11.04:
$ rrdtool --version
RRDtool 1.4.3 Copyright 1997-2009 by Tobias Oetiker <tobi at oetiker.ch>
I'm not sure if the sub-second updates you describe is enough to make it
usable for 10 samples per second. Trying to set --step to 0.1 does not
work:
$ rrdtool create test01.rrd --start 1339355820 --step 0.1
DS:altitude:GAUGE:1:-500.0:10000.0 RRA:MIN:0:1:36000
ERROR: step size should be no less than one second
With --step 1, I do not understand how the resulting numbers are derived:
$ rrdtool create test01.rrd --start 1339355820 --step 1
DS:altitude:GAUGE:1:-500.0:10000.0 RRA:MIN:0:1:36000
$ rrdtool updatev test01.rrd 1339355821.0:9 1339355821.1:9
1339355821.2:10 1339355821.3:11 1339355821.4:7 1339355821.5:10
1339355821.6:9 1339355821.7:11 1339355821.8:9 1339355821.9:9
1339355822.0:8 1339355822.1:9 1339355822.2:11 1339355822.3:11
1339355822.4:12 1339355822.5:10 1339355822.6:9 1339355822.7:9
1339355822.8:10 1339355822.9:11
return_value = 0
[1339355821]RRA[MIN][1]DS[altitude] = 9.0000000000e+00
[1339355822]RRA[MIN][1]DS[altitude] = 9.5000010000e+00
9 is not the MIN over the first second as expected (should be 7), and
9.5 is not the MIN over the second second, so clearly I must be
understanding something incorrectly.
I also tried with the first RRA's consolidation function steps of 10,
thinking maybe it could consolidate 10 samples in each PDP, even if
they're not retrievable or graphable individually:
$ rrdtool create test01.rrd --start 1339355820 --step 1
DS:altitude:GAUGE:1:-500.0:10000.0 RRA:MIN:0:10:36000
$ rrdtool updatev test01.rrd 1339355821.0:9 1339355821.1:9
1339355821.2:10 1339355821.3:11 1339355821.4:7 1339355821.5:10
1339355821.6:9 1339355821.7:11 1339355821.8:9 1339355821.9:9
1339355822.0:8 1339355822.1:9 1339355822.2:11 1339355822.3:11
1339355822.4:12 1339355822.5:10 1339355822.6:9 1339355822.7:9
1339355822.8:10 1339355822.9:11
return_value = 0
This does not give any verbose output, which based on the man page's
description of updatev, suggests that no primary data points (PDPs) nor
consolidated data points (CDPs) were stored.
If there is any way that anyone can clarify or point me in the right
direction for using rrdtool for 10 samples per second data, it will be
appreciated.
Thanks.
Martin
More information about the rrd-users
mailing list