Analyze WebSphere native_stderr or native_stdout log

Home > Search
  by

The native_stderr.log and native_stdout.log are WebSpheres verbose garbage collection logs. These logs are created when verbose garbage collection is enabled, by navigating to Servers > Server Types > your_JVM > Java and Process Management > Java Virtual Machines. After enabling verbose garbage collection, restart the JVM for this change to take effect.

 

Assuming there is a unique log for each 24 hour period, typically, each log should be less than 2 MB. Logs that are 2 MB or less probably do not need to be analyzed.

To analyze a log, use IBMs Garbage Collection and Memory Visualizer, which is part of IBMs Support Assistant.

  1. In the IBM Support Assistant, select the Tools tab.
  2. Select Garbage Collection and Memory Visualizer Desktop.
  3. Select Launch.

 

Analyze the log. It is usually a good idea to compare at least a few of the log's, to see if the tuning recommendations in each log are similar or different. 

  1. In the Garbage Collection and Memory Visualizer tool, select File > Load File.
  2. Select the log file you will like to analyze.
  3. At the bottom of the GUI, select the Report tab.

 

Tunng recommendations will be displayed. Following are the steps for known recommendations.


Recommendation: Your application appears to be leaking memory. This is an indication by the used heap increasing at a greater rate than the application workload (measured by the amount of data freed). To investigate further see IBM SDK User Guide.

What you should do: TBD


Recommendation: Excessive time (x.xx%) is being spent in GC. Consider increasing the size of the heap.

What you should do: The heap size determines how often and how long a JVM does garbage collection. When the maximum heap size is large, garbage collection will occur less frequently but will take longer. When the maximum heap size is small, garbage collection will occur more often but will take less time. Garbage collection negatively impacts a JVMs performance, so the goal is to find the heap size that cause the least performance hit. Typically, the proportion of time spent in garbage collection pauses should be less than 1%. 

 

If the proportion of time spent in garbage collection pauses is greater than 1%, determine the steady state after the JVM is restarted. For this, you will need to get the native_stderr.log when the JVM was last restarted. In this example, the JVM was restarted around 3:00 am, and the steady state is near 250 MB, which means a minimum heap size of 256 MB would be appropriate.

Since a large maximum heap size will cause garbage collection to occur less often but will take longer, you don't want to set the maximum heap size to be unnecessarily large. What you want to do is to set the maximum heap to be larger than the minimum heap, and to then measure JVM performance.

 


Recommendation: At one point ### objects were queued for finalization. Using finalizers is not recommended as it can slow garbage collection and cause wasted space in the heap. Consider reviewing your application for occurrences of the finalize() method. You can use IBM Monitoring and Diagnostic Tools - Memory Analyzer to list objects that are only retained through finalizers.

What you should do: Determine if the applications running on the JVM are using the finalize() method. If they are, consider updating the apps to not use the finalize() method.

The number of objects queued for finalization can be visualized by selecting the Line plot tab, then select the Data selector tab, and then check Objects queued for finalization. In this example, the blue line near the top of the chart is the maximum heap size, the line with the saw tooth pattern is the heap usage, and the dark blue line at the bottom are the number of objects queued for finalization.


Recommendation: # global garbage collects took on average ###% longer than the average nursery collect. If you believe this is abnormally high and unacceptable, consider using the Balanced GC policy for applications deployed on a 64-bit platform with a heap size greater than 4GB.

What you should do: Since the recommendation here is to consider using the Balanced GC policy, first determine the current policy. This can be seen on the Report tab. In this example, the policy is gencon. 

 

The GC policy can be changed in the WebSphere admin console by navigating to Servers > Server Types > your_JVM > Java and Process Management > Java Virtual Machines. Set the -Xgcpolicy to balanced, and then restart the JVM for this change to take effect.

 



Add a Comment




We will never share your name or email with anyone. Enter your email if you would like to be notified when we respond to your comment.




Please enter in the box below so that we can be sure you are a human.




Comments