[rrd-users] RRA/RRD tuning

[Tobias Oetiker]

Friday Christoph Anton Mitterer wrote:

> 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?

fadvise is only an advise, it does not actually cause the data to
be evicted from the kernel caceh (check the your os docs)

> 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?

yes

> And also, the more steps I consolidate over the slower, right?

no ... not realy as the consolidation is done continualy with every
step, once the rra is to be written, the values are already
ship shape.

> 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.

it is smart enoughh ...

>
> 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.

yes


> 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?

yes
>
> 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.

the biggest win for graphing time would be to integrate support for
setting the png compression level into rrdtool ... libcairo sets
this very high, and thus spends considerable time compressing the
resulting png file ... setting the compression level to 1 should
give a considerable performance gain ...

I will be glad to integrate your patch

cheers
tobi
>
> Thanks for your insights,
> Chris.
>

-- 
Tobi Oetiker, OETIKER+PARTNER AG, Aarweg 15 CH-4600 Olten, Switzerland
http://it.oetiker.ch tobi at oetiker.ch ++41 62 775 9902 / sb: -9900