Thread memory allocation question
kb+varnish at slide.com
Tue Jul 7 02:35:17 CEST 2009
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
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
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.
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
> | 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
More information about the varnish-misc