[syslog-ng]losing messages using syslog-ng-1.4.7 & libol-0.2.20

[Balazs Scheidler]

> You're almost certainly overflowing the internal queue in either the
> server or the clients or both.  Try logging the messages on the clients to
> a file as well as the network, and see if the local syslog-ngs are
> dropping messages before the server has any chance.
> 
> You can put some printf statements into the libol code to trace what is
> happening with each log entry and the output queue.  I did this to mine
> and I can see in the output that syslog-ng sometimes (often) simply throws
> messages away.  The interesting parts are in pkt_buffer.c and queue.c in
> libol:
> 
>         if (self->queue_size == self->queue_max) {
>                 /* fifo full */           <== oops
>                 ol_string_free(string);   <== this tosses your message
>                 return ST_FAIL | ST_OK;   <== return code is ignored
>         }
> 
> I've raised this issue on this list before, but have been ignored.  

I wouldn't say you have been ignored. I once explained why your arguments
were false.

here's the URL:

http://lists.balabit.hu/pipermail/syslog-ng/2000-October/000890.html

carefully sizing the output fifo size will not drop you fetched messages.

The shortest message can be 4 bytes, so the 1024 byte input buffer (contrary
to what I said in the message above, it's not 2048), you can have at most
256 lines in a single packet.

Have the number of sources and multiply it by 256, and the fifo you get will
hold all input data.

> Regardless of how high your fifo size is, syslog-ng will lose messages if
> the sources generate messages faster than the destintation can consume
> them.  Raising the fifo size only masks transients, but does not help in
> the steady state.

if the fifo is large enough to hold all messages in a single poll() run, TCP
will flow-control the input stream.


-- 
Bazsi
PGP info: KeyID 9AF8D0A9 Fingerprint CD27 CFB0 802C 0944 9CFD 804E C82C 8EB1
     url: http://www.balabit.hu/pgpkey.txt