2

from time to time jboss serwer throws "An unhandled exception has occurred:

java.lang.OutOfMemoryError: Java heap space".

Could you please explain me how it works?

A few infromation: Jboss is running all the time in standalone mode on Windows. From standalone.conf "JAVA_OPTS=-Xms1G -Xmx1G -XX:MaxPermSize=256M" I deploy ~50MB war file, after tests I remove it.

What is possible cause of this Java heap space exception? Should I restart server between following deploys? Is there any command to clean heap space? If I understand corectly increasing of -Xmx argument will not help. It will only delay the appearance of the exception. Right?

Thanks in advance

SamHoque
  • 2,978
  • 2
  • 13
  • 43
  • You may be having a memory leak in your code. Increasing size will just delay the OOM... Try using some profiler tools to see what is eating your memory and not releasing back – Pushpesh Kumar Rajwanshi Nov 06 '18 at 09:52
  • I dont think it's a memory leak. After restarting serwer everything is good. After some time exception occurs again on completely diffrent build. What is more when I start jboss serwer it eats about 560MB Memory (from task manager), when exceptoin occures occupied memory by this Java process is more than 1.5GB –  Nov 06 '18 at 10:10
  • @TomekKoźlak different build of same app after a restart is not an indicator of there not being a memory leak. i.e. it could still be a memory leak. – Jason Armstrong Nov 06 '18 at 10:59
  • This link may be helpful: https://www.cubrid.org/blog/the-principles-of-java-application-performance-tuning It may or may not be a memory leak. What is the app doing? Is it caching a lot of data? Is it allocating large objects? How many? Is it allocating a lot of small objects? How often do objects survive a newgen collection? What distribution of Java are you using? Are you on 32-bit or 64-bit? Have a look at: https://dzone.com/articles/enabling-and-analysing-the-garbage-collection-log – Jason Armstrong Nov 06 '18 at 11:04
  • *"I dont think it's a memory leak."* - The symptoms you describe are not inconsistent with a memory leak. – Stephen C Nov 07 '18 at 04:52
  • @JasonArmstrong - I would describe an app that caches lots of data in a way that the GC cannot free it when necessary as a memory leak. – Stephen C Nov 07 '18 at 04:53
  • @StephenC potentially poor word choice. Some apps do need lots of memory, some of it is caching, some of it is large objects, some of it is lots of little objects that may/may not need to hang around. The potential here is that it may be a case of the 5 pound bag problem. OP won't know until he profiles it, but it's possible it may just need more memory. – Jason Armstrong Nov 07 '18 at 13:01
  • @JasonArmstrong - Yes. But if the cache component is properly implemented, then it won't be the cause of the OOMEs. The GC should trigger clearing of the cache before an OOME happens. Or to put it another way, a cache that doesn't respond to the GC is effectively a memory leak. – Stephen C Nov 08 '18 at 13:44

3 Answers3

3

What is possible cause of this Java heap space exception?

On the face of it, the explanation is simple. The JVM has run out of heap space, and the GC is unable to reclaim enough space to continue.

But what caused the JVM to get into that state?

There are a number of possible explanations, but they mostly fall into three classes:

  1. Your application has a memory leak.

  2. Repeated deploys are causing memory to leak.

  3. There are no memory leaks, but occasionally your application is getting a request that simply needs too much memory.

Should I restart server between following deploys?

That may help if the deploys are causing the leaks. If not, it won't.

Is there any command to clean heap space?

There is no command that will do this. The JVM will already have run a "full" GC before throwing the OOME.

If I understand corectly increasing of -Xmx argument will not help. It will only delay the appearance of the exception. Right?

That depends. If the root cause is #3 above, then increasing the heap size may solve the problem. But if the root cause is #1 or #2, then tweaking the heap size will (at best) cause the JVM to survive longer between crashes.

My recommendation is to start by treating this as a "normal" (cause #1) memory leak, and use a memory profiler to identify and fix leaks that are likely to build over time.

If / when you can definitively eliminate cause #1, consider the others.

Stephen C
  • 698,415
  • 94
  • 811
  • 1,216
1

I absolutely agree with the answer from Stephen C, i just want to show you a possible way how you can analyse it.

A minimal tool for monitoring the memory is jstat and comes with JDK. After starting JBoss you can start monitoring the memory and GC with

jstat -gc <JBOSS_PID> 2s

The output can then be loaded for example in an excel.

Now when you recognize something strange happens with the memory, take a heap dump:

jcmd <JBOSS_PID> GC.heap_dump <filename>

jcmd also comes with JDK.

You can than load the heap dump into MAT and analyse it. It takes some practice and patience to work with MAT. They also have a good Tutorial. You can also compare heap dumps in MAT.

I also suggest you add XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=<path>" to your JAVA_OPTS.

wirnse
  • 1,026
  • 8
  • 7
0

Please increase the MaxPermSize variable and check it will work.

JAVA_OPTS=-Xms1G -Xmx1G -XX:MaxPermSize=512M

Raheela Aslam
  • 452
  • 2
  • 13
  • 1
    I assume this solution will not help because of this warning on the beginning of logs when serwer starts: Java HotSpot(TM) 64-Bit Server VM warning: ignoring option MaxPermSize=256M; support was removed in 8.0 –  Nov 06 '18 at 10:20
  • you can try this to solve this problem. In JBoss EAP 6.4, right click on the server and open launch configuration under VM argument you will find {-Dprogram.name=JBossTools: jboss-eap" -server -Xms1024m -Xmx1024m -XX:MaxPermSize=256m} update it to {-Dprogram.name=JBossTools: JBoss 6.4" -server -Xms512m -Xmx512m} this will solve your problem. Reference: https://stackoverflow.com/questions/22634644/java-hotspottm-64-bit-server-vm-warning-ignoring-option-maxpermsize – Raheela Aslam Nov 06 '18 at 10:24