Bug? Barage of hits leads to failure creating worker threads / stats tracking

John Adams jna at twitter.com
Sat Apr 11 00:35:14 CEST 2009


It takes time to spawn threads. If you start the server with hundreds  
of threads, they won't be ready for ~30-90 seconds.

Maybe that's causing this issue?

-j

On Apr 10, 2009, at 3:12 PM, Ray Barnes wrote:

> Hi all.  Note that everything herein is based only on a very lay  
> knowledge of varnish, without being familiar with the internals of  
> the code.
>
> In my quest to eek more performance out of Varnish, I've been  
> testing under 2.0.4.  I have not seen much improvement over 2.0.3 in  
> the way it acts after receiving a bunch of hits all at one time.  I  
> am invoking varnish like this:
>
> ulimit -n 131072
> ulimit -l 82000
> /usr/local/sbin/varnishd -a 98.124.141.3:80 -b 67.212.179.98:80 -T  
> 98.124.141.3:6083 \
>         -t 60 -w1440,3000,60 -u apache -g apache -p  
> obj_workspace=16000 -p sess_workspace=262144 -p listen_depth=4096 \
>         -p shm_workspace=64000 -p thread_pools=8 -p  
> thread_pool_min=180 -p ping_interval=1 -p srcaddr_ttl=0 -s malloc,80M
> As best I can tell, the problem I'm seeing is that it will not  
> create the number of worker threads that I'm telling it to, as  
> evidenced by the 'status' output within the CLI immediately after  
> launch:
>
>          270  N worker threads
>          285  N worker threads created
> So if I launch 'ab' with 700 connections against varnish, it will  
> not work right from the beginning, like so:
>
> [root at mia ~]# ab -n 20000 -c 700 http://98.124.141.3/
> This is ApacheBench, Version 2.0.40-dev <$Revision: 1.146 $>  
> apache-2.0
> Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
> Copyright 2006 The Apache Software Foundation, http://www.apache.org/
> Benchmarking 98.124.141.3 (be patient)
> apr_socket_recv: Connection refused (111)
> [root at mia ~]# ab -n 20000 -c 700 http://98.124.141.3/
> This is ApacheBench, Version 2.0.40-dev <$Revision: 1.146 $>  
> apache-2.0
> Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
> Copyright 2006 The Apache Software Foundation, http://www.apache.org/
> Benchmarking 98.124.141.3 (be patient)
> apr_poll: The timeout specified has expired (70007)
> Total of 147 requests completed
> [root at mia ~]# telnet 98.124.141.3 80
> Trying 98.124.141.3...
> Connected to 98.124.141.3 (98.124.141.3).
> Escape character is '^]'.
> GET / HTTP/1.0
> ^]
> telnet> quit
> Connection closed.
> The above telnet command simply hung, presumably because there are  
> still 700 sessions in CLOSE_WAIT state within the kernel, although  
> that should not matter if varnish opened the number of worker  
> threads it was supposed to.  Based on what I've seen, it would seem  
> that varnish has some problem when you launch it with "too many"  
> initial worker threads (although I'm having a hard time  
> understanding why 1400ish is too many).  It seems to go crazy if you  
> specify too many threads initially.  Again, that number should not  
> be a problem for the machine in theory, as it's a multicore Xeon.   
> Platform is Linux 2.6 RHEL.  Any idea what's happening here?
>
> -Ray
>
> _______________________________________________
> varnish-dev mailing list
> varnish-dev at projects.linpro.no
> http://projects.linpro.no/mailman/listinfo/varnish-dev

---
John Adams
Twitter Operations
jna at twitter.com
http://twitter.com/netik




-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://www.varnish-cache.org/lists/pipermail/varnish-dev/attachments/20090410/b6b285d7/attachment-0001.html>


More information about the varnish-dev mailing list