Introduction

The use of Java Options depends on the Java release in use.

  • Typically earlier Java releases include features that are not active by default.
  • Such features can be active by default in later releases.

For further information refer to the JS7 - How To - Apply Java Options article,

Heap Size

Heap size depends on memory consumption of each JS7 product which is related to:

  • the number of parallel users working with JOC Cockpit,
  • the number of workflows deployed to Controllers and Agents,
  • the number of parallel tasks,
  • the maximum outage duration that is assumed for the connection between Agent and Controller as well as for the connection between Controller and JOC Cockpit..

For more details see JS7 - Sizing.


Specify minimum and maximum heap size for JOC Cockpit with Unix
# Default value
JAVA_OPTIONS="-Xms128m -Xmx500m"
Specify minimum and maximum heap size for JOC Cockpit for Windows
@rem Default value
set JAVA_OPTIONS=-Xms128m -Xmx500m

Explanation:The JOC Cockpit can be operated initially with 128 MB heap size i.e. -Xms128m.

  • Heap size can grow up to the specified maximum -Xmx500m based on performance indicators such as:
    • the number users working with JOC Cockpit,
    • the number of inventory items such as workflows, schedules etc.
  • The above values should work for approx. 10 concurrent users.


Specify minimum and maximum heap size for Controllers with Unix
# No Default value

# Recommended: limit initial and max. heap size
JAVA_OPTIONS="-Xms500m -Xmx1g"
Specify minimum and maximum heap size for Controllers with Windows
@rem No Default value

@rem Recommended: limit initial and max. heap size
set JAVA_OPTIONS=-Xms500m -Xmx1g

Explanation:

  • The Controller can be operated initially with 500 MB heap size i.e. -Xms500m.
  • Heap size can grow up to the specified maximum -Xmx1g based on performance indicators such as:
    • the number of workflows deployed to the Controller,
    • the max. failure time for which the Controller is not connected to JOC Cockpit.
  • The above values should work for approx. 10 000 workflows with a max. failure time of 24 hours.


Specify minimum and maximum heap size for Agents with Unix
# Default value
JAVA_OPTIONS="-Xms100m"

# Recommended: limit initial and max. heap size
JAVA_OPTIONS="-Xms100m -Xmx1g"
Specify minimum and maximum heap size for Agents with Windows
@rem Default value
set JAVA_OPTIONS=-Xms100m

@rem Recommended: limit initial and max. heap size
set JAVA_OPTIONS=-Xms100m -Xmx1g

Explanation:

  • The Agent can be operated initially with 100 MB heap size i.e. -Xms100m.
  • By default no maximum heap size is assigned - that is, the Agent will be assigned the heap size calculated by Java when starting the Java Virtual Machine.
  • Heap size can grow up to the specified maximum -Xmx1g based on performance indicators such as:
    • the number of workflows deployed to the Agent,
    • the number of parallel tasks executed with the Agent,
    • the max. failure time for which the Agent is not connected to a Controller.
  • The above values should work for approx. 10 000 workflows with a max. failure time of 24 hours.

Threads

JS7 products make use of multithreading which is dynamically assigned according to the available CPU cores.

The JOC Cockpit requires the thread stack size to be set as some Linux distributions such as Ubuntu tend to modify the JDK's default values. 


Specify thread stack size for JOC Cockpit with Unix
# Default value
JAVA_OPTIONS="-Xss=4000kb"
Specify thread stack size for JOC Cockpit with Windows
@rem Default value
set JAVA_OPTIONS=-Xss=4000kb

Explanation:

  • If a StackOverflowError exception is raised then the stack in use is larger than the thread stack size and suggests that the thread stack size should be increased.
  • if an OutOfMemoryError exception is raised then the stack is larger then the available memory and suggests that the thread stack size should be decreased.

Garbage Collector

The Java Garbage Collector has to be operated in a performant and efficient way as otherwise memory will remain blocked by unused objects.


Activate G1 Garbage Collector with Unix
# Recommended: use G1 Garbage Collector
JAVA_OPTIONS="-XX:+UseG1GC"
Activate G1 Garbage Collector with Windows
@rem Recommended: use G1 Garbage Collector
set JAVA_OPTIONS=-XX:+UseG1GC

Explanation:

  • It is recommended that the G1 Garbage Collector is activated.
  • This applies to Java releases 1.8 to 11. For Java 17 the default Garbage Collector is G1.
  • This option is applicable for JOC Cockpit, Controller and Agents.

String Deduplication

Strings held in memory can be managed more efficiently by the JVM if a string is available just once and is referenced from a number of occurrences.


Activate String Deduplication with Unix
# Recommended: activate string deduplication
JAVA_OPTIONS="-XX:+UseStringDeduplication"
Activate String Deduplication with Windows
@rem Recommended: activate string deduplication
set JAVA_OPTIONS=-XX:+UseStringDeduplication

Explanation:

  • String deduplication reduces memory consumption.
  • This option is applicable for JOC Cockpit, Controller and Agents.

Entropy Pool Settings

The entropy pool is used to retrieve random numbers which are required to secure connections to the JS7 - Database and to a JS7 - Credential Store.

This setting can be applied if the Java version in use is configured to use the /dev/random entropy pool which shows a blocking behavior when randomness is exhausted. This results in substantial delays and errors when accessing a database or Credential Store. Switch to a source of randomness with non-blocking behavior by using the following Java option:


Set entropy pool with Unix
# Recommended: specify non-blocking entropy pool if not specified by java.security file
JAVA_OPTIONS="-Djava.security.egd=file:///dev/urandom"
Set entropy pool with Windows
@rem Recommended: specify non-blocking entropy pool if not specified by java.security file
set JAVA_OPTIONS=-Djava.security.egd=file:///dev/urandom

Note:

Further Resources