[rrd-users] RRA/RRD tuning

[Christoph Anton Mitterer]

Hi.

I was wondering how to best tune the following, especially with respect
to a) update speed and b) graphing speed.

The background is PNP4Nagios with always 1 data source per RRD...

a) I looked through http://oss.oetiker.ch/rrdtool-trac/wiki/TuningRRD
but all that seems to be simply an in-code thingy.... nothing that the
user would tune manually by how he sets up the RRD.
btw: That document tells it would use fadvise to tell the kernel to only
cache relevant stuff but not the actual data ... however... I get
considerable fast graphing once the RRD has been read (and I guess so:)
and cached.
Does that mean there seem to be some problem with the use of fadvise?


So what remains is tuning by how I set up the RRAs

b) with respect to update
As far as I understand, less RRAs should mean faster updates, right?
And also, the more steps I consolidate over the slower, right?

If so, is that just some "in theory: yes"... or of real practical
influence.


c) with respect to grap
I want to have rather long detailed data, say 1 year of data in 1 minute
steps....
And then say.. 5 years of data in... whatever... 1 hour steps.

Okay, the files get obviously quite big, but disk space is usually the
least of a problem (of course this could have drawbacks with the caching
again... you thing they'd be serious?).


Now does it make sense (with respect to graphing - I guess with respect
to update it should be negative in any way) to add another RRA, that is
of the same (or shorter) length as my detailed one (the one over 1 year)
but less detailed,... say only 1 day steps.

Of course,.. update time would increase... but I could imagine that it
should at least be technically possible that rrdgraph could be smart
enough to decide based upon --start, --end and --width whether it needs
the highly detailed RRA (1 year, 1 second steps) or whether the less
detailed (1 year, 1 day steps) would be enough.


So for example... if I graph with a width of 356 (+ size of borders)
points (thus: 1 year)... it would be clear,.. that the less detailed RRA
is already enough... there wouldn't be a need for rrdtool to read over
the much larger and more detailed 1st RRA,... just to calculate/scale
everything together again.


I made a few tests (though on a production node, therefore not lab like
conditions) and it seems that it just works like that.

True or myth?


Any other ideas on how to tune update/graph time?


Am I doing wrong, when I also focus on graph time (with the ideas from
(c) above... at the cost of update time)? I mean... one could always do
the graphing just on another node... but splitting the updating of
thousands of RRDs on different nodes is (while surely possibly) quite
unhandy IMHO.


Thanks for your insights,
Chris.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5450 bytes
Desc: not available
Url : http://lists.oetiker.ch/pipermail/rrd-users/attachments/20120810/75f564c7/attachment.bin