> OK, so there's a way for the administrator to tune this. I note the
> default on my system is 1024, which should be fine for most
> applications. However, for a busy WWW server, how deep should the
> queue be? Anyone got a benchmark?
sort of.
This weekend I took sct's patches that make sockets pass POLL_ events
along with real time sigio signal siginfo structs.. after some fiddling it
works great. So I cooked up a quick static web server that uses sigio
events to feed a ring buffer of fds that have work waiting. the main loop
just walks this buffer servicing fds as long as there are entries in the
buffer. I'll be releasing the source once I clean it up a bit; this thing
is fast fast fast for serving small working sets from memory.
the interesting property of the ring buffer setup is that we always catch
the signals when they arrive, we never mask the signals. we just have to
keep a huge old ring buffer. i setup a test bed serving the webbench
fileset (6000 files at around 75meg, all in cache). running a tweaked
ab.c I have 500 concurrent connections burn through 20000 requests. I
get logirithmic distribution of the amount of work thats sitting in the
ring buffer. 95% of the time there are less than 50 or so pending fds in
the 1024 entry ring bufffer, but with peaks of a few hundred waiting.
This is all over 100mb between two machines. I'll probably throw far more
clients at this and we'll put specs up near Dan's cool high end serving
info-site (http://www.kegel.com/c10k.html).
I only went down this sigio/siginfo road because experiments with thttpd
were showing that select was only returning one or two fds on average..
instead of using an expensive select()/walk fds to find work, we just have
sigio drop them in the ring when they happen.
I want to work this event model into samba/squid to see if it makes a
noticable difference..
> Assuming you need a much deeper queue (4096 for example), then tuning
> rtsig-max will work, but at the cost of increasing the queue depth for
> all processes, most of which won't need it. So how about creating
the rt signal queues are dynamically created linked lists of kmem_cache
objects, having a hard limit across all processes is no problem.. having
lots of them pending across everybody would be a touch more painful.
> rtsig-limit and adding a command to prctl(2), so that a process which
> needs to increase the queue depth can do so (up to the sysadmin tuned
> limit), but other processes use the default?
considering the above, I don't see the need.
-- zach
- - - - - -
007 373 5963
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/