Chat now with support
Chat with Support

Foglight for Virtualization Enterprise Edition 8.9 - Performance Tuning Field Guide

Overview Hardware and Operating System Tuning Management Server Tuning Java Virtual Machine Tuning Backend Database Tuning High Availability (HA) Tuning Agent Tuning Appendix: Performance Health Check Appendix: Analyzing a Support Bundle


This switch specifies the thread stack size of the memory allocation pool. The value must be a multiple of 1024. Append the letter k or K to indicate kilobytes, m or M to indicate megabytes, or g or G to indicate gigabytes.





The stack size should not be changed unless a specific problem (stack overflow) has been identified by Quest Support.

Common Symptoms and Tuning Resolutions

The following table provides common Foglight® performance issues and tuning that resolves those issues.

The JVM is configured to invoke the garbage collector only when heap utilization reaches an upper threshold. Consequently, to operate, the garbage collector must suspend the application. In this particular deployment, it would be suitable to have a concurrent garbage collector.

Check to see if a concurrent garbage collector is enabled. If not, enable one using the
- XX:+UseConcMark


The server logs show java.lang.OutOf
Memory errors

By default, Foglight acquires 75% of the available physical memory (up to a maximum of 1 GB on a 32-bit operating system).

These symptoms usually occur when the size of queued information and cached information combined exceeds the allocated memory size, and therefore the server cannot operate as expected.

Increase the maximum heap size using the -Xmx switch, and consider switching to a 64-bit operating system.


On a 32-bit Windows® operating system, the server logs show java.lang.OutOf
Memory errors.

By default, Foglight acquires 75% of the available physical memory (up to a maximum of 1 GB on a 32-bit operating system).

If too much memory is allocated by the server, then there is not enough address space available for other operations, such as creating a new thread or starting a child process.

Consider reducing the memory allocated by Foglight using the
-Xmx1G switch.

Alternatively, consider reducing the amount of memory allocated per thread using the
-Xss=512k or -Xss=256k switch.

Foglight’s launcher process utilizes Java DLLs, instead of running java.exe as run.bat does. Internal memory parameters such as ‘size of contiguous free memory’ or ‘memory layout’ can lead to related problems and/or limitations.

Customers who plan to have memory requirements that are greater than 800 MB should consider running Foglight on a 64-bit operating system.

JVM Code Cache

Native code runs faster than the equivalent JavaTM code.

The JVM maintains a Java code cache from which native code can be generated. In a large environment running a number of cartridges, this code cache may approach its maximum (though this will taper off eventually). If the code cache is filling up, this results in a decreasing Compilation Time Delta JVM metric.

Use the Performance Overview dashboard (Dashboards > Foglight > Diagnostic > Performance) to check the status of the code cache.


To optimize code execution in larger environments, you can increase the size of the JVM code cache.

NOTE: The default code cache size has been changed to 256m since the Foglight Management Server version
Open <foglight_home>/config/server.config.
Locate the server.vm.option0 line and change the cache size, as needed:


Backend Database Tuning

Foglight® Management Server stores the topology model and observations in the backend database, and it retrieves potentially large amounts of data out of the database when it is asked to by the rules or browser interface. If the database does not perform well, the Management Server slows down as a result. The symptoms of this slow down can vary from general user interface sluggishness to the loss of observations. A properly tuned backend database helps the Management Server run smoothly.

Related Documents