i managed to solve this. i don't know why, exactly, but only loading
snmp, syslog, and write_graphite plugins was the culprit. one of the
following has stopped the closed_wait situation, even though i am not
using any of them.
+LoadPlugin syslog
+LoadPlugin cpu
+LoadPlugin interface
+LoadPlugin lo
one option to reduce data loss on udp is to ensure you get multiple samples per
time slice. sure you may get an average from 2 instead of 3 but it won't be a
gap/loss
I've been using multicast udp ( not to graphite ) and have taken this approach.
so far it has been working pretty well. we are r
This is similar, but not quite the same behaviour as the bug I've got open,
also with write_graphite and TCP behaviour. Mine is that write_graphite doesn't
recover if the graphite carbon-cache is restarted.
(https://github.com/collectd/collectd/issues/430).
I know this isn't the answer, but swi
heya. i've compiled 5.4 for linux (centos) at commit 0a161fcfd, and
seem to be having a problem that does not exist at 5.1.
my collectd is pretty barebones, just doing snmp polling against
network devices every 60s. when first starting it up, i get an
established TCP connection to my graphite coll
