Memory management, auto recover and network settings
-
You must use 64-bit Java! (For 32-bit the heap size limit is 2 GB, which is insufficient.)
-
Previously listed settings now set by the configuration script, are not listed anymore or marked as such.
|
Setting description |
Option entry |
|---|---|
|
|
|
|
Heap size recommendations:
Values from the said range are inefficient because a value ≥ 32 GB switches from 32‑bit addressing to 64‑bit. This causes an overhead and disables an internal tuning mechanism (Compressed Oops). |
|
|
Initial heap size (must be <= maximum heap size) |
-Xms4096m |
|
Maximum heap size |
-Xmx4096m |
|
Use the Garbage-First (G1) Collector |
-XX:+UseG1GC |
|
G1 is usually recommended. Do not use G1 but the concurrent garbage collector if you plan to allocate larger blocks of heap memory for file buffering, e.g. to increase performance. See Garbage collector and related settings “ima.archive.tempFile.inMemoryThreshold...”. |
|
|
Using the concurrent garbage collector as an alternative |
|
|
To use the concurrent garbage collector: |
-XX:+UseConcMarkSweepGC |
|
For example, to set a buffer size of 2 MB: |
-Dima.archive.bufferSize=2097152 |
|
Maximum metaspace size |
‑XX:MaxMetaspaceSize=2048m (optional, but if set, use the value shown here as a minimum) |
|
Metaspace is an important JVM memory area related to class metadata and Java framework internals. By default, since release 9.15.2.4 ImageMaster no longer requires a dedicated maximum metaspace setting. This means that no fixed limit for metaspace needs to be configured in standard installations. However, on servers shared with other mission-critical applications, it can be advisable to define a maximum metaspace size in order to limit memory consumption of the ImageMaster JVM. This is comparable to setting a maximum heap size (-Xmx) to avoid uncontrolled memory usage affecting other applications on the same host. If such a limit is configured, use a sufficiently high value as shown in the examples that refer to MaxMetaspaceSize. Do not configure an unnecessarily low value, because this can lead to performance degradation or runtime failures such as:
Also see: Response time and memory consumption related to metaspace size |
|
|
Reference object processing performance |
-XX:+ParallelRefProcEnabled |
|
Use this setting to increase the general performance. This only works with the G1 garbage collector. |
|
|
Auto recover settings |
|
|
Enable auto recover |
ima.autorecover=true |
|
Enable the auto recover resynchronization processing on one application server at most. Possible values are “true” or “false”. The default value is “true”. In case of a clustered ImageMaster installation (multiple ImageMaster domains sharing a single database), only one node must have auto recover enabled. All other nodes must have this value set to 'false' to avoid concurrent attempts to recover a damaged file. |
|
|
Timeout for recover process |
ima.autorecover.threadTimeout=720 |
|
Set the number of minutes the coordinating auto recover resynchronization processing waits for a worker thread at most to return from processing a packet part. The default value is 720 (12 hours). If the value is -1, the coordinating auto recover processing waits indefinitely for each worker thread. |
|
|
Obligatory settings required for ImageMaster compatibility |
|
|
Disable Lazy Fetch |
org.jboss.weld.context.attributes.lazyFetch=false |
|
If you install ImageMaster with the configuration script according to this manual, this setting is done automatically. The lazy fetch mechanism must be disabled in WildFly/JBoss as it causes conflicts in long running processes such as the ones triggered by an ImageMaster client export. |
|
|
Network settings |
|
|
IPv4 (Internet Protocol version 4) |
-Djava.net.preferIPv4Stack=true |
|
If you host ImageMaster in an IPv4 environment, set this property to “true” to enforce IPv4 (e.g. to avoid network connection issues). Do not set this parameter in an IPv6 environment! |
|
|
Obligatory transaction manager settings |
|
|
Transaction Manager Node ID |
jboss.tx.node.id (The value must be no longer than 23 characters.) |
|
A unique identifier for the WildFly/JBoss transaction manager instance must be defined. In a multi-node environment each application server instance must have a unique value. This applies also when instances use different database schemas (effectively representing different ImageMaster environments) but connect to the same database server. This identifier distinguishes a given server’s transactions from all others and enables correct XA recovery. Once set, this value must not be changed for a server that has pending or in-doubt transactions. Recommended: Pass the value as a JVM system property (e.g., configured in standalone.conf using -Djboss.tx.node.id=<unique-node-id>). Not recommended: Setting it in the <system-properties> section of standalone.xml – the transactions subsystem may initialize before that section is parsed. |
|