Thanks much, guys, for the replies. We've arrived at the same conclusion that Scott suggests - a GB for the heap and the other GB for the product (roughly) of the threads and the stack size in our windows 32-bit environment.
Now it's an exercise in testing the actual -Xss size that we want to run with - which is proving to be a bit elusive. Understanding that local primitives and heap-object addresses are stored on the stack, I can't envision a need for a stack size anywhere bigger than 1MB (for our app, YMMV). Even 1MB is probably way over doing it. There's a few of us here at work who have been lurkers on this list for a long time - or at least a couple of years anyway. We've always found this list valuable and appreciate everyone's involvement. Thanks again. + jay Scott Ferguson wrote: > On Jan 8, 2009, at 5:23 PM, Rob Lockstone wrote: > >> On Jan 8, 2009, at 13:52, Jay Ballinger wrote: >> >>> Hi everyone, >>> >>> We're running Resin 3.0.18 Pro on a Windows 32-bit system and we're >>> looking to understand/tune our memory settings a bit. >>> >>> According to http://www.caucho.com/resin-3.0/performance/jvm-tuning.xtp >>> the stack size is set to 2048k unless set otherwise. Is this true? >>> In using JConsole we can't see where any explicit -Xss setting is >>> passed and we can't readily determine what the current stack size is >>> set to. > > Try -verbose when starting. Since the -Xss is a command line option, > it should be reported. Also, JConsole should be able to see the > command line options on one of the system beans. > >> I think Caucho tends to err on the side of caution in this regard, and >> is also (understandably) more *nix-central than Windows. So take that >> 2048K as being "appropriate for most situations" with a grain of salt >> because situations can vary wildly. > > Basically. There's no way for us to know if your application needs > more stack or more threads. So I assumed 1G heap, leaving 1G for > other stuff, and then figured the default should support 1000 threads, > giving 1m as a default, which should be enough stack unless you have > massively recursive applications, and enough threads for most apps. > You know your own requirements best, of course. > > I believe Linux is the most finicky about the stack allocation, so it > was the OS we needed to solve (and it was the OS which exposed the > issue first.) > > I'm really looking forward for the 64-bit transition to complete so we > can use as much VM as possible. > > -- Scott > > >> >>> So, here's a short list of questions. And thanks for your help. >>> >>> - If JConsole doesn't show -Xss, is it really there for resin? >> Whether it's explicitly set or not, there IS a stack size, which would >> end up being the default stack size of the operating system if the JVM >> itself doesn't set it (I do not think it does, but could be wrong and >> don't feel like looking it up now). >> >>> - How was "2048k is an appropriate value for most situations." >>> determined? >> See above. >> >>> - Can resin/jvm/jconsole report the current stack memory setting? >> I don't know if there's a way to query a running JVM for this >> information. It's best if you explicitly set the stack size using the >> JVM option -Xss (but see below). >> >>> (general sun jvm on windows questions) >>> - What is the default stack memory size? >> That's too general of a question. It depends on the OS, and (perhaps) >> the version of the OS. >> >>> - When a thread is created, does it grab all of the stack memory, or >>> can the stack memory start small and grow to the default or -Xss >>> size? >> Again, might depend on the operating system. Contrary to what Knut >> said, and to the best of my knowledge and in the testing that I did >> (it's been a while), all of the memory for the stack is pre-allocated >> (at least from the perspective of the JVM itself). But it's easy >> enough to write a program to check this. >> >> Thread stacks, at least on Windows, are more complicated than just a >> single memory allocation (down at the Windows API level) because >> you've got both reserved and committed memory allocations, and one >> always has to be >= the other (I forget which), and there's a 64K >> granularity in sizing, and you're dealing with physical and virtual >> memory, and this is all set in the linker and therefore configurable, >> but can also be set programmatically on a per-thread basis. In other >> words, it's quite involved. See this page as an example of how complex >> this kind of memory management is when you go into how the underlying >> OS is actually managing all of this >> <http://msdn.microsoft.com/en-us/library/ms686774(VS.85).aspx >>> . >> Remember, thread allocation/destruction as well as context switching >> and just about everything else is managed by the operating system, not >> Java (unless you're running "green" threads, which I don't think is >> even around anymore?). This is why the memory used by the thread's >> stack is not part of the Java heap. On a 32-bit machine, the maximum >> addressable space for an individual java program is 2G. So, for >> example, if you run java with these parameters on a 32-bit machine: >> >> java -server -Xms1500M -Xmx1500M -Xss1M >> >> then you'll leave enough room to run ~548 threads (2048M - 1500M = >> 548M / 1M stack = 548 threads). Of course, that assumes that none of >> the 548M of non-java-heap memory is being used for anything else, >> which is a false assumption, perhaps hugely false depending on what >> your java program is doing, e.g. graphics operations or the like. >> >> Something I discovered while optimizing our Resin on Windows >> environments is that the version of Windows and Java we use (64-bit >> Windows 2003 Server with Java 1.5) will allow a minimum stack size of >> 128K, and if you try to specify a stack size of 256K or 512K, Windows >> (or maybe the JVM, I don't know which one for sure) automatically >> jumps you up to 1M. So you have a choice between 128K, 1M, 2M, ??? (I >> didn't test above 2M). >> >> Fwiw, we've got dozens of Windows servers running Resin Pro 3.0.x >> (upgrading to 3.1.x in the not-too-distant future), and we run all of >> them with a 128K stack size. In general, unless you're running code >> that's highly recursive, you don't need very large stack sizes in Java >> programming. >> >> Rob >> >> >> >> _______________________________________________ >> resin-interest mailing list >> [email protected] >> http://maillist.caucho.com/mailman/listinfo/resin-interest > > > > _______________________________________________ > resin-interest mailing list > [email protected] > http://maillist.caucho.com/mailman/listinfo/resin-interest _______________________________________________ resin-interest mailing list [email protected] http://maillist.caucho.com/mailman/listinfo/resin-interest
