On January 27th, this site will be read-only as we migrate to Oracle Forums for an improved community experience. You will not be able to initiate activity until January 30th, when you will be able to use this site as normal.

    Forum Stats

  • 3,889,573 Users
  • 2,269,760 Discussions
  • 7,916,783 Comments

Discussions

JRA-Analysis

Sawan Patwari
Sawan Patwari Member Posts: 11
edited May 25, 2015 9:52AM in JRockit

Hi,

We have been having Out-Of-Memory issues in our Production Weblogic 10.3.2 Servers that we use. So we are trying to replicate the OOM issue in our Test Servers. In this quest, we took the JRA recording for one of the Test Servers. We have attached the screen shot of GC pattern seen in JRMC. We tried to attach JRA file but it seems it is not allowed to. We have a total heap size of 2 GB and Nursery size of 512 MB. The GC strategy used is Genparpar. Please let us know if we need to do any sort of tuning to have better GC activity than what we have today. Also I have attached the exceptions that we encountered in Production Server and the Thread-Dump taken from Production Server but the JRA recording that is attached is from Test Server. We tried to replicate the OOM issue that we see in Production Server in Test Server but we haven’t achieved just yet and the reason why I say like this is because we haven’t seen any OOM issues getting reported in our Test Server logs.

Our concerns are as follows:

  1. Are we running the right GC mode with the right configuration or settings? Please let us know your suggestions from JRA recording that I have shared.
  2. The Old Collection is happening when we almost hit the roof of 2 GB. The Heap usage gradually increases to the max value and that is when Old Collection is being called and Heap memory usage comes down to 150 MB. We will have to see if we can have the Old Collection happening before even we hit the max value or close to max value. I am aware of the fact that we have the option of configuring ‘<strong style="font-size: 14.0pt;">gctrigger</strong> but as I understand this option is when we have Mostly Concurrent GC strategy. Currently, we are having Genparpar Strategy.

Please let me know if I need to furnish any more information.

Thanks in advance.

Regards,

-Sawan.Patwari

Answers

  • Mattis Castegren-Oracle
    Mattis Castegren-Oracle Member Posts: 16
    edited May 25, 2015 9:52AM

    Hi

    The picture of the JRA recording looks very good. What you see there is a Young Collection triggered because a TLA could not be allocated. This is the usual reason we trigger a Young Collection. After that, we still couldn't allocate a TLA, which is why we triggered an Old Collection, that reduced the heap usage down 197MB. This is exactly how a GC graph should look, a jagged line upwards followed by a sharp drop when the Old Collection is triggered.

    The exceptions you see are OutOfMemory errors. These are not at all correlated to the GC tuning. You simply don't have enough space on the Java heap. In the picture of the JRA recording, you only use 197 MB out of a 1.8GB heap, so I doubt these OOMs comes from the time you took the JRA. However, at some later point in time, the heap must be getting full, and you see these OOMs.

    We never throw an OOM without first trying to do a full GC, so if there is memory left after a GC (like in the JRA) we shouldn't throw OOMs (unless you try to allocate a huge array and we can't find a big enough continuous block of memory due to pinned objects... which is really rare).

    What you should investigate is the amount of memory after your Old Collections to see if that memory is increasing over time. If so, you have a memory leak in your program, which is nothing you can fix with tuning

This discussion has been closed.