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?
--
Pavel Levshin
_______________________________________________
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.
