Increasing the time to 20000 usec cuts CPU in half again - to about 1/8 of the original consumption. It's now using ~10-15% of a CPU under the same heavy log load from ~750 connections. Granted, this increases latency, but I don't think 10 or 20 msec delays will kill anything.
The idea is cool, although I have to admit it is really a hack :)
What's wrong/the issue with adding epoll? Besides non-portability? Also 20msec may not hurt on 2.4.x kernels regarding latency however, 2.6.x kernels busy loop with HZ>100. Reducing HZ to something sensible like 100 is better for servers anyway. Could the OP also put his .config online somewhere?
This might be useful to others as well. I will probably add it as a global option. Thanks for tracking this down.
Could you please oprofile syslog-ng with your setup and configuration? Also, if you have some spare cycles to burn, have oprofile annotate your source with the profiler results. I happen to find oprofile a bit better to use for independent task/thread profiling sometimes than pure gprof. YMMV. I don't have time right now, that's why I don't do it. Regards, Roberto Nibali, ratz -- echo '[q]sa[ln0=aln256%Pln256/snlbx]sb3135071790101768542287578439snlbxq' | dc