[rrd-developers] rfc: later caching

[Tobias Oetiker]

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 tobi at oetiker.ch ++41 62 775 9902 / sb: -9900