Barry, for what it's worth, I'll offer some more thoughts. You're on the right track.
First, I'll concur with Kai and your observation that this is about the possibility of the heap being high, thus constraining the space left for creating stacks. As Kai noted, it's counterintuitive because we all assume "outofmemory" means "out of heap", but it doesn't. Yours is due to running out of stack space, not heap. As such, yes, lowering the stack size can help, but as you note, if your config's default is 256k (which others should note as Kai said is dependent on jvm, os, and architecture) so you're leery of lowering it more. You can, but just watch out for errors due to "stackoverflow". It's a delicate balance. You're right to focus first on just lowering the heap. Especially if you have some means to have monitored and confirmed that you're not having outofmemory errors due to running out of heap. (And you can't use as a gauge whether you've "hit" the heap max, as shown in some monitoring tool, because you usually will. The question is whether when the system did a GC, did it recover a lot. If so, and consistently, then you can afford to lower the heap. Just watch out for possible new "oom: heap space" errors.) But then there is also the matter, as you brought up originally, of lowering your thread use. As much as the max threads may seem to be the issue, it may not be. Rather, there are MANY things that create threads in a CF/JRun environment. It could be datasource connections. Do you have them limited at all? Timing out? Even then, there have been bugs where they've not timed out when they should. What CF version are you running? And what hotfixes? And are you sure you have the right ones? (It's easy to have mis-implemented 8.0 hot fixes on an 8.0.1 server, and vice versa, for instance.) You can also enabled JRun metrics to track the various thread pools, which can help identify if something is getting out of whack. You can also monitor thread use from the jrun.exe process, from the OS perspective, which can help. The good news is that this problem can be solved, generally, once you have a clearer idea of what the problem is (and is not). /charlie From: [email protected] [mailto:[email protected]] On Behalf Of Barry Chesterman Sent: Monday, April 12, 2010 12:03 AM To: [email protected] Subject: Re: [cfaussie] RE: Coldfusion JRun Max handler threads setting Thanks for the replies. I will do some load tests with adjusting the queued threads setting, from what I've read, the 'unable to create new native thread' errors are related to having a large heap size (which we do) and the operating system not being able to spawn new threads (as an OS thread is spawned to keep track of each JVM thread). We previously had standard 'out of memory' errors which were in fact related to a heap size that was too small. Kai, we use JVM 1.4 at the moment, and thread stack size is by default 256KB, so I don't think i'll look at adjusting that as 256KB is supposed to be pretty low, Apparently JVM 1.5 upwards use 1MB :O! We have our max handler threads (wait queue) at 500, and our active threads at 25, I'll have a go at decreasing the heap size and max handler threads and do some load testing. Thanks for your help all. Barry -- You received this message because you are subscribed to the Google Groups "cfaussie" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/cfaussie?hl=en.
