On Thu, Sep 19, 2013 at 6:34 PM, David Lang <[email protected]> wrote: > On Thu, 19 Sep 2013, Rainer Gerhards wrote: > > On Thu, Sep 19, 2013 at 6:13 PM, David Lang <[email protected]> wrote: >> >> looking at your stats here >>> >> ...
> enqueued=89947026 full=0 discarded.full=0 discarded.nf=0 maxqsize=11365 >>> >>> >> That's the most important counter for this context. It tells us the main >> queue never got anything really queued up (it never had more then 11,365 >> messages, which is "nothing" in a high performance environment). >> >> >> >>> These don't look bad to me. >>> >>> note that you only have an action queue for one of your actions >>> (action2), >>> all the rest of your actions are being handled by the main thread. I >>> don't >>> think this is what you intended (unless there really is something special >>> about your 'pdc' logs) >>> >>> >>> Given the main queue stats, I'd say that running any file logging >> process >> on a dedicated queue just wastes CPU cycles and does no good. >> >> This is why I came to the conclusion that the only potential bottleneck I >> see is how fast imudp can pull out messages from the OS receive buffers. >> In >> my experience, failure here does not even manifest in increased CPU use by >> the imudp thread. >> > > I know you said that you don't think it's DNS lookups, but am I correct in > thinking that if it is a problem with DNS lookups you would have the same > symptoms? the imudp thread would not be eating CPU as it's blocked waiting > for the response from the DNS server. > yes, BUT: the DNS lookup is done on the main message queue thread. imudp never does it. It just sets a flag that it hasn't done it. Actually, the resolution later in processing only occurs if a property is accessed that needs it. Early version of rsyslog (v5 and below?) did do it on the imudp thread, but that's long gone away. > I wonder if there's a way to run more than one imudp thread on the port. > the inbound packets would not be evenly split between them, but if one is > stalled, the other may be able to pull a packet. > That would require redesign and I am rather skeptic about it. The reason is that imudp runs in a very thight loop that essentially does pull messages off the receive buffers and puts them into the queue. No real waits involved here. But of course multiple threads may have the result of getting more / or quicker CPU power assigned. However, for that use case I think realtime priority is a much better solution. I would even expect that two imudp threads would contend each other for the main queue thread, as it is a really thight loop... BUT - it's my estimate, not tested reality. To test it, I would probably need two to three days and I don't think they were wisely spent at this moment. Rainer _______________________________________________ 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.
