<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
<html><head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<meta name="generator" content="Osso Notes">
<title></title></head>
<body>
<p>----- Original message -----
<br>> Any suggestions on how I debug this?
<br>>
<br>> I have a tcp and a udp source (defined as separate sources) that share a
<br>> common destination
<br>>
<br>> log { souce(s_udp); source(s_tcp); destination(d_file); };
<br>>
<br>> 90% of the log volume comes from the tcp sources.
<br>> The udp log lines are logged 10 minutes "late". If I decrease the
<br>> so_rcvbuf then I can get this down to 5-10 seconds "late." I can issue
<br>> on a source udp server
<br>>
<br>> logger -t test "this is a test"
<br>>
<br>> and wait on the server. It shows up, but minutes later.
<br>>
<br>> OK, playing a little more, if I add the log_iw_size option on the
<br>> udp source, the symptoms go away. Odd since I do NOT have any flow
<br>> control in any destination.
<br>>
<br>> Can anyone explain why that option would make a difference?
<br>
<br>hmmm,, with 3.3 flow control behaviour was changed a bit because of the multithreaded nature of syslog-ng. file destinations enable a mode I called soft-flow-control.
<br>
<br>In 3.2 and earlier, syslog-ng always prioritized output over input, effectively starving all inputs as long as the outputs were busy flushing data.
<br>
<br>The same behaviour was unfeasible with the multithreaded architecture, so I employed the flow control logic to control the input flow (that was its role after all). However people usually don't have flags(flow-control) in their configuration, removing the architectural guarantee to prioritize output over inputs would cause message loss in cases there were none before.
<br>
<br>Therefore file destinations automatically enable soft-flow-control, which means that as long as there's an active file opened, flow control is in operation. If syslog-ng fails to open a file, or it gets suspended because of a write error (e.g. disk full) flow control is lifted again.
<br>
<br>This way, log-iw-size() does have an effect after all, as long as you have a file destination in the log path.
<br>
<br>The log-iw-size and log-fifo-size defaults were also increased in a number of cases, but maybe not for udp.
<br>
<br>What may be biting you is a small window size and a busy file destination, which takes minutes to flush its buffered data (that must be busy indeed) Try increasing flush-lines for the file destination, it should increase the output bandwidth a lot.
<br>
<br>Probably the so-rcvbuf() only decreased the amount of lost udp frames, the one delayed was probably lost before.
<br>
<br>hope this helps.<br></p>
</body>
</html>