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-0f541dc4b...@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@projects.linpro.no > http://projects.linpro.no/mailman/listinfo/varnish-misc _______________________________________________ varnish-misc mailing list varnish-misc@projects.linpro.no http://projects.linpro.no/mailman/listinfo/varnish-misc