JVM Configuration Denodo 7.0 , Denodo 6.0 , Denodo 5.5 , Denodo 5.0
Denodo Virtual DataPort server is a java application running on a Java Virtual Machine. As such, its launch scripts can be modified to specify parameters that could help improve performance in a particular scenario.
Such launch scripts are located inside the platform installation folder, under the bin/ subfolder. In particular, the launch script for the Virtual DataPort server is vqlserver.bat in Windows environments or vqlserver.sh for Unix systems.
By default, this script specifies the following JVM options:
- -mx1024m: maximum size of JVM heap, equivalent to the maximum amount of memory the JVM will be allowed to use. A value of 1Gbyte is here expressed as 1024m.
- -XX:MaxPermSize=256m: maximum size of the PermGen region in the JVM heap, used by certain types of objects created during the execution of applications.
These two configuration parameters can be easily changed in the Denodo Control Center (“Configure” > “JVM Options”).
If the Denodo Platform is installed on an environment without graphical interface, these parameters be modified editing in the configuration file of Virtual Data Port (<DENODO_HOME>/conf/vdp/VDBConfiguration.properties) the following property:
Once the configuration file has been updated, you have to execute the <DENODO_HOME>/bin/regenerateFiles.sh script in order to propagate the changes in the startup scripts. After the execution of this script, the next time a server or a tool is started, it will use the new JVM startup options.
Note: these modifications are finally applied to the startup scripts (vqlserver.bat or vqlserver.sh), but these files should never be modified directly. Installing a new update can modify these files automatically and therefore the startup options could be overwritten.
Recommended settings for the JVM when Denodo Platform needs to deal with huge datasets
If Denodo needs to deal with huge datasets, the recommendation is to use a 64-bit JVM and increase the default heap space (which is 1024Mb). We recommend starting with 4096Mb. If with this heap size, swapping is still needed for some queries, and there is available memory in the machine, the administrator can try to increase it.
In order to know the maximum amount of memory we can assign, we have to check the amount of physical memory available before launching Denodo Virtual DataPort (VDP). Do not assign all the available memory to VDP. Leave at least around 300 / 400 Mb free. Think about whether there will be more processes running on the machine at the same time as VDP, and if they will use more memory in the future.
Important note: Do not assign more memory than what it is available. Otherwise, the OS will have to swap the memory of other processes to disk and the performance of the machine and all its processes will decrease.
Important note: If the server is running in a virtual machine, try to guarantee that the memory assigned to that virtual machine is actually reserved for it (that is, the allocated memory cannot be used by other virtual machines, even when VDP is not using it). If this is not possible, be conservative in setting the size of the allocated heap size to avoid the OS swapping to disk.
Note: If we assign less than 1.4 Gb to VDP’s heap, we must use a 32-bit JRE. By using a 64 bits, performance will be hurt, as every object will cost twice as much to address.
Use a 64-bit JVM only if the size of the heap is 1.4 Gb or bigger.
Recommended settings for the JVM in memory-demanding scenarios
Note that for a batch queries scenario where pauses caused by the garbage collector do not represent a problem for the functionality of the system it is not recommended to use a heap size greater than 16 Gb. This configuration assigns 8 Gb to the JVM's heap:
-server -Xms8192m -Xmx8192m -XX:+DisableExplicitGC -XX:+UseConcMarkSweepGC -XX:NewRatio=4 -XX:ReservedCodeCacheSize=256m
For Denodo versions previous to 7.0, the following recommendation can be used to assign 8 Gb to the JVM’s heap:
-server -Xms8192m -Xmx8192m -XX:MaxPermSize=256m -XX:+DisableExplicitGC -XX:+UseConcMarkSweepGC -XX:NewRatio=4 -XX:ReservedCodeCacheSize=256m
Recommended settings for the JVM in real time scenarios
For a scenario where real time queries are being executed it is not recommended to use a heap size greater than 8 Gb. With larger heap sizes the execution of the garbage collector can last a long time (even minutes) and it will affect the response time when the garbage collector is running if the heap size is larger than 8 Gb. For very quick queries returning only a few rows the following configuration is recommended:
-server -Xms4096m -Xmx4096m -XX:+DisableExplicitGC -XX:+UseConcMarkSweepGC -XX:NewRatio=4 -XX:CMSInitiatingOccupancyFraction=60 -XX:ReservedCodeCacheSize=256m
-server -Xms4096m -Xmx4096m -XX:+DisableExplicitGC -XX:NewRatio=4 -XX:+UseG1GC -XX:MaxGCPauseMillis=1000 -XX:ReservedCodeCacheSize=256m
Use the following configuration for Denodo versions previous to 7.0:
-server -Xms4096m -Xmx4096m -XX:MaxPermSize=256m -XX:+DisableExplicitGC -XX:+UseConcMarkSweepGC -XX:NewRatio=4 -XX:CMSInitiatingOccupancyFraction=60 -XX:ReservedCodeCacheSize=256m
-server -Xms4096m -Xmx4096m -XX:MaxPermSize=256m -XX:+DisableExplicitGC -XX:NewRatio=4 -XX:+UseG1GC -XX:MaxGCPauseMillis=1000 -XX:ReservedCodeCacheSize=256m
Explanation of these settings:
- -server: with this option, the JVM and its Garbage Collector (GC) are configured to run server applications. That means that the default values of the JVM and its Garbage Collector (GC) will be oriented to execute server-class applications. Server-class applications have different needs than client applications. For example, client applications need faster startup times than server ones even if in the end, the throughput is slightly worse.
- -Xms and -Xmx
- -Xms: amount of allocated memory. Allocated memory is fully backed by physical memory.
- -Xmx: amount of reserved memory. The JVM announces the OS that at some point, it may request this amount of memory, but it does not need it yet. The reserved memory can be used by other processes while is not allocated by the JVM.
- Both parameters should have the same value in server-class applications. When the JVM is launched, it allocates a region of memory with size -Xms and, if needed, it requests more memory to the operating system (OS), until it reaches the -Xmx limit. Allocating more memory for the JVM is a rather expensive operation because the JVM memory has to be contiguous and if there is not any contiguous space, the OS has to swap the memory used by other processes until it obtains a region with the requested size. This process can even lead to swapping the memory of some processes to disk.
- In server-class applications it is a good idea to put the same value to -Xms and -Xmx because eventually, the memory used by the JVM will grow to the top size (-Xmx). The boot process may be slightly slower (we are talking about a difference in seconds) because it has to allocate more memory, but in the end it will result in a performance gain. The reason is that DataPort will not have to request any more memory to the O.S during the execution.
- -XX:MaxPermSize: Top size of the Permanent Generation of the JVM's heap. Note that it is not included in Denodo 7.0, since Denodo 7.0 uses Java 8 and this JVM parameter is no longer supported in Java 8.
- -XX:+UseConcMarkSweepGC: The JVM uses the Concurrent Mark-Sweep (CMS) GC. Sun's JVM has different algorithms of GC and this is the most appropriate one for server-class applications.
- -XX:+DisableExplicitGC: The JVM ignores all invocations to System.gc() from the code. The JVM still performs garbage collection when necessary.
It is usually a good idea to enable this option because a developer of an external jar (i.e.: custom wrapper, stored procedure, …) loaded into Virtual DataPort can invoke a System.gc() to free some memory. However, this may force the GC to start collecting garbage even when there is enough free space in the heap. This can even lead to serious performance issues, especially if Virtual DataPort is receiving many simultaneous requests.
- -XX:-ReduceInitialCardMarks (Only Denodo 4.6). This option is not documented, so we do not know what it does. It is a workaround for a bug present in the CMS collector in the JVM 6 Update 18 and earlier.
- -XX:NewRatio : Ratio of new/old generation sizes. The default value is 2. NewRatio is the ratio between the “Young Generation” (eden + survivor spaces 1 and 2) y “Old Generation”. If NewRatio=4 and total heap size is 500, “Young Generation Size” would be 100 and “Old Generation Size”=400.
- -XX:ReservedCodeCacheSize (Denodo 5.5, 6.0 and 7.0): This parameter defines the size of the region of the heap in which the JVM stores compiled native code.
- -XX:CMSInitiatingOccupancyFraction=<value> (Denodo 5.5, 6.0 and 7.0): Informs the JVM when the CMS should be triggered. It allows to create a buffer in the heap that can be filled with data while the CMS is working. The value is expressed as a percent and it should be calculated based on the speed in which memory is consumed in the old generation space during the expected load. -XX:CMSInitiatingOccupancyFraction should be set to 60, which means that the CMS cycle will start when a 60% of the old generation size is used.
- -XX:+UseG1GC (Denodo 5.5, 6.0 and 7.0): tells the JVM to use the G1 Garbage collector.
- -XX:MaxGCPauseMillis (Denodo 5.5, 6.0 and 7.0): sets a target for the maximum GC pause time. This is a soft goal, and the JVM will make its best effort to achieve it.
Note: These notes are specific to the Sun/Oracle JVM. Differences in configuration when using other JVMs such as IBM's or jRockit to appear in this space as they are determined.