I am off to another meeting, so just some quick thoughts... (inline below) 2016-02-17 8:43 GMT+01:00 David Lang <[email protected]>:
> 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. > I think that is not really the problem here, because imjournal does a poll() system call and no sleep, so in theory it should get awaken very quickly (I just checked the *current* code, not sure for older ones). > > 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. > > ... and the ommysql is also not using an async queue. I would bet that MySQL induces the delay. More later, Rainer > 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. > _______________________________________________ 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.
