On Wed, 17 Feb 2016, Damiano Verzulli wrote:
There are a log of possible things going on here, it's not going to
be
possible to guess which are the cause until we see the config.
I already posted it in response to Rainer's request
I must have missed it. Please post again.
Here is the message the OP was referring, directly from the ML archives:
http://lists.adiscon.net/pipermail/rsyslog/2016-February/042046.html
In the middle, it reports several config infos.
Ok, this config is using imjournal, which is what systemd recommends, but not
what rsyslog recommends. Part of the reason why we don't recommend this approach
is that this means that all logs go first into the systemd journal, and then a
polling process (the imjournal process) has to query systemd asking if there are
any new messages, and if so, then ask for the new messages. This process is
inherenly a problem for someone looking for low latency like the OP is.
This module is documented at
http://www.rsyslog.com/doc/v8-stable/configuration/modules/imjournal.html and in
that documentation, I don't see anything that lets you adjust it to poll more
aggressively.
RedHat has opted for this as their default, argue with them over it (please, we
disagree with their choice :-)
There is a different approach that you can take that will set the systemd
journal to forward the logs to rsyslog (note that this still suffers a
performance hit from the trip through the journal) that's fairly well documented
in the systemd documentation.
And I'm told that there is a way to tell systemd to not have the journal listen
to /dev/log at all, which would allow rsyslog to operate as it traditionally
has. But I don't know how to find this option to point you at any documentation
for it.
Now, it is possible that I am wrong, and the problem isn't the trip through the
journal, but we know that doing so is going to add delays. Try configuing
imuxsock on some other port and configure something to log to it and see what
delay you get there.
Also note that the queue you have setup only affects traffic destined to the
172.31 destination, traffic to the 192.168 destination does not have an action
queue, so any backups or delays on that connection will delay all messages,
including ones written locally. This is one of the places where the new style
config makes it much clearer that the queue only applies to the one action.
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.
