Well, let's look at some bigger picture issues before getting into JRun configuration details.
If you're getting java.lang.OutOfMemoryError exceptions in the JRun error log, well, you're out of memory. No upvote for that, please ;-). You didn't say whether you were running 32- or 64-bit Windows, but you did say that you have 8 GB of RAM, so that will have some impact on an answer. Whether or not you're running a 32- or 64-bit JVM (and what version) will also impact things. So those are a few answers that will help us get to the bottom of this.
Regardless, your application IS running out of memory. It's running out of memory for one or more of these reasons:
- Your application is leaking memory. Some object your application uses is continually referenced and therefore never eligible for garbage collection; or worse- some object created new on every request is referenced by another object in perpetuity and therefore, never eligible for garbage collection. Correct J2EE session handling can be particularly tricky in this regard.
- The amount of required memory to handle each concurrent request (at the configured concurrent request level) exceeds the amount of memory available in the JVM heap. For instance, you have a heap size of 1 GB and each request can use up to 10 MB. Your app server is tuned to allow 150 concurrent requests. (Simplistic numbers, I know). In that case, you would definitely be running out of memory if you experienced 100 or more concurrent requests under load (if each request used the maximum amount of memory necessary to fulfill the request).
Other things to keep in mind: on 32-bit Windows, a 32-bit JVM can only allocate approximately 1.4 GB of memory. I don't recall off the top of my head if a 32-bit JVM on 64-bit Windows has a limitation less than the theoretical 4 GB max for any 32-bit process.
UPDATED
I read the blog post linked via TalkingTree and the other post linked within that post as well. I haven't run into this exact case, but I did have the following observation: the JRUN metrics logging may not record the "max values" you cited in a period of peak thread usage. I think it logs metrics at a fixed, recurring interval. That's good for showing you smooth, average performance characteristics of your application, but it may not capture JRUN's state right before your error condition begins to occur.
Without knowing about the internal workings of JRUN's thread management, I still say that it really is out of memory. Perhaps it's not out of memory because your app needed to allocate memory on the JVM heap and none was available, but it's out of memory because JRUN tried to create another thread to handle an incoming request and the heap memory necessary to support another thread wasn't available- in other words, threads aren't free- they require heap memory as well.
Your options seem to be as follows:
- Reduce the amount of memory your application uses in each request, or-
- Experimentally reduce the value of the thread tuning parameters in JRUN's configuration to make more threads queue up for processing instead of becoming runnable at the same time, or-
- Reduce the number of simultaneous requests in the ColdFusion administrator (Request Tuning page, field "Maximum number of simultaneous Template requests")
Regardless of the option you pursue, I think a valid fix here is going to be experimental in nature. You're going to have to make a change and see what affect it has on the application. You have a load testing environment, right?
Doublecheck if your script translated the raw beancounters correctly. according to this you only have 256 megs of RAM, not 4 gigs as your admin tells you.
concentrate only on 2 beans:
- privvmpages - maximum amount of memory your container can allocate (reserve)
- oomguarpages - guaranteed amount of memory your container will get to actually use. In case of tight memory situation on the host everything using over that amount will probably be killed.
Java is notorious for allocating gobs of memory and then never using them, counting on the OS to overcommit. In my experience you need at least a gig of privvmpages to run JVM reliably, although only couple of dozen megs will be used.
After couple of months experimenting and trying to contain privvmpages in VEs running Java, I have personally given up, I just set the barrier to the max and tweak the oomguarpages appropriately and hope for the best ;)
Best Answer
There are several minimalist Linuxes where you can just install what you need. Ubuntu Server would probably be easiest to set up, but if all you want is Java, you could probably get Arch running like that pretty easily. Just do a base install and then:
You could get it booting real fast and light since you wouldn't need any daemons running except network (and probably sshd).