Page History
...
| Anchor | ||||
|---|---|---|---|---|
|
In most cases, a Precise TPM tab displays information in the context of a specific application and time frame. However, if you want to view findings for another time frame or application, you can change these settings using the respective dropdown lists. See About TPM findings.
How to investigate a finding
When investigating finding, it is recommended to investigate findings based on their severity.
...
- In the All Applications table, select the application you want to investigate. In the Finding Details area, the top findings for a selected application are displayed in the Findings table of a tab.
- Identify the findings with the highest severity rankings (red, orange, and yellow icons where red is the highest severity and yellow the lowest) in the Findings table.
- In the Findings table, select a finding to analyze further the problem.
- In the selected finding (the expanded view), read the data displayed for the finding and follow any links provided to view additional information (advice) or next steps (bullets) to perform the recommendation(s) that best suit(s) your needs.
| Anchor | ||||
|---|---|---|---|---|
|
Several tab findings exist in the Findings table to help the user.
...
- Hotspot Detected
- Frequent SLA Breaches
- Partial Upgrade
- Starved Virtual Machine
- VM Memory Swapping
- Virtualization Events Detected
| Anchor | ||||
|---|---|---|---|---|
|
A high work time for a specific hotspot (reflecting the hotspot's work time only, without the underlying call path), can indicate a performance issue within the context of that hotspot.
In the same way, a high work time for a specific occurrence of a hotspot invoked multiple times in the invocation tree can indicate a performance issue within the context of that specific occurrence.
Working with the finding
To effectively locate the root cause of the performance finding, examine the heaviest occurrences further by following the featured link.
...
| Info |
|---|
By default, information is displayed for the heaviest hotspot's call path. To investigate the other call paths, select them from the invocation tree. (They are highlighted in bold). |
| Anchor | ||||
|---|---|---|---|---|
|
SLA thresholds are defined to help the user pinpoint transactions experiencing performance issues according to specific criteria. Frequent SLA breaches and near breaches can be caused by an underlying performance issue.
Working with the finding
To effectively locate the root cause of the performance finding, perform one of the following:
- Click on the transaction's link, and then look at the overtime SLA behavior to locate and zoom in to a specific (problematic) time frame. View the findings for that time frame and drill down until you locate the root cause.
- Select the root level of the transactions tree and select the Transactions tab. A high rate of SLA breaches across the application could result from overall resource exhaustion. Open the Tiers tab, follow the link to the heaviest ones and open the Statistics tab to learn more about the environment performance issues, like high memory usage, CPU usage and so on.
- Go to AdminPoint > Settings > SLA to view the thresholds definitions. (When you have too many SLA breaches, it may be a result of thresholds that are not defined appropriately for your application).
| Anchor | ||||
|---|---|---|---|---|
|
This Application has undergone an upgrade with Precise 9.6.x, but not all of the instances were upgraded. Therefore, statistics data will be displayed only for instances that have either been upgraded, or are newly installed.
Working with the finding
To effectively locate the root cause of the performance finding, perform the following:
- Upgrade all instances in this Application. You can see a list of the non-upgraded servers in the AdminPoint > Management > Updates.
- To view data for the old instances, move the instances to a separate Application.
| Anchor | ||||
|---|---|---|---|---|
|
This section contains information about the Starved Virtual Machine finding in Precise TPM.
CPU Ready time is the amount of time that a guest virtual machine is ready to run against the physical CPU. However, the VMware CPU Scheduler cannot find time to run the virtual machine because other virtual machines are competing for the same resources. CPU Ready time can be an indicator of saturation on a system.
Working with the finding
To effectively locate the root cause of the performance finding, perform the following:
- Examine the statistics for the virtual machines sharing the ESX Server of the starved virtual machine, and look for virtual machines that use a high level of CPU usage.
- Refer to VMware's documentation on CPU management for solutions.
| Anchor | ||||
|---|---|---|---|---|
|
This section contains information about the VM Memory Swapping finding in Precise TPM.
...
The basic cause of memory swapping is memory over-commitment using virtual machines with high memory demands.
Working with the finding
To effectively locate the root cause of the performance finding, perform the following:
- Examine the statistics for the virtual machines sharing the ESX Server of the suffering virtual machine, and look for virtual machines that use a high amount of memory.
- Refer to VMware's documentation on Memory management for solutions.
| Anchor | ||||
|---|---|---|---|---|
|
This section contains information about the Virtualization Events Detected finding in Precise TPM.
Virtual machine events inform you of anything that occurs during the lifetime of a virtual machine. Any event on your application's virtual machines is something that is irregular and should be considered when checking performance issues.
Working with the finding
To effectively locate the root cause of the performance finding, examine the events that occurred for the application's virtual machines. Look for any changes in the performance graphs to see if the events might have had any influence on the virtual machine's behavior.
...