Thread memory allocation question

[Ken Brownfield]

Overcommit defaults off; sane use cases for overcommit are few and far  
between, IMHO.  With overcommit on, the performance implications might  
be more of a wash... but then you have two problems.

Even though the stack remains mostly unused, it would still have to be  
swapped out under memory pressure, and thread creation and reclamation  
would cause more swap thrash.  Used or not, the performance pain is  
the same.

Plus I'd rather not allocate/waste 8GB of RAM for 1,000 varnish  
threads at idle, which represents two orders of magnitude more than it  
needs.

A 1MB limit holds up fine for me, though 256KB or even 128KB should be  
fine as well, since Varnish tends to sit at around 86KB under Linux/ 
x86_64.  Maybe Varnish could have its own stacksize parameter, rather  
than using the ulimit value?  Out-of-box scalability would be much  
better, and this is how MySQL handles it, FWIW.
-- 
Ken.

On Jun 30, 2009, at 5:11 PM, Tollef Fog Heen wrote:

>
> ]] "Poul-Henning Kamp"
>
> | In message <5C056AE2-7207-42F8-9E4B-0F541DC4B1B2 at slide.com>, Ken  
> Brownfield wri
> | tes:
> |
> | >Would a stack overflow take out the whole child, or just that  
> thread?
> |
> | The kernel would try to extend the stack and provided you are not on
> | a 32 bit system, it shouldn't ever have a problem with that.
>
> On the other hand, the gain from decreasing the stack size would  
> just be
> a bit less book-keeping for the kernel, unless you have overcommit
> turned off (which I don't think anybody actually uses), right?
>
> -- 
> Tollef Fog Heen
> Redpill Linpro -- Changing the game!
> t: +47 21 54 41 73
> _______________________________________________
> varnish-misc mailing list
> varnish-misc at projects.linpro.no
> http://projects.linpro.no/mailman/listinfo/varnish-misc