Announcement

Collapse
No announcement yet.

[SOLVED] Larger Heaps on Linux - JRockit 1.4.2_08

Collapse
This topic is closed.
X
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • [SOLVED] Larger Heaps on Linux - JRockit 1.4.2_08

    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

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

    Comment


    • #3
      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

      Comment


      • #4
        LOL true enough

        Comment


        • #5
          JVM Crashes

          Originally posted by chrisplough View Post
          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!
          Attached Files

          Comment


          • #6
            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:

            Code:
            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

            Comment


            • #7
              Re: Larger Heaps on Linux - JRockit 1.4.2_08

              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:

              Code:
              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

              Comment

              Working...
              X