On Thu, 4 Nov 2010, Marc Schiffbauer wrote:
I am not sure on the exact semantics of the 4.6.4 engine, but in any
case you
need to limit concurrency (and thus speed) as much as possible. If you
really
need sequence, that means you need to run it on a single thread (with
a
direct mode main queue). The defaults look like they "preserve
sequence", and
you will see the inevitable out of sequence only when heavy traffic
occurs.
However, any approach to trying to "preserve sequence" will not work
if
looked at closely enough, so there is nothing that can be preseverd.
Details
are in my Linux Kongress paper:
http://blog.gerhards.net/2010/10/linux-kongress-2010-rsyslog-paper.html
Thanks Rainer. Interesting. I read chapter 7 about concurrency optimization.
What I am looking for is indeed what is described there: preserved timestamp
order. And this only with some restrictions:
* in time windows within few seconds or so
because those message will be processed with the need of chronological order.
why is it so critical to process them in chronological order? are you
absolutly sure that the messages will not be able to get re-ordered over
the network (for example, UDP syslog messages could pass each other on the
network)
David Lang
* only per system
Of course there might be corner cases where this will not always work but this
will then be only due to a system outage or something like that.
I am now going to try 5.6.0 with omruleset. I hope it will work
then.
Are there any config options to control or affect timestamp ordering?
In my case I guess it would be sufficient if only one thread would feed the
database.
TIA
-Marc
_______________________________________________
rsyslog mailing list
http://lists.adiscon.net/mailman/listinfo/rsyslog
http://www.rsyslog.com
_______________________________________________
rsyslog mailing list
http://lists.adiscon.net/mailman/listinfo/rsyslog
http://www.rsyslog.com
