Virtual file system (VFS) native memory leak in JBoss EAP 5

Solution Verified - Updated

Environment

  • Red Hat JBoss Enterprise Application Platform (EAP) 5
  • Sun JDK prior to JDK 7
  • IBM JDK 1.6 prior to SR10

Issue

  • Process size grows very fast when JBoss is processing and caching annotations, which utilizes VFS a lot.
  • I have noticed a huge memory consumption by our JBoss EAP 5 instances. In particular I have noticed that a Jboss instance that starts with the memory java parameters set to “-Xmx=4GB” , “- Xms=4GB “ , “-XX:PermSize=512M” and “-XX:MaxPermSize=512M”, gets a memory footprint on Operative System roughly 7GB.
  • The memory footprint for JBoss EAP 5 seems to be significantly higher than the jvm heap configuration and even after taking into account the thread stack and PermGen, the memory consumed is much higher than we envisaged.
  • JBoss is configured to use 8 GiB of Heap. It's also configured to have a maximum of 200 threads, by which default take up a maximum of 512KB of stack. However, it is getting 11 GB of memory being used by JBoss EAP 5, which is very close the maximum system memory and eventually the OS kills it to regain the memory.
    Also, from GC logs, the Heap is not full and only taking up to ~2 GB, so not even close to the 8GiB of memory.

Resolution

This issue is being worked, and a fix will be provided in a future JBoss EAP 5 minor release:

Content from jira.jboss.org is not included.Content from jira.jboss.org is not included.https://jira.jboss.org/browse/JBPAPP-4768

Possible workarounds are:

  1. Use unzipped deployments (exploded deployments) OR
  2. Use the JVM option -Djboss.vfs.forceVfsJar=true to disable the internal zip-usage
    • Set the location -Djboss.vfs.forceVfsJar=true stores the nestedjar*.tmp . It defaults to -Djava.io.tmpdir (/tmp on Linux if undefined)
    • Using jboss.vfs.forceVfsJar=true does cause increased heap usage: Increased heap usage with forceVfsJar set. Monitor garbage collection to see if the heap size needs increasing. Other options to offset the increased heap usage would be reducing the number of deployed jars and removing duplicate jars.
    • Have a script to clear out the -Djava.io.tmpdir directory before each restart ( JBoss does not automatically delete the generated nestedjar* files on restart)

Root Cause

Diagnostic Steps

  • Test with unzipped deployments or use the JVM flag. Does the process size go down?
SBR
Product(s)
Components
Category
Tags

This solution is part of Red Hat’s fast-track publication program, providing a huge library of solutions that Red Hat engineers have created while supporting our customers. To give you the knowledge you need the instant it becomes available, these articles may be presented in a raw and unedited form.