On Thu, 26 Sep 2013, Rainer Gerhards wrote:
On Thu, Sep 26, 2013 at 12:31 AM, David Lang <[email protected]> wrote:
am I correct in thinking that this isn't going to help if each action is
in it's own queue?
Depends on the action, but in this case it hurts. Action queues only make
sense for really slow actions. Where "slow" means things like databases or
even remote hosts that may be offline for a while. In this setup, I'd
expect that the action queue has nothing to do at all - even the filters
are evaluated by the main queue threads (because that needs to happen
before the action is called). As I said, I think the filters are the
culprit here (and still do so).
Keep in mind that action queues have an overhead:
- need to duplicate the messsage (to guard against modification by other
actions downstream)
- keep real queue structures
- overhead of mutex operations
I would assume that the overhead here is much higher than the processing
cost for omfile. So I conclude that action queues slow down things.
Ok, I understand what you are saying, but he is getting much better performance
with a small number of main queues and action queues per action than he was
getting with no action queues and more main queue threads.
The reason I was looking at trying to use rulesets was to be able to split the
test overhead between different threads (and have a queue per ruleset rather
than per action)
what is the best way to do this?
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.
