Chapter 8. Postinstallation Configuration

Memory Settings
Maximum Number of Open Files
Maximum Number of Processes or Threads
Firewall Exceptions

Memory Settings

Current implementation of Java Virtual Machine allows only a global configuration of memory for the JVM system process. Thus the whole application server, together with WARs and EARs running on it, share one memory space.

Default JVM memory settings is too low for running an application container with CloverDX Server. Some application servers, like IBM WebSphere, increase JVM defaults themselves, however they still may be too low.

The optimal memory limits depend on many conditions, i.e. transformations which CloverDX should execute. Please note that the maximum limit isn't the amount of permanently allocated memory, but limit which can't be exceeded. If the limit is exhausted, the OutOfMemoryError is raised.

JVM Memory Areas

JVM memory consists of several areas: heap memory, PermGen space, direct memory and stack memory. Since JVM memory is not just HEAP memory, you should not set the HEAP limit too high; in case it consumes whole RAM, JVM won't be able to allocate direct memory and stack for new threads.

Table 8.1. JVM Memory Structure

Heap memory

Heap is an area of memory used by JVM for dynamic memory allocation. Required heap memory size depends on various factors (e.g. complexity of graphs, number of graphs running in parallel, type of component, etc.), see the respective server container's installation guide in this documentation. (Note that current heap memory usage can be observed in CloverDX Server Console.)

PermGen Space Permanent Generation - separate memory space containing class definitions and related metadata. (PermGen was removed from Java 8.)
Direct MemoryMemory used by graph edges and buffers for I/O operations.
Stack Memory Stack Memory contains local, method specific variables and references to other objects in the method. Each thread has its own stack; therefore, the memory usage depends on the number of components running in parallel.

Configuring Memory

You can set the minimum and maximum memory heap size by adjusting the "Xms" and "Xmx" JVM parameters. There are more ways to change the settings depending on the used application container.

Recommended Server Core and Worker Heap Memory Configuration

Optimal distribution of main memory between Server Core and Worker depends on nature of executed tasks. The recommended defaults of Server Core heap size and Worker heap size for different RAM sizes are in the table below.

Heap limit is not a limit of the full memory used by JVM. JVM uses memory in addition to the heap size for other memory spaces, e.g. direct memory. We recommend to set the heap limit to no more than 80% of system memory size, to leave space for the operating system and other JVM memory spaces.

Table 8.2. 

RAM SizeServer Core HeapWorker HeapRemaining for OS (estimated)
4 GB1 GB1 GB1 GB
8 GB2-3 GB2-3 GB2 GB
16 GB4 - 8 GB4 - 8 GB4 GB
32 GB4 - 8 GB16 - 20 GB8 GB
64 GB4 - 8 GB42 - 52 GB8 GB

Memory Configuration in Java 8

In Java 8, the memory space for loading classes (so called "Metaspace") is separated from heap, and can be set by the JVM parameter -XX:MaxMetaspaceSize. The default maximum Metaspace size is unlimited.

Please see the specific container section for details on memory settings.


We recommend you to put limit on metaspace memory. Add -XX:MaxMetaspaceSize=size to command line parameters of Server Core or Worker. Replace size with a suitably high limit. 512MB should be enough.


Direct memory

To avoid excessive usage of direct memory, we add -Djdk.nio.maxCachedBufferSize=262144 to command line of Worker. We recommend you to add this system property also to the command line of Server Core. This system property is available since java 1.8.0_102.

In Apache Tomcat, add this system property to JAVA_OPTS environment variable, which is configured in bin/ file.

Codecache Size

Some CloverDX Server installations can occasionally run into performance issue: JVM is running more than hundred times slower. The issue can be caused by a full code cache (Java SE Embedded: Developer's Guide - Codecache Tuning). The reserved code cache size is platform dependent and can be too small for CloverDX Server. It is highly recommended to increase the code cache size using the following JVM argument:


Maximum Number of Open Files

When using resource-demanding components, such as FastSort, or when running a large number of graphs concurrently, you may reach the system limit on simultaneously open files. This is usually indicated by the Too many open files exception.

The default limit is fairly low in many Linux distributions (e.g. 4096 in Ubuntu). Such a limit can be easily exceeded, considering that one FastSort component can open up to 1,000 files when sorting 10 million records. Furthermore, some application containers recommend increasing the limit themselves (8,192 for IBM WebSphere).

Therefore, it is recommended to increase the limit for production systems. Reasonable limits vary from 10,000 to about 100,000 depending on the expected load of CloverDX Server and the complexity of your graphs.

The current limit can be displayed in most UNIX-like systems using the ulimit -Sn command.

The exact way of increasing the limit is OS-specific and is beyond the scope of this manual.

Maximum Number of Processes or Threads

If you run graphs with many subgraphs containing many components, you may reach the limit on number of threads per user or per system. In this case, you can find java.lang.OutOfMemoryError: unable to create new native thread in graph's log.

The current limit on number of processes/threads per user can be displayed in most UNIX-like systems using the ulimit -Su command. Note that the documentation on ulimit may not distinguish between processes and threads. The limit on number of threads per system can be displayed using the sysctl kernel.threads-max command. The exact way of increasing the limit is OS-specific and is beyond the scope of this manual.

Firewall Exceptions

In order to function properly, CloverDX Server requires an outside communication. The table below describes both incoming and outgoing communication of CloverDX Server. Please, configure your firewall exceptions accordingly.

Table 8.3. Firewall Exceptions

TrafficCommunicationDescription & Components
IncomingHTTP(S)Communication between Designer and Server
JMXTracking and debugging information
Outgoing (depending on an actual usage)JDBCConnection to databases (DBInputTable, DBOutputTable, DBExecute)
MX Receiving and sending JMS messages (JMSReader, JMSWriter, JMS Listener)
HTTP(S) Requesting and receiving responses from servers (Readers, WebserviceClient, HTTPConnector)
SMTPSending data converted into emails (EmailSender)
IMAP/POP3Receiving emails (EmailReader)
FTP/SFTP/FTPS:Remote file reading and writing (readers, writers)

Garbage Collector for Worker

We recommend using the G1 garbage collector for Worker, as it behaves better on huge heaps and causes shorter full stops of the Java Virtual Machine. G1 is the default garbage collector in Java 9 or newer; however, for Java 8 the Parallel garbage collector is the default and G1 is just optional. Because of that, CloverDX automatically enables G1 garbage collector for Worker on Java 8.

If worker.javaExecutable is not specified and no specific garbage collector is selected by the worker.jvmOptions property, CloverDX uses the G1 garbage collector on Worker by default on Java 8. So if you modify the JVM used by Worker, we don't set G1 by default. Also, if you specify a different garbage collector, we don't override this setting.

Selecting Garbage Collector

Java 8 uses the Parallel garbage collector by default, which we override for Worker to use the G1 garbage collector. If you wish to use a different garbage collector than G1 for Worker, then it must be specified by adding the -XX:+UseParallelGC (for Parallel GC) command line option for the Worker's JVM using the worker.jvmOptions property.


Continue with:  Chapter 14, System Database Configuration