[syslog-ng] time_sleep() and inadvertent admission control
Alexander Clouter
ac56 at soas.ac.uk
Mon Jan 28 21:55:32 CET 2008
Hi,
Balazs Scheidler <bazsi at balabit.hu> [20080128 20:52:36 +0100]:
>
> On Mon, 2008-01-28 at 10:26 -0800, Evan Rempel wrote:
> > >
> > > > [snipped]
> > >
> > > Thanks for the detailed analysis (and for the original idea too :), I
> > > think the following solutions exist:
> > >
> > > * do multiple accepts per poll loop; or
> > > * increase the I/O priority for the listeners
> > >
> > > The first one easily increases the incoming connection rate and is
> > > simple to implement, the second is more complex and might cause further
> > > unexpected behaviour:
> > >
> > > if the priority of the listeners is increased, that would mean that any
> > > incoming connection might starve the incoming message stream, e.g. if
> > > there's a continous stream of incoming connections, then long-living
> > > connections might be starved.
> > >
> > > So I'd choose the first option, what do you think?
> >
> > Would it be possible to have an acceptor thread that does not use the
> > time_sleep() and let the I/O reader threads honor this setting? That way
> > there would not be any starvation and there would not be any interaction
> > from time_sleep() and accepting connections.
> >
> > Just throwing this idea out there as I am not aware of the architecture
> > of the code.
>
> The same can be achieved by much simpler changes. I could do a poll() call
> for all listener fds and if that returns nothing in 10msecs, I'd sleep for
> time_sleep()-10msec and then poll for everything, but I'm not sure this is
> worth it. Doing multiple accepts in each poll iteration should be just as
> good.
>
Unsure how portable it is, might only be Linux 2.4+ but looks like BSD and
Solaris might also do this, however the following looks good:
http://www.kegel.com/c10k.html#nb.sigio
Spares you the poll() during idle periods. Instead you use poll() *only*
when you know there is something waiting for you. Of course multiple accepts
needed but then no need to faff with timers.
For those not aware C10k, its a good read.
> Syslog-ng is not multithreaded now (this is something I'm planning to change).
>
Is this to make use of now common SMP setups or to help on IO throughput? If
it's on the latter I think I read somewhere mmap'ing a file between a single
writer (network input, one per input fd) and a pool of writers (disk output,
one per file) would give you shiny performance. Of course this is a
completely different architecture than what syslog-ng gives...syslog-ng-ng
anyone? :)
Cheers
Alex
More information about the syslog-ng
mailing list