Posted By: David Faust
We all wish we had more memory from time-to-time. Here are useful techniques for analyzing the memory used by your Java Virtual Machine (JVM).
Finding JVM Heap Size
Find the committed and maximum sizes of the JVM heap in your ctreesql process.
- Run jconsole (found in the JDK’s bin directory).
- In the New Connection dialog box, choose the Local Process entry with the process ID of the ctreesql process and click Connect.
- Select the Memory tab and view the Heap Memory Usage chart. What are the values of the Committed and Max heap sizes that are shown below the graph? In the example below it is “Committed: 59,072 bytes”, which is 59 MB, and “Max: 699,072 kbytes” which is about 699 MB. (Note that even if you click “Perform GC” and the used amount of the heap is reduced, the committed value, which is the actual memory in use by the JVM and not available for other purposes, does not change.)
If you find that the JVM is using a significant amount of memory, FairCom recommends setting smaller initial and maximum JVM heap sizes, with the goal of making more memory available for c‑treeACE SQL use. This is accomplished using the following option in ctsrvr.cfg and restarting c‑treeACE SQL:
This example sets initial and maximum heap sizes to 100 MB each. After setting this option and restarting c‑treeACE SQL, run jconsole again and you should expect to see Committed and Max values are both 100 MB.
Advanced JVM Configuration
The JVM is loaded into c‑treeACE SQL and becomes part of the process when the appropriate configuration options point to a valid Java Runtime Engine (JRE). Stored procedures, triggers, and user-defined functions are executed within this JVM. The JVM environment can be configured and tuned with numerous options. The deployment architect should be familiar with these options from the available Oracle Java documentation.
The SETENV DH_JVM_OPTION_STRINGS configuration keyword can be used to specify exact parameters for the JVM to use at runtime.
Note: Java stored procedures and triggers developers may take advantage of many different Java features and have wide latitude in creating stored procedure logic. Due to this, it is difficult to make general recommendations, however, information and links are provided below to demonstrate the vast variety of options available.
Different options may be available on different platforms as Java is a highly cross-platform environment.
One of the most important considerations is memory usage of the JVM. This can result in unexpected memory usage of the c‑treeACE SQL process. As the JVM gradually allocates additional heap memory, the process space can grow quite unexpectedly. While Java takes advantage of advanced automatic garbage collection of unused memory references, the triggers for this are many, and in some cases, require careful tuning for the best balance of performance and memory use. Two options of immediate use are the minimum and maximum size of the memory heap.
The JVM defaults to certain proportions of available memory, depending on the OS and if the process is 32-bit or 64-bit.
The initial heap size of the JVM is the following:
- Larger of 1/64th of the machine’s physical memory or some reasonable minimum. Before J2SE 5.0, the default initial heap size was a reasonable minimum, which varies by platform.
- If the nursery size (the part of the heap memory reserved for allocation of new objects) is set with –Xns, the default initial heap size will be scaled up to at least twice the nursery size.
You can specify the initial (and minimum) JVM heap size with the -Xms option.
Note: The initial Java heap cannot be set to a value smaller than 8 MB, which is the minimum Java heap size. If you attempt to set it to a smaller value, JVM defaults to 8 MB.
The -Xms value cannot exceed the value set for -Xmx (the maximum Java heap size).
The maximum heap size of the JVM is the following:
- Smaller of 1/4th of the physical memory or 1GB. Before J2SE 5.0, the default maximum heap size was 64MB.
You can specify the maximum JVM heap size with the -Xmx command-line option.
Alternative Garbage Collectors
Alternative garbage collectors (GC) are available within the JVM. For particular environments, it may be advantageous to choose an alternate GC for throughput or latency reasons.
- -XX:+UseParallelOldGC (default)
- -XX:+UseG1GC (New in Java 6 and 7)
Many numerous options are available to tune each of the Java garbage collectors for performance, throughput and low-latency. Check the current Java documentation for your chosen JVM for complete details.
It is frequently necessary to examine actual garbage collection statistics. Java garbage collection has many debugging options available for this task. Here is a minimum set to consider:
The JVisualVM utility included with your Java installation is recommended for advanced monitoring of the Java GC process. Load the Visual GC plugin from the “Tools->Plugins” menu.