[collectd] collectd versus rrdcollect-remote rrdtool [network] IO

[Greg]

Florian,

> 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
> collectd.
>   

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 [0], 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 [0], 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 
plugin.

> The guess that collectd isn't ``tuned for IO perf'' is next to a
> personal insult. Please read [1] 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 
quickly !

> 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
> collectd:
>   

I'm agree with this theory. I've increased those values, but it didn't 
help :

epoc-02:~# sysctl -a | grep core.rmem
net.core.rmem_default = 4194304
net.core.rmem_max = 8388608

-- 
Greg