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