I've been testing OTM on Linux with the JRockit 1.4.2_08 JDK, instead of the 1.4.2_05 JDK that ships with OTM (thanks for the tip, Nick). I have to say that there are some significant improvements in this version, primarily around the memory allocation.
Note: I'm sure this configuration (at the time of this post) is unsupported by Oracle. Any risk you take is your own responsibility.
Now that the disclaimer is over, I can tell you that I simply replaced the existing JDK with the new one. Tuning will come at a later point and wasn't important for this test. I simply wanted to see how large of a memory heap I could startup OTM with and run reliably on 32-bit Red Hat ES Linux. With the previous version of JRockit, the max was around 1400MB, which is significantly lower than other platforms. After making the swap, I was able to allocate heaps up to 2500MB consistently, and sometimes 2800MB, depending on how the kernel was configured. This is AMAZING! This allows OTM on Linux to reap the performance benefits of JRockit while utilizing more memory for efficiently handling large volumes of transactions and complex bulkplans.
I can say that this combination appears incredibly stable. It has withstood several 6-8 hour bulkplans (don't ask!) and one infinite bulkplan that we let run for over 24 hours. During the entire run, we could not detect memory leaks or instability in the new version of JRockit.
I've been testing OTM on Linux with the JRockit 1.4.2_08 JDK, instead of the 1.4.2_05 JDK that ships with OTM (thanks for the tip, Nick). I have to say that there are some significant improvements in this version, primarily around the memory allocation.
Note: I'm sure this configuration (at the time of this post) is unsupported by Oracle. Any risk you take is your own responsibility.
Now that the disclaimer is over, I can tell you that I simply replaced the existing JDK with the new one. Tuning will come at a later point and wasn't important for this test. I simply wanted to see how large of a memory heap I could startup OTM with and run reliably on 32-bit Red Hat ES Linux. With the previous version of JRockit, the max was around 1400MB, which is significantly lower than other platforms. After making the swap, I was able to allocate heaps up to 2500MB consistently, and sometimes 2800MB, depending on how the kernel was configured. This is AMAZING! This allows OTM on Linux to reap the performance benefits of JRockit while utilizing more memory for efficiently handling large volumes of transactions and complex bulkplans.
I can say that this combination appears incredibly stable. It has withstood several 6-8 hour bulkplans (don't ask!) and one infinite bulkplan that we let run for over 24 hours. During the entire run, we could not detect memory leaks or instability in the new version of JRockit.
Hope this helps!
Thanks,
Chris
Hi Chris,
I recently encountered a JVM crash on my OTM app server. How I found out was that there was apparently a DEFUNCT jvm thread when I did a top. (Later I found out that several orders had data quality issues )
I reported this to Oracle and they told me that the JVM probably ran out of memory. However, I am wondering how is this so when I have 4 GB RAM? I am running 1.4.2_05 and I set my WebLogic conf file as:
I'd definitely upgrade to the latest SR (January 07 at the time of this writing). Oracle had to upgrade the JRockit JDK included to 1.4.2_11 - so in addition to the rest of the fixes, you'll get a fully-supported JVM upgrade. With this JVM, you'll also be able to utilize larger java heaps. For instance, you could change the settings in your weblogic.conf file to:
FYI - after working with a few clients, we found that a 2000MB JVM heap was much more stable for our clients. So, taken from the post above, the settings should be:
)
Linear Mode
