[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
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
More information about the rrd-developers