quinta-feira, 22 de janeiro de 2015

webMethods and other servers Java Memory Settings

The purpose of this entry is to identify the meaning of the java memory settings for the IS services/processes.

Java heap refers to the volatile part of the memory, in the context of the wM IS documents instances or service execution and other IS objects will use this part of the memory. By definition
The Java heap is where the objects of a Java program live. It is a repository for live objects, dead objects, and free memory. When an object can no longer be reached from any pointer in the running program, it is considered "garbage" and ready for collection.
and IS is very large Java program dedicated to real time message processing which means it has a very dynamic a continuously reshaping memory structure.

Has specified in the documentation Java Heap can be set in the setenv.bat/sh and there are two parameters:


JAVA_MIN_MEM  -> Defaults to 256MB

JAVA_MAX_MEM  -> Defaults to 1024MB 

The JAVA_MIN_MEM is the memory that IS is starts with, and that will be the reference to calculate the heap space available at each GC (GC) iteration.

The JAVA_MAX_MEM refers to max memory the IS will use before triggering the garbage collector.


  • Why not to keep this values the same?
If this values are the same then the JVM will have a constant value for the heap memory, the disadvantage of this is that the GC takes more time to collect the death objects the bigger the heap is, in the limit IS might become irresponsive.

Lower heap might conduct to shorter GC while big heaps can lead to longer GC but less frequent.

Why not to keep JAVA_MIN_MEM to zero?

Because it takes resources to increase the heap size, the configuration as suggested is to use the lowest required memory at any time by the IS for the JAVA_MIN_MEM, and the biggest to the JAVA_MAX_MEN.



There is another memory component, the perm or permanent space, this is were the .class files are stored, it is the object factory that allows the generation of the instances used during runtime. 


By analogy you can compare heap space to the RAM in you're computer and the perm space to the hard drive. In wM terms I would say heap space is for run time memory requirements while perm space is related to services/documents/processes design.

The total amount of memory used in the OS will be the sum of 3 components, java heap + java perm + other (which is the smaller portion and is mostly related to JVM internal requirements to keep the java engine running).



  • Finally, why do we get the following errors?


  1. Out of memory error:java perm space
  2. Out of memory error:java heap space



1 Is quite easy to assert and you might see it happen on the wM IS env if you keep the default settings, as one build more packages and services, the available perm memory will be less and less at each new development until at last the space available to allocate new classes is not enough and we get the error number 1.

2 Is a bit more complex, the error is thrown when the garbage collector is unable to free up enough space to allow allocation to the requested object.

So basically when a new object is to be created and there is not enough space in the heap, the jvm will invoke the garbage collector. If after the gc completion, there is still not enough space freed up, then the jvm throws an OutOfMemoryError: java heap.

In highly inaccurate but comprehensive description if you have capacity to run 1000 IS services instances, when the heap reaches the 1000 services the GC will be started, if only 100 services instances are cleared and there are 200 in the queue voilá you have a java singularity :p and the error number 2 is triggered.

That's all good luck with you're machines tuning and will appreciate comments ;)

Some references:
Official wM documentation of course ;)
https://plumbr.eu/outofmemoryerror/java-heap-space
http://www.yourkit.com/docs/kb/sizes.jsp
http://www.coderanch.com/how-to/java/InvestigateOutOfMemoryError
http://www.coderanch.com/t/537313/Performance/java/memory-error-java-heap-space

1 comentário: