Hi David
Thank you for the quick response. The logs are from the relay server so it both receive and send, let me try to sketch it: router/server/firewall/etc client -> relay server -> archive server 1 + 2 So the action-2 you highlighted is for logs going to archive server 2, good catch. I can see that one is actually having a bit of a struggle and I have now attempted to fix that. Also good idea about naming the actions, that does indeed make it much easier to read the stats. I'm not quite sure what you mean about "batch size of something on the order of 100-128", could you please elaborate on that? I have read a bit about queues on https://www.rsyslog.com/doc/concepts/queues.html but must say I'm unsure which values to use. I have found an example here: https://rsyslog.readthedocs.io/en/latest/examples/high_performance.html and attempted to replicate that. For now, our servers appear to be running better, but I won't know for sure until tomorrow when the general load is higher. Best regards Jesper Skou Jensen -----Original Message----- From: David Lang <da...@lang.hm> Sent: Tuesday, July 16, 2024 11:49 AM To: Jesper Skou Jensen via rsyslog <rsyslog@lists.adiscon.com> Cc: Jesper Skou Jensen <j...@jysk.com> Subject: Re: [rsyslog] rsyslog stops accepting TCP for a minute or two it's not clear if this config and pstats output is for the sending or receiving system Tue Jul 16 09:23:13 2024: action-2-builtin:omfwd queue: origin=core.queue size=1000 enqueued=248342 full=702 discarded.full=2 discarded.nf=0 maxqsize=1000 This indicates that the queue to deliver messages out from this system filled it's queue 702 times, that would cause processing on this system to receive messages to block (or at least spill over to the disk files for this queue, which are considerably slower) a larger queue size may help ride out short surges in traffic one thing that can speed things up is to set a batch size of something on the order of 100-128, something like that on the sending side. Also, naming the actions makes the pstats output much easier to read you can run top and hit "H" to show threads and see if there is a thread that is using a lot of cpu. Is there a firewall/router/switch that could be dropping packets in the path? tcp timeouts/retries could account for delays David Lang _______________________________________________ rsyslog mailing list https://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.
