Archived

This forum has been archived. Please start a new discussion on GitHub.

How can I known if my thread stack size is set correctly?

I've intergrated the IcePatch2 code into my own server, which is the calc and FileServerI, at first, they worked fine.

but some day, it cannot work, after some hours of debugging, i found it always crashed (segment fault) without finishing the bzip compressing ( in fact, it lefts a temp file, *.bz2temp and file length is 0 ), fiannly, I found it's because I set the server and client thread pool's stacksize to 20K, then I enlarge them to 200K, everything works fine again.

But here is my question: How do I known how much stack size should I set? or How do I known if my setting of stack size is correct?

Any suggestion ?

Thanks again, your gurus.

Comments

  • bernard
    bernard Jupiter, FL
    In general, I would recommend to leave the stack size to its default value.

    The stack size is just virtual address-space and is not allocated until it's needed. The main use-case for changing the stack-size of your threads is when you run a very large number of threads in a 32-bit process; in this case, with say 1MB virtual address space per thread, you can reach the 2^32 (4GB) virtual address space limit with only a few thousand threads.

    Best regards,
    Bernard
  • As you found out, if the stack size is too small, your process is history. There is no way to find out what the smallest possible stack size is other than to experiment. Check your code for functions that either allocate a lot of data on the stack or are recursive (or both), and stress those functions. They are the ones that will require the most stack space.

    If you run a test case that gets these functions into the deepest possible call chain, you can then reduce the stack size until the process dies, and then increase it again, leaving some margin.

    Note that setting the stack size too large is detrimental too--the kernel must reserve swap space for all the stacks (even though they don't consume any real memory until they grow). However, swap space is limited too. If lots of programs allocate far more swap space than they really need, the kernel will eventually refuse to spawn more processes because it can no longer guarantee that it will be able to meet their future memory requirements.

    Cheers,

    Michi.
  • thanks very much for your replies, so from your replies, the correct thread stack size is concerned with how you use the thread, but I'm using IcePatch code, so do you have any test on how large directory IcePatch File server can handle? does there any recurise method used in IcePatch?(I think it used when it handle directory), so do you guys have any idea on how deep directrory that IcePatch FileServer can handle? and the guide for setting thread stack size ? because I want to integrate icepatch file sever in my program, sharing one adapter, and my program uses large number of thread pool, so it's important to known how to set thread stack size for ice patch file server.
  • We don't have any specific test case. However, we've run IcePatch2 on very large file systems with deep directory hierarchies and lots of files in directories without ever running into a stack space problem (using the default thread stack size).

    I'm also concerned about your design, with hundreds of threads. I cannot think of any problem that would require that many threads. Most likely, all this will do is degrade performance due to excessive context switching and increased working set size. It is highly unlikely that doing this is going to achieve anything worthwhile.

    It's difficult to say more without knowing more about what you are doing. If you contact us at info@zeroc.com, we can provide commercial consulting services to help with the design of your application.

    Cheers,

    Michi.