Over a million developers have joined DZone.

1 Line Code to Analyze GC Logs

You can use the RESTful API provided by GCEasy to analyze garbage collection logs. Here are a couple of use cases where this API can be extremely useful.

· Performance Zone

Discover 50 of the latest mobile performance statistics with the Ultimate Guide to Digital Experience Monitoring, brought to you in partnership with Catchpoint.

In this modern world, Garbage collection logs are still analyzed in a tedious and manual mode — i.e. you have to get hold of your DevOps team, then they will mail you the application’s GC logs, then you will upload the logs to GC analysis tool, then you have to analyze it. There is no programmatic way to analyze Garbage Collection logs in a proactive manner. Thus to eliminate this hassle, you can use the RESTful API provided by GCEasy to analyze garbage collection logs. With one line of CURL command, you can get your GC logs analyzed instantly.

Here are a couple of use cases where this API can be extremely useful.

Use Case 1: Production Proactive GC Log analysis

Depending on traffic volume in the production environment, your application might be deployed across tens, hundreds, or thousands of JVMs. Because of the above-mentioned tediousness, only selective few JVM’s Garbage Collection logs are analyzed. But the challenge here is that there might only be a subset of JVMs experiencing performance problems or they might exhibit different performance characteristics from the JVM’s GC logs that you analyzed. In those circumstances, those JVM problems will go unnoticed.

With Garbage Collection analysis API, you can analyze GC logs in a proactive manner. On a periodic basis, you can invoke Garbage Collection analysis API to check whether any problem is brewing in the application. Garbage Collection log analysis API reports any vulnerabilities that are currently happening in the application, plus its ML algorithms can even forecast certain types of memory problems that are going to happen in the near future.

Use Case 2: Continuous Integration

As part of continuous integration it’s highly encouraged to execute performance tests. Garbage collection log from this execution can be analyzed using the API.  If API reports any problems, then build can be failed. In this way, you can catch the memory problems and other performance degradation right during code commit time instead of catching it in  or production.

How to Invoke Garbage Collection Log Analysis API?

Invoking Garbage Collection log analysis is an extremely simple:

  1. Register with GCEasy. You will get an email with API key. This is a one-time setup process.
  2. Post HTTP request to http://api.gceasy.io/analyzeGC?apiKey={API_KEY_SENT_IN_EMAIL}
  3. The body of the HTTP request should contain the Garbage collection log that needs to be analyzed.
  4. HTTP Response will be sent back in JSON format. JSON has several important stats about the GC log. Primary element to look in the JSON response is: “isProblem“. This element will have value to be “true” if any memory/performance problems has been discovered. “problem” element will contain the detailed description of the problem.

CURL command

Assuming your GC log file is located in “./my-app-gc.log,” then here is 1 line CURL command to invoke the API:

curl -X POST --data-binary @./my-app-gc.log http://api.gceasy.io/analyzeGC?apiKey=<API-KEY> --header "Content-Type:text"

It can’t get any simpler than that? Isn’t it?

Other Tools

You can also invoke the API using any web service client tools such as SOAP UI, Postman Browser Plugin, etc.

postman

FFig: POSTing GC logs through PostMan plugin

Sample Response

{
  "responseId": "03d4eab6-2070-4081-a1dc-273e213c5175",
  "graphURL": "http://api.gceasy.io/my-gc-report.jsp?p=L2hvbWUvcmFtL3VwbG9hZC9HQ0VBU1kxL3NoYXJlZC8yMDE2LTYtMTgvYXBpLWQwOTRhMzRlLWJkMjItNGMyOC05Njk4LTgxOWUzZDk1MWVhN2JmMjI5NmJhLTk0MDAtNDk1ZC04ZWI1LWM4ZWRkMTU3M2Q3Mi50eHQ=",
  "isProblem": true,
  "problem": [
    "Our analysis tells that your application is suffering from memory leak. It can cause OutOfMemoryError, JVM to freeze, poor response time and high CPU consumption."
  ],
  "jvmHeapSize": {
    "youngGen": {
      "allocatedSize": "1.3 gb",
      "peakSize": "1.3 gb"
    },
    "oldGen": {
      "allocatedSize": "2.67 gb",
      "peakSize": "2.67 gb"
    },
    "permGen": {
      "allocatedSize": "285 mb",
      "peakSize": "214.54 mb"
    },
    "total": {
      "allocatedSize": "3.87 gb",
      "peakSize": "3.64 gb"
    }
  },
  "gcStatistics": {
    "totalCreatedBytes": "6.07 tb",
    "measurementDuration": "29 hrs 15 min 28 sec",
    "avgAllocationRate": "60.38 mb/sec",
    "avgPromotionRate": "284 kb/sec",
    "minorGCCount": "10566",
    "minorGCTotalTime": "3 min 40 sec 168 ms",
    "minorGCAvgTime": "21 ms",
    "minorGCAvgTimeStdDeviation": "6 ms",
    "minorGCMinTIme": "10 ms",
    "minorGCMaxTime": "90 ms",
    "minorGCIntervalAvgTime": "9 sec 755 ms",
    "fullGCCount": "1071",
    "fullGCTotalTime": "37 min 15 sec 829 ms",
    "fullGCAvgTime": "2 sec 88 ms",
    "fullGCAvgTimeStdDeviation": "793 ms",
    "fullGCMinTIme": "100 ms",
    "fullGCMaxTime": "4 sec 920 ms",
    "fullGCIntervalAvgTime": "1 min 38 sec 431 ms"
  },
  "gcDurationSummary": {
    "groups": [
      {
        "start": "0",
        "end": "1",
        "numberOfGCs": 10622
      },
      {
        "start": "1",
        "end": "2",
        "numberOfGCs": 316
      },
      {
        "start": "2",
        "end": "3",
        "numberOfGCs": 565
      },
      {
        "start": "3",
        "end": "4",
        "numberOfGCs": 128
      },
      {
        "start": "4",
        "end": "5",
        "numberOfGCs": 6
      }
    ]
  }
}

