Because of all the other changes going into the 3.0 release and that the rrdcached being brand-new when we started our release cycle, we decided to hold off on this upgrade for the 3.0 release.  We will most definitely investigate it for the next release, since it should greatly improve RRD performance.

What have you found with using it?  Do you have patches for this you'd like to submit?  Like I said, it's definitely something we'll investigate for the next release.

Thanks,

Matt Ray

Zenoss Community Manager

I share an office with the Product Manager, so I've been bugging him about it.  I could have sworn there was an enhancement around it somewhere, but it's definitely on our radar.

-Matt

Unfortunately that call to fetch isn't entirely spurious. For COUNTER and DERIVE data points it is required to properly evaluate any thresholds that may be applied to them. We're relying on RRDtool to calculate the rate for us so that we're thresholding on the rate instead of the raw value.

To properly use rrdcached we'll need to have Zenoss itself remember the last value retrieved for each COUNTER and DERIVE data point so that can can calculate the rate internally without fetching it from the RRD file.

Next week was an overestimate; it's in trunk now.

http://dev.zenoss.com/trac/changeset/21852

Pretty similar to Massimo's patches, except:

1. There's a wrapper script (zenrrdcached) that'll bring rrdcached up and down with zenoss
2. If the daemon isn't up it'll fall back to writing directly to the rrd files
3. Journaling is used by default
4. Socket lives under $ZENHOME/var instead of /var

You can pass more options to zenrrdcached and they'll be sent along to rrdcached, so if you want to change the flushing or the timeout or whatever you can.