Connections dropped under load

[David Birdsong]

On Tue, Jan 11, 2011 at 4:09 AM, George Georgovassilis
<g.georgovassilis at gmail.com> wrote:
> Hello Kristian,
>
> Thank you for summarizing - the relation between threads, session linger and
> connection handling has been explored indeed sufficiently in this thread.
> The advice of increasing the thread pool size is one that is not always easy
> to follow though. I'm running my app on a virtual machine (think Open VMS or
> EC2) and there is a low thread limit, so naturally I'm exploring ways of
> keeping that low especially since the application server behind varnish is
> also competing for them. nginx can as far as I know serve thousand of
> connections with just two worker threads, I erroneously assumed when first
> evaluating varnish that it was using a similar technique.

nginx uses a completely different concurrency model, but it also is
not burdened with managing as much address space and content as
varnish is under normal configurations.  in most nginx setups, it's
either proxying content to a backend app or serving files off of disk.
 try serving lots of content off of disk with just 1-2 worker
processes (nginx isn't multi-threaded) and you will start seeing
connections piling up until you up the number of workers until your
disk becomes the limiting factor.


>
> Regs,
> G.
>
>
> On 11.01.2011 08:48, Kristian Lyngstol wrote:
>>
>> thanks.
>> posting,
>> top
>> stop
>> Please
>>
>> On Tue, Jan 11, 2011 at 12:59:58AM +0100, George Georgovassilis wrote:
>>>
>>> Thank you for the hint. Here are the values:
>>>
>>> thread_pools = 2
>>> thread_pool_min = 2
>>> thread_pool_max = 200 (was 2 at the time of my initial tests)
>>> thread_pool_add_delay = 2
>>
>> As have already been pointed out, this is a low value. This also explains
>> why session_linger is an issue to you. Unless you are on 32-bit (which you
>> shouldn't ever ever ever be), there's no reason to not always have a
>> thousand threads laying around. Your settings also means that you have
>> FOUR
>> threads available when you start your tests. Not exactly a lot of room for
>> bursts of traffic.
>>
>> Your other mail actually had a thread_pool_max of 16. That will give you a
>> maximum of 16 concurrent requests that can be handled, with an other 32
>> that can be queued. With session_linger, these threads will remain
>> allocated to the connection for a longer duration, thus it's obvious that
>> in this case, your thread starvation was the real issue and you just
>> triggered it faster with a higher session_linger. It's a perfectly obvious
>> and mystery-free explanation. Session lingering is a mechanism to avoid
>> trashing your system during high load by constantly moving data around
>> between threads, but it depends on reasonable thread-settings - or rather:
>> an abundance of threads.
>>
>> http://kristianlyng.wordpress.com/2010/01/26/varnish-best-practices/
>> sounds
>> like a good place to start reading. Specially about threads.
>>
>> - Kristian
>
>
> _______________________________________________
> varnish-misc mailing list
> varnish-misc at varnish-cache.org
> http://www.varnish-cache.org/lists/mailman/listinfo/varnish-misc
>