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
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
Comment