Performance options for trunk

[Audun Ytterdal]

I run trunk in front of a site. I have 3 varnishservers, all with 32GB

of ram serving only small pictures, thumbnails and profile pictures. The
cacheset is pretty large (1.5 TB) and changing much over time. And
before you all ask why I don't just server partitioned data from several
apache/nginx/lighttpd servers It's because we're not there yet. The
varnishes all fetch their content from one lighttpd server .

I run into the Thread pileup-problem

I've set threadlimit to 1500 and it usually lies between 80 and 700.
While restarting it hits the 1500 limit and stays there for a few
minutes. Then it gradualy manages to controll traffic and ends up around
80 threads. It usually grows a bit. But not over 700-1000 ish. But
suddenly, under high traffic it goes up to the limit beeing 1500 or 4000
or whatever i set it to. Then it stays there and usualy never recovers
without a restart.
I guess it's because the backend at some point answers slowly. But is
there a way to easier get out of this situation.

Running varnish like this:

(redhat 4.6 32 GB RAM)

/usr/sbin/varnishd -a :80 -f /etc/varnish/nettby.vcl -T 127.0.0.1:82 -t
120 -w 2,2000,30 -u varnish -g varnish -p client_http11 on -p
thread_pools 4 -p thread_pool_max 4000 -p listen_depth 4096 -p
lru_interval 3600 -h classic,500009 -s
file,/var/varnish/varnish_storage.bin,30G -P /var/run/varnish.pid

and for testing purposes

(redhat 5.1 32 GB RAM)

varnish  22959 17.1 45.2 20187068 14938024 ?   Sl   May29 160:40
/usr/sbin/varnishd -a :80 -f /etc/varnish/nettby.vcl -T 127.0.0.1:82 -t
120 -u varnish -g varnish -p thread_pools 4 -p thread_pool_max 2000 -p
client_http11 on -p listen_depth 4096 -p lru_interval 3600 -h
classic,500009 -s malloc,60G -P /var/run/varnish.pid

Each varnish handles about 3000 req/s before it caves in.

Any suggestions?

Are the parameters sane?

--
Audun



*****************************************************************
Denne fotnoten bekrefter at denne e-postmeldingen ble
skannet av MailSweeper og funnet fri for virus.
*****************************************************************
This footnote confirms that this email message has been 
swept by MailSweeper for the presence of computer viruses.
*****************************************************************