The input to server1 has be relatively consistent, save the few spikes around the time the server2 starting exhibiting abnormal highs and lows. under normal conditions it typical has a consistent deviation of 5-10k (so in the evening/early morning it is anywhere between 15k and 25k, while during the day its between 25 and 35/40k). Even during the incident server1 was only receiving around 30k.
Something happens (assumed to be a spike) causes the receiver to throttle or deny input resulting in the sender queuing. The more the sender queues the more it tries to send when the retriever allows it resulting in high spikes of 1 million events and lows of 5k periodically. In todays case restarting the receiver corrected the issue resulting in more consistent input on the receiver from the sender and the sender quickly dequeing. singh.janmejay wrote > Has it just ramped-down on load Right now server1 is setup to rebind ever 250000 events; should roughly be every 5 seconds at 50k. If anything it might not be frequent enough. singh.janmejay wrote > are you cycling connections too frequently? Only the receiver was restarted. Though in the past we have also tried restart the sender. Sometimes that works do .... though not always. restarting both will always work. singh.janmejay wrote > Or was sender restarted recently? ----- ~Regards Matthew Gaetano -- View this message in context: http://rsyslog-users.1305293.n2.nabble.com/Disabling-IMPTCP-FlowControl-tp7591485p7591492.html Sent from the rsyslog-users mailing list archive at Nabble.com. _______________________________________________ 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.
