We analyzed the data from 2,180 different applications while looking for the answer to these questions:

  • How often do memory leaks occur in Java applications?
  • How big is a memory leak?
  • How quickly does a memory leak grow?

Out of those 2180 applications, Plumbr Agents discovered 754 different memory leaks. As some applications contained several memory leaks, the number of unique applications where a leak was detected was a bit lower – 682 to be precise. Based on this data, we can conclude that 31% of the Java applications contain a heap memory leak. Take this with a grain of salt – we do admit the fact that the applications Plumbr ends up monitoring are more likely to contain a memory leak than the ones we do not monitor.

Now, knowing that you have roughly one in three chances of having a heap memory leak in your application, lets see whether you should be worried about the leaks at all. For this, lets look at two different characteristics we have for these 754 heap memory leaks.

When Plumbr finds a memory leak, it runs a complex calculation to determine the retained size of the leak. Or, in more simpler way – Plumbr calculates how big is the particular leak in megabytes. This data surfaced the following numbers about the leak sizes at discovery:

  •  < 1 MB: 25%
  • 1 - 10 MB: 17%
  • 10 - 100 MB: 28%
  • 100 - 500 MB: 21%
  • 500 - 1000 MB: 5%
  •  > 1000 MB: 4%

From the data we can see that Plumbr detects many leaks at their infancy – for example it has found187 leaks (25% of total leaks) while the leak was still smaller than 1MB at the time of discovery. In the other extreme, some leaks take longer to detect, so in 31 cases the leak was detected only after it had grown to 1GB. The biggest leaks had managed to escalate to 3GB in size before detection.

Another interesting conclusion to draw from the above is that majority of the leaks get caught byPlumbr before the application’s end users feel any impact - 70% of the leaks are still smaller than 100MB at the time Plumbr reports the leak as an incident.

Now, the fact that an application contains a leak occupying less than 100MB is not something to take action upon. Coupling the size of the leak with the velocity of the leak, the severity of the incident becomes more clear:

  • < 1 MB/h
  • 1 - 10 MB/h
  • 10 - 100 MB/h
  • 100 - 500 MB/h
  • > 500 MB/h

The information on the above chart can be interpreted this way: for 6% (37 occurrences) of the cases the leak velocity at the time of discovery was between 100 and 500 MB/hour.

In the extreme cases, we have either very slow or extremely fast leaks. On 398 occasions (53% of the leaks discovered) the leak was escalating at the pace of 1MB per hour or less. At the other end of the spectrum we had 31 leaks escalating at mind-boggling 1GB/hour or faster. The “record holder? in this regard managed to leak more than 3GB per hour.

The original article was posted in Plumbr performance tuning blog, where you can see the full details of the analysis.