JSON Response Elements

ElementDescription
responseIdUnique transaction Id that is generated for every response. This is used for any debugging or diagnosis purposes
graphURLGraphical visualization of the GC log can be found at this location.
isProblemtrue’ is returned if any memory problems are found. ‘false’ is returned if no memory problems are found. This element can be used to build any alerts for proactive GC monitoring
problemDescription of the memory problem is reported in this element. Like what type of memory problem, it is. What are the side-effects and symptoms it might cause
jvmHeapSizeThe data points in this section is gathered from the GC log, thus It may or may not match with the size that is specified by the JVM system properties (i.e. –Xmx, -Xms,…). Say you have configured total heap size (i.e. –Xmx) as 2gb, whereas at runtime if JVM has allocated only 1gb, then in this report you are going to see the allocated size as 1gb only.
youngGen
allocatedSizeYoung Generation’s allocated size (i.e. specified at the JVM level)
peakSizeYoung Generation’s peak utilization size at runtime
oldGen
allocatedSizeOld Generation’s allocated size (i.e. specified at the JVM level)
peakSizeOld Generation’s peak utilization size at runtime
metaSpace
allocatedSizeMetaspace’s allocated size (i.e. specified at the JVM level)
peakSizeMetaSpace’s peak utilization size at runtime
permGen
allocatedSizePerm Generation’s allocated size (i.e. specified at the JVM level)
peakSizePerm Generation’s peak utilization size at runtime
total
allocatedSizeTotal allocated heap size (i.e. specified at the JVM level) includes Young + Old + Perm (or Metaspace)
peakSizePeak utilization of the heap size at runtime
gcStatisticsGC statistics summary is based on ‘real’ time reported in the GC Logs. For more details on difference between user, sys, real time refer to https://blog.gceasy.io/2016/04/06/gc-logging-user-sys-real-which-time-to-use/
totalCreatedBytesTotal amount of objects created by the application
measurementDurationTotal time duration application has been running
avgAllocationRateObjects creation rate by the application. When more objects are allocated, young generation gets filled up quickly, and Minor GC runs more frequently.
avgPromotionRateObjects promoted rate from Young Generation to Old Generation. When more objects are promoted to Old generation, Full GC will be run more frequently.
minorGCCountNumber of Minor GCs occurred in the application
minorGCTotalTimeTotal time spent in Minor GCs
minorGCAvgTimeAverage time taken by the Minor GCs (i.e. total time taken by all minor GCs / number of minor GCs)
minorGCAvgTimeStdDeviationStandard Deviation of the Minor GC average times
minorGCMinTImeMinimum Time of all the minor GCs
minorGCMaxTimeMaximum time of all the minor GCs
minorGCIntervalAvgTimeAverage time interval between minor GCs
fullGCCountNumber of Full GCs occurred in the application
fullGCTotalTimeTotal time spent in Full GCs
fullGCAvgTimeAverage time taken by the Full GCs (i.e. total time taken by all full GCs / number of full GCs)
fullGCAvgTimeStdDeviationStandard Deviation of the Full GC average times
fullGCMinTimeMinimum Time of all the full GCs
fullGCMaxTimeMaximum time of all the full GCs
fullGCIntervalAvgTimeAverage time interval between Full GCs
gcDurationSummary
groupsArray of GC Duration summary group. Example of a group:
{
“start”: “0.2”,
“end”: “0.3”,
“numberOfGCs”: 5
}, Indicates that 5 GCs completed between 0.2 second and 0.3 seconds
startGroup’s start time reported in seconds
endGroup’s end time reported in seconds
numberOfGCsNumber of GCs that completed between ‘start’ time and ‘end’ time
gcCausesarray  reporting the GC Causes
causeThe reason which triggered the GC. Values could be: Concurrent Mode Failure, Allocation Failure, System.gc() calls
countNumber of time GC occurred because of this reason
commandLineFlagsJVM arguments that were passed to the application

Best Practice: Building alerts

For production monitoring or for performance tests, you can build alerts around the JSON response.

  1. If “isProblem” element has value to be “true” then alert can be generated with the content from “problem” element.

  2. You can also setup thresholds on the elements like: “fullGCCount”, “fullGCTotalTime”, “fullGCAvgTime”, “fullGCAvgTimeStdDeviation”, “fullGCMinTIme”, “fullGCMaxTime”,
    “fullGCIntervalAvgTime”. If any these elements value exceeds your threshold then alerts can be triggered.

Is your APM strategy broken? This ebook explores the latest in Gartner research to help you learn how to close the end-user experience gap in APM, brought to you in partnership with Catchpoint.

Topics:
java ,jvm ,garbage collection ,performace

Opinions expressed by DZone contributors are their own.

The best of DZone straight to your inbox.

SEE AN EXAMPLE
Please provide a valid email address.

Thanks for subscribing!

Awesome! Check your inbox to verify your email so you can start receiving the latest in tech news and resources.
Subscribe

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}