On Sun, 12 May 2013, Axel Rau wrote:
Am 09.05.2013 um 21:36 schrieb Axel Rau <[email protected]>:
Am 09.05.2013 um 18:34 schrieb David Lang <[email protected]>:
no, you don't need to do a debug build, but you may need to start it with -n as
well as -d so that it doesn't detach from the tty
Ah, that was useful. Now I'm getting the event trace (available on request).
Looks not so bad?
But
6621.088012506:802007400: tcpSend returns 16
seems to show the tcp backlog at the client side.
Will trace the client tomorrow.
Some of David's hints helped me to solve the issue.
To make a long story short, database INSERTS worked only in debug mode,
because I had not enough test events, to hit the default of
$ActionQueueWorkerThreadMinumumMessages (100). It seems that debug mode lowers
this value.
One last question:
How can I configure to commit my transaction after, say, 2 seconds after start
of transaction, even if I have not reached the limit configured with
$ActionQueueWorkerThreadMinumumMessages?
hmm, this sounds like a bug in the postgres module (which was contributed). Due
to the way rsyslog handles batches of messages, this should not be needed. I
don't believe there is any way to set a timeout. I would suggest setting the
value very low and then see how it scales.
I also cannot find where in the code it uses this parameter (doing a grep -i
minimum on the entire code base only finds documentation and comments), which is
an indication that I'm missing something.
The way message batching is supposed to work is that the worker thread (the
postgres module) grabs as many messages as are available (up to it's configured
max) and processes them as a single transaction.
If there's only one, it grabs and inserts the one message as it's own
transaction.
Since inserts of single messages in a database are horribly inefficient
(compared to inserting multiple messages in one transaction), as the volume of
messages climbs, multiple messages will arrive while the worker thread is
inserting the one message, and so the next pass it will insert multiple
messages.
This approach results in the database being kept busy continuously, with a
varying number of messages per transaction, but it makes the latency for new
messages getting to the database be as small as possible (and it eliminates the
exact symptom that you ran into here)
The naive approach to doing batches is to define a batch size (in this case
100) and insert nothing until that many messages arrive. This is a bit more
efficient on the database, but at the cost of delaying messages (and if the
system were to crash, loosing more messages as they are waiting for the batch
size to fill). Implementing timeouts is a hack to try and make this less bad
when the message rate is low.
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.
