[chrisplough]

All,

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

[Shells]

24 hour bulk plans with no memory leaks? Now -that- is music to my ears

[chrisplough]

True - but if your bulk plan is really going 24 hours (this was just a test), you've got more pressing issues to deal with!

--Chris

[Shells]

LOL true enough

[ianlo]

Originally Posted by chrisplough

All,

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:

wrapper.java.additional.1=-jrockit
wrapper.java.additional.2=-Xms1800m
wrapper.java.additional.3=-Xmx1800m
wrapper.java.additional.4=-Xgcprio:throughput
wrapper.java.additional.5=-Xverbose:memory
wrapper.java.additional.6=-Xnoclassgc


After reading your post, will upgrading to 1.4.2_08 help? Is this JVM in any of the OTM patches? Oracle Support told me to upgrade to Jan 07 SR.

Thanks!

[chrisplough]

Ian,

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:

wrapper.java.additional.1=-jrockit
wrapper.java.additional.2=-Xms2500m
wrapper.java.additional.3=-Xmx2500m
wrapper.java.additional.4=-Xgcprio:throughput
wrapper.java.additional.5=-Xverbose:memory
wrapper.java.additional.6=-Xnoclassgc 

This should give you an extra 700MB of usable memory and give OTM the legroom it deserves (needs).

I hope this helps!

--Chris

[chrisplough]

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:

wrapper.java.additional.1=-jrockit
wrapper.java.additional.2=-Xms2000m
wrapper.java.additional.3=-Xmx2000m
wrapper.java.additional.4=-Xgcprio:throughput
wrapper.java.additional.5=-Xverbose:memory
wrapper.java.additional.6=-Xnoclassgc
...

Hope this helps.

--Chris