Comentários (12)

1 JohnPape comentou às Link permanente

With respect to the number following the thread name : the value is a monotonically increasing number that is assigned to a new thread in the thread pool. The large value indicates that there have been quite a few thread creates in the pool but, it does not necessarily indicate that the thread pool is not bounded. Even in a thread pool, threads can be destroyed after a period of non-use. Pools are designed with the ability to scale up and back down as need arises.

2 ScottyThomason comentou às Link permanente

Thanks for the feedback John. I agree with your comments and reworded the last paragraph to include your thoughts.

3 foocked comentou às Link permanente

Hi John , from Argentina , I have an AIX 6.1 with WebSphere Network Application Server 7.0 .It's an Standalone partition with 6GB memory and one application ear running, and his memory heap are
Mi question is according your comments "To debug native memory problems, the first step is to ensure Max Heap size is not set too high (above 1536M). Find for "-Xmx" and you should be at the Max heap size. In this case, it's 1024, so you are within the 1536M"

It's wrong my configuration?
thanks and regards!

4 mmoritz@th comentou às Link permanente

Hi Ivan,

On the configuration you specified, the -Xms1024m is the starting Java Heap only and this will grow to the -Xmx value which is the maximum Java Heap size. you should ammend this to:
If you are running a 32 bit WAS installation, -Xmx2048m would not leave enough room for the native memory and you should set it to -Xmx1536m as specified above. This is because the maximum addressable area for the Heap and the native memory together on 32bit is 2048m .
-Xmx2048 refers only to the Java Heap leaving no space at all for native memory objects.
-Xmx1536m would leave 512m for the native memory (1536+512=2048).

5 KamleshMalviya comentou às Link permanente


I have a similar setup at my end (AIX6.1, WAS 7.0 and 20GB memory), Now my application is facing OOM exceptions. The minimum heap size is set to 1.5 Gb and max to 2.0 GB, so do I have to set the max to 1.5GB or is there any other solution?

6 ScottyThomason comentou às Link permanente

Hi Ivan, I agree with Michele and do not have anything to add.


7 ScottyThomason comentou às Link permanente


Thanks for adding your comment. I'm glad you pointed out 32 bit since the recommendation of max heap at or below 1536 is based on a 32 bit install of WebSphere Application Server. After re-reading, I think I should be more clear that's the case. I'll update that part to be more precise.

8 ScottyThomason comentou às Link permanente

@Kamlesh, It's difficult to say since I am not sure if your OOM problem is native or heap related or if you are running 32 bit WebSphere Application Server. Take a look at the javacore example in the blog for how to determine if it is a native or heap. If you are running 32 bit WebSphere Application Server, it's highly likely you are having a native memory problem due to the max heap size being set to high and I would recommend lowering the max to 1536m or lower.


9 VitalyR comentou às Link permanente

Hi Scotty,

I am a late guest in this discussion. We cannot even make the 32-bit WebSphere 7.1 server on AIX 5.3 start with Xmx=2048m and currently we are using Xmx=1586m. Every several days we get OutOfMemory crash and from the javaheap dump I can see that the memory has been used up to the last byte. I have tried to set the LDR_CTRL variable for bigger memory models but this seems to have no influence on the WAS jvm.
On the other hand I can call the WAS-included java with the higher mx e.g.:
$WAS_HOME/Appserver/bin/java -Xmx3000m -version
Which returns success.
Is my only option to go for WAS 64 bit?

10 SteveWebb comentou às Link permanente

@VitalyR Thanks for the comment. Your question is quite involved and we can't provide "support" through the blog. So if you need further assistance, I recommend that you open a Service Request through the SR tool using the following link -
Thanks, Steve

11 SumitTambe comentou às Link permanente

Hi Scotty,

Thanks form the detail explaination abt OOM issue.
We are running WAS v7 32-bit on Linux.
Just going through ur blog we thought that it would be clearly a native memory issue since we were also getting the below message in the javacore.
TITLE subcomponent dump routine
NULL ===============================
1TISIGINFO Dump Event "systhrow" (00040000) Detail "java/lang/OutOfMemoryError" "Failed to create a thread: retVal -1073741830, errno 11" received
But while troubleshooting the native memory issue, we found that the heap itself is not fully utilised.PFB the details.
0SECTION MEMINFO subcomponent dump routine
NULL =================================
1STHEAPFREE Bytes of Heap Space Free: 3031EF30 approx 0.8 GB
1STHEAPALLOC Bytes of Heap Space Allocated: 40000000 approx 1GB
Then native can utilize this 0.8GB and should not be giving OOM issue.
Or is there something else which we need to check or monitor to solve this issue.

12 ScottyThomason comentou às Link permanente


I appreciate the comments and that you were able to get started looking at the information in your javacore. I agree it sounds like you should not be seeing the OOM related to heap exhaustion based on what you have indicated, but I would still recommend decreasing it to 1536. Setting it to 2048 can only be problematic.
My first thoughts are for you to check the bottom of the blog where it gives the WebContainer example and make sure you have threadpools set as indicated for that symptom in the javacore. If neither recommendation helps, you could make sure you are on the most current fix pack. Otherwise, it's likely you have a leak that needs to be looked at by the IBM Support team so I believe you would need to open a PMR. You can do that on the Service Request site -
Scotty T