[rrd-developers] rrdcached + collectd issues

Thorsten von Eicken tve at voneicken.com
Sat Oct 10 03:13:28 CEST 2009

kevin brintnall wrote:
>> Yes, the question is whether it's collectd's fault or rrdcached's fault..
> The protocol is such that the client should wait for the server response
> to continue...  there is no notion of "pipelined" operation, except BATCH
> mode.

What I mean is that as you state, the two are "locked together", so if 
one slows down, the other slows equally. Since rrdcached sits at 100% 
cpu I suspect it's the one determining the rate of processing inputs.

>> That's in-place modification as far as I can tell. In fact, in most 
>> cases (no \ escape chars) it actually reads and writes the same byte in 
>> the above assignment, so it doesn't actually copy anything.
> Yes, it looks like you're right.. it does indeed modify in-place.  In that
> case, it should be relatively easy to optimize..  let me think on it.

I found an explanation for the gprof oddity: multithreading. gprof 
doesn't deal with that out of the box. See 
<http://sam.zoy.org/writings/programming/gprof.html> for one write-up. 
I'm now trying the fix suggested on that page. Let's locate the issue 
before optimizing...


More information about the rrd-developers mailing list