[rrd-users] Any users of RRDCache.pm from UW?

Dale W. Carder dwcarder at wisc.edu
Wed Apr 13 15:37:59 CEST 2011


Thus spake Jo Rhett (jrhett at netconsonance.com) on Tue, Apr 12, 2011 at 02:27:23PM -0700:
> From the following page we found some solutions to certain problems we were seeing.  http://net.doit.wisc.edu/~dwcarder/rrdcache/
> 

Hi Jo,

Here are some thoughts:

- My crappy web page more or less evolved into a real paper written by
actual academics which was presented at LISA '07:
http://www.usenix.org/events/lisa07/tech/full_papers/plonka/plonka_html/index.html

- We are now running our (even bigger) MRTG system with (16) solid-state disks 
in a RAID configuration, and needless to say we don't have issues with seek or 
read performance any more.

- Take a look at rrdcached in the 1.4.x branch of code.  I know this doesn't 
help you now, but it is where all of the development effort is going.
While we aren't using this rrdcached yet, we're keeping a close eye on
it as it stabilizes.

- If you could move to a version of rrdtool that at least incorporates the
posix fadvise calls, thay might clear up your issue or go long way towards
resolving it.  This would be version rrdtool-1.2.26 or better.
Presumably you could port that (rather simple) change into the version
that you are running and your OS "does the right thing" with this call.

- As a last resort, you may be able trick your OS to evict pages from the
buffer cache.  See the paper, and this utility:
 http://net.doit.wisc.edu/~plonka/fadvise/

Cheers,
Dale


> This one host is using an older version of RRDtool with little chance for upgrade due to obsolete host OS, so this seemed appealing.  However playing with the module has found it quite immature ... print() statements inside the library, plus a number of fairly obvious bugs due to fixing a specific problem for one application and not for all.
> 
> Issues I've found so far:
> 
> 	1. If the application is short lived, tmp files are never renamed and thus never used.  It only works as implemented for long-running applications.
> 
> 	2. If the application saves data with "N" for the timestamp, all updates are applied with the same timestamp.
> 
> 	3. Not all functions from RRDs.pm implemented
> 
> 	4. print() calls in the library routines
> 
> 	5. error() function commented out
> 
> I'm sure there are more.  Is anyone else using this in the wild?  Want to collaborate on fixes?
> 
> -- 
> Jo Rhett
> Net Consonance : consonant endings by net philanthropy, open source and other randomness
> 



More information about the rrd-users mailing list