1

We have a java application as a long running service (actual up-time for this JVM 31 days 3 hrs 35 min)

Due to Windows taskmanager the process uses 1,075,384,320 B - nearly one GB.

Heap size of the JVM is restricted to 256 MB (-Xmx256m)

Memory-Data

Memory:
Size: 268,435,456 B
Max: 268,435,456 B
Used: 100,000,000 up to 200,000,000 B

- no leak here

Buffer Pools

Direct:
Count: 137
Memory Used and Total Capacity: 1,348,354 B

Mapped:
Count: 0
Memory Used and Total Capacity: 0 B

- no leak here

my question: where does the JVM uses the additional memory?

Additional informations:

Java: version 1.8.0_74 32 bit (Oracle)

Classes:
Total loaded: 17,248
Total unloaded: 35,761

Threads:
Live: 273
Live peak: 285
Daemon: 79
Total started: 486,282

After a restart it takes some days for the process size to grow, so of course regular restart would help, and maybe using a newer java version also may solve the problem, but I would like to have an explanation for this behaviour, e. g. known bug in 1.8.0 before 111, fixed in ... - I did not find anything, yet.

We use about 350 of such installations in different places so changing is not so easy.

Volker Seibt
  • 1,479
  • 16
  • 19
  • Take a look at the used memory with jvisualvm. You find it in JDK_HOME/bin. You can then count the living instances of your classes. – Tobias Otto Jan 25 '17 at 15:20
  • What do you think where I go the above data? – Volker Seibt Jan 25 '17 at 15:27
  • As you see above loaded classes are 17.248; Metaspace consumes about 58 M. – Volker Seibt Jan 25 '17 at 15:32
  • try https://docs.oracle.com/javase/8/docs/technotes/guides/troubleshoot/tooldescr007.html and (assuming linux) `pmap` – the8472 Jan 26 '17 at 00:15
  • @the8472: thanks for your tip, I also found this toolset. At the moment I'm trying to understand the results. Native Memory Analysis from my current proccess claims to use more memory in total than taskmanager shows. – Volker Seibt Jan 27 '17 at 12:47

2 Answers2

1

Don't forget to run your JVM in server mode on long running tasks!

The reason for this kind of memory leak was the JVM running in client mode. Our solutions runs in a couple of chain stores on old windows xp 32-bit PCs. Default for JVMs on this platform is client mode.

In most cases we run JRE 1.8.0_74-32bit. With our application this JVM leaks memory in "Thread Arena Space" - seems to be nothing returned ever.

After switching to server mode by setting the parameter -server on JVM start the problems disappeared.

Volker Seibt
  • 1,479
  • 16
  • 19
0

There are two common reasons for off-heap memory consumption:

  • Your application or one of the libraries you are using (e.g. JDBC driver) perform something natively (a module invoked via JNI)
  • Your application or one of the libraries are using off-heap memory in other ways, i.e. with direct buffers or with some "clever" use of sun.misc.Unsafe.

You can verify this tracking the native memory usage with jcmd as explained here (you'll need to restart the application).

uraimo
  • 19,081
  • 8
  • 48
  • 55
  • 1
    Buffered Pools (direct or managed) can be monitored by JVisualvm or JConsole (MBeans) - very low memory usage. The `committed virtual memory` in JConsole and the size in the taskmanager matches, so the JVM "knows" the memory it consumes. I've started some of the installations with "native memory tracking" enabled and I'm hopefull to find the memory consuming area this way. – Volker Seibt Jan 30 '17 at 15:45
  • While waiting for my newly started processes to grow large I analysed another already large proccess with VMMap from Sysinternals. There are large blocks (several 300 MB) of "private data" between DLLs. Tomorrow I will do some google-ing for explanations. – Volker Seibt Jan 30 '17 at 17:13
  • Sadly, I'm not familiar anymore with memory management on the Windows platform... – uraimo Jan 30 '17 at 18:42