On Tue, 2006-03-07 at 22:45 +0100, Vincent Haverlant wrote:
Le Tue Mar 7 09:34:23 2006, Cary, Kim a écrit:
basically: increasing udp_max_buf without increasing udp_recv_hiwat has no meaning. Furthermore, you can increase you socket buffer that way up to 64k (Solaris 8 & 9), if you want to increase it further up you must use the setsockopt call (up to udp_max_buf which has a maximum value of 1GB). Here is the official SUN documentation regarding this: http://docs.sun.com/app/docs/doc/817-0404/6mg74vsb5?a=view#gbtag
I've increased the priority of the SO_RCVBUF option in my mind and probably add a patch soon.
Now regarding your packet loss issue. I would increase udp_recv_hiwat -> 65536 udp_max_buf -> 1073741824 (you will never get here anyway)
Then I would try to play with syslog-ng config: log_fifo_size, log_iw_size and log_fetch_limit. But here I'd appreciate a syslog-ng expert to step in and tell us what to do more preceisely.
It also depends on which syslog-ng version you are using. 1.9.x is a complete replacement and has a different queueing model than 1.6.x so tuning is also different. You can read a short chapter in the documentation for 1.6.x http://www.balabit.com/products/syslog-ng/reference-1.6/syslog-ng.html/index... This is however not completely updated for 1.9.x yet. The followings are the most important differences: * there is no garbage collector, their parameters are ignored * syslog-ng supports message flow-control, e.g. messages will not be read if they cannot be sent (this requires flow controlled channels like TCP on both receiving/sending sides); this makes the application slow down instead of losing messages If you are not using flow control, the recipe is the same: * make sure your input socket buffer _AND_ your output queue size (log_fifo_size) is able to hold your potential message bursts -- Bazsi