On Mon, 25 Nov 2013, Pavel Levshin wrote:
25.11.2013 12:18, David Lang:\
Another possibly interesting message is:
7975.038523942:7fe2064cf700: main Q: doEnqSingleObject: LightDelay mark
reached for light delayable message - blocking a bit.
which was received approximately once per second during following
interval (this is also when the traffic went down to zero):
1385087975 Fri Nov 22 02:39:35 UTC 2013
1385088546 Fri Nov 22 02:49:06 UTC 2013
Does this shed any light on what's going on?
I bet this is the problem. This blocks main queue for a second.
There are possible workarounds, including increasing main queue size (this
watermark is set to 70% by default).
searching through the documentation, this seems to be a tcp input option
old style
$InputTCPFlowControl defaults on set to off to disable
new style
FlowControl='off' on the module load
it still seems wrong that this triggers problems for such a long time.
unless some output is blocking and causing the queue to not drain, it seems
like it shoudl very quicly open up again.
I'm wrong in that it is blocking the whole queue; in reality, it is blocking
only one input. In this case, it is RELP. It is using flow control, there is
no option to disable it.
The question is: why queue length stays above LightDelayMark for a while?
what does pstats show during this timeframe? set the reporting frequency so that
you will get several samples during the problem timeframe.
David Lang
_______________________________________________
rsyslog mailing list
http://lists.adiscon.net/mailman/listinfo/rsyslog
http://www.rsyslog.com/professional-services/
What's up with rsyslog? Follow https://twitter.com/rgerhards
NOTE WELL: This is a PUBLIC mailing list, posts are ARCHIVED by a myriad of
sites beyond our control. PLEASE UNSUBSCRIBE and DO NOT POST if you DON'T LIKE
THAT.
