disclaimer: this is about 1.5 not 1.4 ! Yesterday I was giving an rrdtool talk at goOpen 2009 a question in the talk lead to a discussion about the design of the caching model. The question was, why we were caching at the 'input' stage and not at the output stage, since the writing to disk is what is hurting us ...
What came out of the discussion is this: * the current rrdcached is sitting quite close to the beginning of the rrd data path. * the advantage of this is, that it is quite simple to hook it up there. * the (big) disadvantage is that updatev does not work anymore, and for larger deployments updatev is a cornerstone function in driving holt winters based alerting. * moving the cached to a place right before the updates get written into the rrd file would solve this problem. * it would require the cached to read the header information of the rrdfiles once and cache them internally so that it can calculate the updates without accessing the disk, but since header information is quite small, a decent sized machine could easily keep hundreds of thousands of headers in the cache daemon. comments ? cheers tobi -- Tobi Oetiker, OETIKER+PARTNER AG, Aarweg 15 CH-4600 Olten, Switzerland http://it.oetiker.ch [email protected] ++41 62 775 9902 / sb: -9900 _______________________________________________ rrd-developers mailing list [email protected] https://lists.oetiker.ch/cgi-bin/listinfo/rrd-developers
