Re: Thread memory allocation question
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
Re: Thread memory allocation question
]] "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
Re: Thread memory allocation question
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. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ varnish-misc mailing list varnish-misc@projects.linpro.no http://projects.linpro.no/mailman/listinfo/varnish-misc
Re: Thread memory allocation question
On Jun 19, 2009, at 7:15 AM, Tollef Fog Heen wrote: > | 40111000 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: > | > | 40111000 8192K rw---[ anon ] > > Looks like the default stack size. > > | And this at almost double the child count: > | > | 7f4d5790 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 ___ varnish-misc mailing list varnish-misc@projects.linpro.no http://projects.linpro.no/mailman/listinfo/varnish-misc
Re: Thread memory allocation question
]] 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: | | 40111000 8192K rw---[ anon ] Looks like the default stack size. | And this at almost double the child count: | | 7f4d5790 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 ___ varnish-misc mailing list varnish-misc@projects.linpro.no http://projects.linpro.no/mailman/listinfo/varnish-misc
