This is one of those times when an "outofmemory" error is NOT what it seems. The answer is NOT because you're running out of heap space, and the solution is NOT to increase the heap space (which as you may know, if on 32-bit version of CF, you're already about maxed out at anyway at 1.4gb).
This may shock some, but I would bet the answer for you is to lower your max heap size instead. Heresy, I realize.
I don't have time to elaborate, but again if this is a 32-bit OS (or CF is running in 32-bit mode), you may know you can only get 2gb of user space per process. If you do use up 1.4gb of it with heap, and then also the 192m you show for permgen (which is the default and usually an ok value), and then add in some OS overhead, what's left gets used for the "stack space" (a place to allocate a stack for each running thread). If there's not enough room to allocate a stack for a running thread, you get that error.
TO be clear, you can't control the size of the stack, so instead I'm proposing that you lower the heap to give it more breathing room.
You will read of some proposing to use the -xss switch--that's to control the size of each entry in the stack (not the total stack space size). Sadly, it's risky business trying to fix things by changing the xss. For one thing, I've not found a good java reference to confirm what the current size is on any given jvm, so how do you know if the value you use (from some blog entry suggestion, for instance) is making the stack entry size bigger or smaller than your current default?
Some may wonder, "so if a stack entry gets allocated for each thread, is this related to the size of the simultaneous request threads entry in the CF Admin?" Well, it is, but that's really only just one of several thread pools in a CF system. There are threads for every database connection, threads for request waiting to run (the queue), threads to manager client variable repositories, threads used for internal java processes, and so on.
You may sometimes find that the error above is driven more by an over-abundance of threads being created, but in my experience, that's not the problem. It's the stack space being allocated in leftover memory space being squeezed by the heap and permgen. Those are easier to lower, though I'd focus on the larger heap. Some servers really don't need the heap as large as they make it. As long as you don't get corresponding outofmemory errors reporting "out of heap" problem if you lower the heap, you're generally ok.
As so many things, it's a balancing act. HTH.
/charlie
/Charlie (troubleshooter, carehart.org)
12
Replies
AdChoices