立即与支持人员聊天
与支持团队交流

Foglight 5.9.1 - 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

Canonical Data Transformations (CDTs)

Theoretically, CDTs can be a performance bottleneck. Unfortunately, it is not easy to tune them. In most cases, a cartridge update is required.

CDTs convert data received from agents into the server’s internal representation (that is, into the Canonical Data Form). Although this process is usually fast, it can be computation-intensive and therefore may cause performance issues.

The server is generally slow overall.

The CDT transformTime metrics are high. Typical values for OS Cartridge agents are in the 0.01 - 0.1 second range, in 15-minute intervals.

CDT transformTime metrics can be accessed through the browser interface by going to Dashboards > Configuration > Data > Foglight > All Data > AllTypeInstances > TopologyObject > subTypes > CanonicalDataTransform > instances > ... > transformTime.

CDT tasks are visible in thread dumps.

Tuning will probably have to be done by the agent development team. A support bundle along with the thread dumps will be very helpful in the investigation.

Agent Weight / Environment Complexity

Foglight™ Management Server maintains an internal metric that represents, roughly, the amount of work the server has to do in order to process the data collected by the agents.

This metric is called aggregateAgentWeight. It is available from the EnvComplexityEstimator service in the Management Server Metrics dashboard: Dashboards > Foglight > Servers > Management Server Metrics > <CatalystServer> > Services > com.quest.nitro:service=EnvComplexityEstimator > aggregateAgentWeight.

This metric is derived from the number and types of connected agents according to: <foglight_home>/config/agent-weight.config.

The value of the metric is typically expressed in agent units. Recent server builds generally work well with up to 4000 agent units connected.

The agent-weight.config set-up is based on Quality Assurance (QA) capacity test results. Generally, it should not be changed. However, if new data on the relative agent weight is available, the configuration file can be adjusted manually. You must restart the server after you change this configuration file.

Large Topologies

On occasion, agents may send so much observation data that the resulting topology model becomes too large and causes performance problems in the server.

Java EE Technologies agents are the most likely to cause this type of situation, if they are not carefully pre-configured.

The server is in overload condition.

Agent data is being dropped.

The browser interface performance is poor (that is, it responds slowly).

Create a support bundle and check the topology size breakdown. A topology size breakdown by type is available in the diagnostic snapshot files that are part of each Management Server support bundle. Look for large topology object instance counts.

1. Stop data collection on agents that produce an excessive number of topology objects.

2. Re-configure those agents to produce reasonable amounts of topology data.

3. Delete any excess topology objects.

4. Resume data collection on the affected agents.

There is a large number of JavaEEAppServerRequestType topology objects.

You can reduce the number of JavaEEAppServerRequestType topology objects by adjusting the FilteringRules parameter in recording.config.

Sampling Frequency

All converted Foglight™ 4 agents have a secondary ASP (usually called SamplingFreq) that controls data collection frequencies.

To access that ASP, select an agent in the Administration module of the browser interface and then choose Edit Properties.

相关文档

The document was helpful.

选择评级

I easily found the information I needed.

选择评级