Tchater maintenant avec le support
Tchattez avec un ingénieur du support

Foglight 7.1.0 - 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 Store and Forward Processing Appendix: Performance Health Check Appendix: Analyzing a Support Bundle

-Xss

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.

Examples:

-Xss=512k

-Xss=1m

Default

-Xss=256k

Recommendation

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.

 
Table 1. Common Symptoms and Tuning Resolutions
Symptoms
Diagnosis/Verification
Tuning
•
The browser interface is intermittently slow.
•
Data is missing or incomplete.
•
The Server dashboard shows large spikes in heap memory utilization.
•
The server logs show that the server is discarding data during garbage collection.

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
SweepGC switch.

NOTE: In Foglight 5.2.3 and later, a concurrent low-pause garbage collector is enabled by default.

 

•
Data is missing or incomplete.
•
The Server dashboard shows consistently high heap memory utilization (80 percent or more).
•
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.

NOTE: Double any assumptions about memory requirements when running on a 64-bit operating system.

 

•
On a 32-bit Windows® operating system, the server logs show java.lang.OutOf
Memory errors.
•
On a 32-bit Windows operating system, the server logs show java.lang.OutOf
MemoryError:unable to create new native thread.

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.

•
On a 32-bit Windows operating system, the server fails to start with more than 0.8/1GB of heap, but other JavaTM applications start normally.
•
On a 32-bit Windows operating system, the server output displays a ‘Could not reserve enough space for object heap’ message.

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.

Figure 1. Performance Overview dashboard

 

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

To 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 5.7.5.1.
1
Open <foglight_home>/config/server.config.
2
Locate the server.vm.option0 line and change the cache size, as needed:
server.vm.option0 = "-XX:ReservedCodeCacheSize=512m";
3
Restart the Management Server.

 

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.

•
Initial Database Configuration Settings
•
MySQL Tuning
•
Oracle Tuning
•
Microsoft SQL Server Tuning
•
PostgreSQL Tuning
•
Troubleshooting
Documents connexes

The document was helpful.

Sélectionner une évaluation

I easily found the information I needed.

Sélectionner une évaluation