On Mon, 2011-05-02 at 19:04 +0100, Simon Hobson wrote: > Joshua Keroes wrote: > > >Is our theory correct, that the RRD consolidations may be causing > >these long runtimes > > It would be logical that each time a "bucket" is completed, then > additional processing will happen in order to do the necessary > normalisation and consolidation. > > >, and if that's the case, is there a way to evenly > >stagger the consolidations over time so we can better distribute RRD > >update load? > > You cannot offset the consolidation times as everything is referenced > to unix epoch (Midnight 1st Jan 1970). However, if it is just system > load you are concerned about, can you delay feeding in some update > values a bit ? As long as you use an explicit timestamp in the update > statement, then it doesn't matter what actual clock time the update > is submitted to rrd - as long as you maintain the right sequence of > updates.
At the risk of typing into Joshua's keyboard I suspect he wasn't asking to shift the times to which the RRAs are aligned, but spread the work done for those RRAs - the hypothesis being that for an RRA which aggregates N samples it not do all the work after N samples but try to do 1/Nth the work upon the presentation of each sample. If indeed it is waiting to have N samples and then does the work en mass then all delaying updates would do is shift the spikes rather than smooth them out right? rick jones _______________________________________________ rrd-users mailing list rrd-users@lists.oetiker.ch https://lists.oetiker.ch/cgi-bin/listinfo/rrd-users
