Pinned topic ITCAM for WebSphere GC Analysis
Answered question This question has been answered.
Unanswered question This question has not been answered yet.
I'm having trouble understanding the data coming from the Garbage Collection Analysis attributes. Do they come from the native_stderr.log by default? If so, why doesn't the data in the workspace match up to the data in the log file? For example, if I look at the Garbage Collection Analysis table in the workspace (after adding the Heap Used % attribute), I see 63.9% used. But in the native_stderr.log it's about 50% used. We do use gencon and have heaps larger than 2 GB. We are also using ITCAM for WebSphere 184.108.40.206 on WAS 6.1 (Windows Server 2003).
Updated on 2012-01-16T21:02:37Z at 2012-01-16T21:02:37Z by svenkatesh
svenkatesh 120000P93J1 Post
Re: ITCAM for WebSphere GC Analysis2012-01-16T21:02:37ZThis is the accepted answer. This is the accepted answer.The data for Garbage Collection Analysis workspace is retrieved at a fixed interval as specified by its setting in the TEMA configuration properties, which is 60 seconds by default. When TEMA requests the data from Data collector at this interval time, the DC returns the data based on the following conditions:
1. If there was one or more GCs during that time interval, then the GC data for heap free/used will be based on the last GC entry in the verbose GC log (whose default file is native_stderr.log or IBM JVM or native_stdout.log for HotSpot). The number of GCs during this interval period is also indicated in the workspace. Note that the verbose GC log file is usually redirected to a different file during DC configuration. By default, it would be
2. If there were no GCs done during the data retrieval time interval, then the current free and allocated sizes are obtained from java.lang.Runtime class' freeMemory() and totalMemory() methods. These would return values that are Java system snapshots at that particular instant. The "Number of GCs" value in the workspace for this case would be zero.
Hence, the GC data could be a combination of data from verbose GC and direct Java Runtime calls. When you verify the numbers in the workspace against the verbose GC log, make sure the "Number of GCs" field has a value greater than zero.