Varnish 2.0.3 stops accepting connections - fixed? Performance revisited

[Ray Barnes]

Hi all.  I have already seen Eden Li's patch, apparently committed to
2.0.4, which fixes the problem of varnish not re-checking to see if
file descriptors are available again to service connections - at least
that's my extremely lay understanding, being mostly a non-programmer.
Further to Eden Li's post to this list which says "We're getting
around it now by setting the max open file limit and listen_depth
appropriately so that varnish never gets to this point, but it'd be
nice if this was fixed in case we ever accidentally get here again." -
I'm wondering if someone can critique my config.  I've observed
several instances where Varnish would do exactly what Eden describes -
stop listening to requests on port 80.  A 'telnet ip 80' would simply
freeze indefinitely and not connect.  The child process was running,
etc.  So I'm going to assume for the moment that the bugfix will be
the fix for this issue, as I have not been able to duplicate it under
lab testing, but only under live load conditions.  Here is the way we
call varnishd:

#!/bin/bash

ulimit -n 131072
ulimit -l 82000


/usr/sbin/varnishd -a x.x.x.x:80 -b x.x.x.x:80 -T x.x.x.x:6083 \
        -t 60 -w150,2000,60 -u varnish -g varnish -p
obj_workspace=4096 -p sess_workspace=262144 -p listen_depth=8192 \
        -p shm_workspace=29000 -p thread_pools=24 -p thread_pool_min=8
-p ping_interval=1 -p srcaddr_ttl=0 -s malloc,60M

This configuration was a hack between John Adams config from a post
from February with the subject "Is anyone using ESI with a lot of
traffic?", and the Fedora startup script for varnish in /etc/init.d -
platform is Linux 2.6 (Fedora 10 and RHEL).  cat /proc/sys/fs/file-max
says 65535 - I set this value on the fly without rebooting yet.  This
behavior I described, where port 80 will stop taking connections, is
also present when I call varnishd using simply 'varnishd -a x.x.x.x:80
-b x.x.x.x:80 -T x.x.x.x:6083' with no ulimit commands, no additional
arguments, and as far as I can remember, default FDs in
/proc/sys/fs/file-max.

Before I "chase my tail" any further, can anyone recommend any
improvements to the above config?  Also, is there any particular
reason, given the above config, why 'ab' (the apache benchmarking
utility) would fail intermittently to connect 1000 concurrent sessions
to varnish?  I found that when I used John Adams' default of 400
initial minimum threads, the daemon would do unpredictable things and
not let me run 'ab' consistently without refusing the connections -
any idea why?

Thanks in advance, both for any replies, and to everyone who has
contributed to the project.

-Ray