Yesterday Thorsten von Eicken wrote: > Tobias Oetiker wrote: > > Interesting ideas. But I'm a bit confused... First you say > > 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 ... > > > but then you say
the initial motivation for the question was, that the person was wondering why we were saving up the (cpu intensive) part of the work until the last moment while we would have time todo that beforehand. My intial reaction was that CPU was not an issue for us, but then ... > > * 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. > > > I understand the holt-winters issue, but what is the issue around "since the > writing to disk is what is hurting us"? I.e. is the only benefit of caching at > the output stage that holt-winters can be made to work? Furthermore, how would > caching at the output stage differ from the OS disk cache? I'm running > cached's with a 1-hour cache, which is 40% of the first-level RRA, would I see > a 2x improvement in cache capacity? the difference of using cached versus the OS diskcache is, that with cached we can define our own caching behaviour, in linux, writes normally get delayed (cached) for about 5 seconds. With cached we can have anything (1 hour in your case). There is no change in that, regardles whether the caching is done at the input or at the output stage, but as I said, the present solution prevents updatev from working, and this is not ideal. I have been idly thinking about this, but it only became clear to me yesterday, that this is actually fixable ... cheers tobi > Thorsten > > -- 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
