[collectd] collectd versus rrdcollect-remote rrdtool [network] IO
greg at easyflirt.com
Tue Jan 20 10:26:19 CET 2009
> I'm confident, that once a value has made it into the system, it will
> get written to an RRD file. I have seen collectd in some high-IO
> situations and this has never occurred. So values aren't ``lost'' inside
Yes, data are cached manytimes, and will be lost only after a crash...
> That doesn't mean that high-IO situations don't come with potential
> problems. As I've writte in , I have encountered two problem so far:
> 1) Overflow of the (UDP) receive-buffer.
> 2) Corrupted RRD file caused collectd to quit ungracefully.
> If you have gaps in all graphs but the ones the server collects about
> itself, the first point is the most likely. I've done the changes I was
> talking about in , you can get the code by checking out the Git
> repository or use Sebastian's snapshots. If you see collectdmon
> restarting collectd frequently, the second case is very likely.
I'm using official (backported) Debian package, and don't want to make
mine today. I will do it for version 3.5, for "Plugin" options in perl
> The guess that collectd isn't ``tuned for IO perf'' is next to a
> personal insult. Please read  which explains all the troubles
Sorry, mispelled ? I would say that "my" collectd (my configuration of
collectd) is not enough tuned for IO performance.
But, after reading your post, seems that I was incriminate disk IO too
> put into the files). It appears you have both tools running on the same
> machine at the same time, so my guess is that rrdcollect is killing the
> machine and collectd is not scheduled often enough, leading to the UDP
> receive-buffer issue. Try increasing the receive-buffer and restarting
I'm agree with this theory. I've increased those values, but it didn't
epoc-02:~# sysctl -a | grep core.rmem
net.core.rmem_default = 4194304
net.core.rmem_max = 8388608
More information about the collectd