Thread memory allocation question

[Ken Brownfield]

On Jun 19, 2009, at 7:15 AM, Tollef Fog Heen wrote:
> | 0000000040111000   8192K rw---    [ anon ]
> Looks like the default stack size.

Ah, of course.  Good find, thanks.  I'm thinking it might be nice to  
have a thread track its stack history and emit its approximate largest  
size when it's reaped (and the workspaces too I suppose).

Would a stack overflow take out the whole child, or just that thread?

The 1024K blocks roughly add up to the SMA outstanding bytes, so I'm  
assuming these are jemalloc block allocations, and not related to  
thread count:

lib/jemalloc/malloc.c:
	#define CHUNK_2POW_DEFAULT      20

Thanks!
-- 
Ken.

On Jun 19, 2009, at 7:15 AM, Tollef Fog Heen wrote:

> ]] Ken Brownfield
>
> | When looking at /proc/map info for varnish threads, I'm seeing the
> | following allocations in numbers that essentially match the child  
> count:
> |
> | 0000000040111000   8192K rw---    [ anon ]
>
> Looks like the default stack size.
>
> | And this at almost double the child count:
> |
> | 00007f4d57900000   1024K rw---    [ anon ]
>
> Unsure what this is.
>
> | I noticed some pretty intense memory usage when I had a backend  
> issue
> | and the thread count increased into the hundreds.  Obviously the
> | threads will need memory as they scale, but are these large
> | allocations intentional, and are they tunable (beyond the relatively
> | small workspaces?)
>
> You should be able to tune it using ulimit -s.  If you turn it too  
> low,
> things will break, though.
>
> -- 
> Tollef Fog Heen
> Redpill Linpro -- Changing the game!
> t: +47 21 54 41 73