Has anyone tried using this yet? The way to do it seems to be to set the environment variable RRDCACHED_ADDRESS to the same value as the -l parameter you used to start rrdcached, before running MRTG.
I've been testing this as part of my performance testing, and it seems a little immature. The cached seems not to support such functions as tune, create, and info; only supporting update. When rrdcached is running on a unix socket, MRTG seems to work and all is fine - I suspect the tune, create and info are done via the normal channels. If you use a TCP address, though, you get lots of errors about 'dummy'. I think this is the RRD functions choking because they cannot stat the RRD file, or create it. There is also an issue that rrdcached rejects absolute paths for RRD files when submitted via TCP which seems to be in conflict with the way MRTG works. Possibly MRTG should be patched to detect rrdcached mode, and in this case skip the various checks like verifying the MaxBytes (and tuning), checking for .log files, and so on. You'd still need to have the rrd files pre-created unless rrdcached can support this in the next version, though. If rrdcached can support create (as well as update) via TCP sockets then it will open up the possibility to have one server running rrdcached and the web frontend, and then a cluster of others running MRTG processes feeding back to the rrdcached, allowing a huge expansion... I'm going to have a bit more of a play with this, but I'd be interested in hearing anyone else's experience with this. Steve ________________________________ Steve Shipway ITS Unix Services Design Lead University of Auckland Floor 2, 58 Symonds Street 09 3737599 ext 86487 P Please consider the environment before printing this e-mail
_______________________________________________ mrtg mailing list [email protected] https://lists.oetiker.ch/cgi-bin/listinfo/mrtg
