Robert, please try the following configuration
module(load="imuxsock") # needs to be done just once Roberto 8-9-13
module(load="imklog")
module(load="impstats"
interval="10"
log.syslog="off"
log.file="/var/log/pstats")
# Provides UDP syslog reception
module(load="imudp"
batchSize="1000"
TimeRequery="10"
SchedulingPolicy="fifo"
SchedulingPriority="10")
input(type="imudp" port="514" )
#### GLOBAL DIRECTIVES ####
# Use imprecise-old-style timestamp format
$ActionFileDefaultTemplate RSYSLOG_TraditionalFileFormat
$MainMsgQueueType FixedArray
$MainMsgQueueSize 20000000
$MainMsgQueueWorkerThreads 1
$MainMsgQueueDequeueBatchSize 1000
$InputUDPMaxSessions 40000000
#### RULES ####
action (type="omfile"
File="/dev/null)
On Thu, 10 Oct 2013, Rainer Gerhards wrote:
Date: Thu, 10 Oct 2013 18:45:17 +0200
From: Rainer Gerhards <[email protected]>
To: Robert <[email protected]>
Cc: David Lang <[email protected]>, rsyslog-users <[email protected]>,
rmkml <[email protected]>
Subject: Re: [rsyslog] Tr : Re: perfomance tweaking (fwd)
On Thu, Oct 10, 2013 at 6:40 PM, Robert <[email protected]> wrote:
Attached are the results to /dev/null, 10 second interval for imstats,
with zip and async removed.
OK ... I finally give up, it's a waste of time. I thought that was just the
plain config writing to /dev/null w/o any bells and whistles. This,
together with the messy thread makes me strongly belive we'll go nowhere
that permits us to draw any conclusions. Should you come up with a stable
situation that tell where a bottleneck may be, I am happy to join this
thread again, but until then I can't spent the time. I also doubt we'll
ever arrive there..
Rainer
top was better the worker threads stayed around ~35% each, imudp thread
was high at ~95%.
----- Original Message -----
From: David Lang
Sent: 10/10/13 12:14 PM
To: Robert
Subject: Re: [rsyslog] Tr : Re: perfomance tweaking (fwd)
by the way, the following command line may help you see what's happeing (with
relative stats)
grep imudp pstats |grep -v "=0"
grep imudp pstats |grep -v "=0"
Also, when we are writing out to /dev/null, let's make a run with ziplevel and
asyncwrite removed (since they only benefit us by saving I/O and moving it to a
different thread)
David Lang
On Thu, 10 Oct 2013, Robert wrote:
Date: Thu, 10 Oct 2013 09:46:38 -0400
From: Robert <[email protected]>
To: Rainer Gerhards <[email protected]>
Cc: David Lang <[email protected]>, rsyslog-users <[email protected]>,
rmkml <[email protected]>
Subject: Re: [rsyslog] Tr : Re: perfomance tweaking (fwd)
These are the results with 1000 for both timeREquery and batchsize, writing out
to /dev/null
----- Original Message -----
From: Rainer Gerhards
Sent: 10/10/13 08:48 AM
To: Robert
Subject: Re: [rsyslog] Tr : Re: perfomance tweaking (fwd)
umm.. again the ML thread is broken :-(
On Thu, Oct 10, 2013 at 2:43 PM, Robert < [email protected] > wrote:From the
documentation does that mean that I should lessen my timeRequery and batchSize? to
something lower ?
A relatively large batch size is a good thing. I would be conservative with
timeRequery in a large batch environment. As I wrote in the doc, I'd recommend
not to go higer than 10.
Rainer
Robert.
Robert.
Robert.
_______________________________________________
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.
