[rrd-users] scaling rrd - file format question

[Ryan Kubica]

Oh, it doesn't 'break' ... it lags back and queues all incoming data until the 
rrds exist.

The entire data model is a store-forward-queue, so all the data is in a queue 
already.  Just that when the datapoint files don't exist yet, they need to be 
created, so the queue will back up while that is occurring.

This is all about how quickly the data can be written out from the queue and how 
latent the data in graphs and exports are due to issues resulting from new 
datapoints being created.

Currently, one host has 913 thousand active datapoints being updated every 
minute with a write rate of ~68k rrd updates per second.  RRD file create rate 
is 70/s.  I can make creates quicker by parallel creating but that will further 
stomp on the disks.

I'm looking for a better solution than consuming 'peak IO' during high create 
periods.  Since all of the data written is reported on every minute through 
aggregation and then alerted on, it's important to try and not have latency 
built into the system during surges.

I'll pick through the rrd code to see if I can manage a rebase option.

Thanks,

-Ryan



Hi Ryan,

Today Ryan Kubica wrote:

>
>
> RRD Developers,
>
> I have the need to pre-create rrd datapoints before they are used; such that
> there are already existing datafiles on the filesystem which are in a free 
pool
> and used when required.
>
> The problem is that without a free pool the system is creating the datapoints 
>on
> demand when newly monitored data is being inserted.  That for the most part is
> okay if the new datapoint count is low thousands.  However the issue arises 
>when
> >50 thousand datapoints are required quickly.   Creating them causes noticable
> latency in storing all new datapoint data.
>
> So the answer seems to be pre-create.
>
> The concern I have is in the past (5 years ago) I tested creating rrd data 
>files
> with an RRA of 1 year of data and the create time set to unix epoch.  When 
>doing
> an update to that file it seemed like the entire rrd was rewritten since none 
>of
> it's 'intervals' were valid for the update time of 'now'.
>
> Does the latest 1.4 version do the same thing?
>
> Or is it essentially a no-cost-difference in IO to update an rrd with a start
> time (and thus round-robin end time) with a time interval in the future of it?
>
> I don't want this feature to have a negative impact on IO in nearly the same
> manner as creating them would be.
>
> I could try and test it, but RRD developers will know for certain what the 
>total
> cost is, which is what I'm most interested in.

there is no smartness about updating 'old' rrd files in rrdtool
today ... if you have to go this route you may want to add a
'rebase' option to rrdtool tune which lets you modify the last
update property in an existing rrd file.

I wonder though if you could not design your system in a way that
it does NOT break when it gets a request for 50'000 rrds by makeing
sure the process who tries to submit information does not have to
way for it to be actually stored back ...

cheers
tobi
>
>
> Thanks,
>
> -Ryan
>
>
>

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



      
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.oetiker.ch/pipermail/rrd-users/attachments/20101022/505562d9/attachment.htm