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... Cheers, Thorsten _______________________________________________ rrd-developers mailing list rrd-developers@lists.oetiker.ch https://lists.oetiker.ch/cgi-bin/listinfo/rrd-developers