Troubleshooting › General Troubleshooting › Determine the Cause of a Spike in SRT and Dip in Observation Count

Determine the Cause of a Spike in SRT and Dip in Observation Count

First determine if another application is active on the server.

1. Click the Engineering page.
2. Select the following Settings from any Response Time view:
   • Application -- All
   • Server -- select the name of the server
   • Network Set -- All
3. Click the blue hypertext Application in the header of the Response Time Composition view to see all applications that are being monitored the server:

   

   If another application appears in the resulting Performance Map, repeat these steps to determine if it is the problem source for the performance issue.

   The key is an increase in the number of observations for the particular application at the same time the performance problem was reported.

4. If no other application appears in the resulting Performance Map, use the back arrow to return to the Engineering page. Click Trends on the horizontal menu and check whether this performance event demonstrates a pattern over the past weeks and month. If a pattern appears you can use a protocol analyzer at the specific time in question on a projected recurring time and date to identify the problem source application.

   Examples of applications that create issues for the primary application on a server are:

   • Backups performed at night
   • Upgrades to anti-virus software
   • Agents used by other teams to measure the server capacity or performance

   Backup processes are typically scheduled through the backup software agent for recurring time periods. Therefore, there should be a pattern visible on the Trends views showing cyclical spikes of Server Response Time at the same time every 24-hour period, every other 24-hour period, or whatever the backup schedule dictates.

   Upgrades to anti-virus definitions are typically done on a weekly basis, or in emergency situations on an "as needed" basis. Consult with your anti-virus software vendor and/or desktop/security team to determine the automated update release schedule. Occasionally, application development teams might install third party agents or encode performance agents into their software. Review change notifications to determine if any changes to the software on the server have been made just prior the start of the performance issue.

Determine if the server/application service has become unreliable.

1. Set up thresholds in the management console to launch an investigation when Server Response Time exceeds accepted values. The management console automatically gathers relevant information such as CPU and memory utilization.
2. Review of server system logs can reveal errors and other events that might be affecting the stability of the application.
3. Check the switch port facing the server and the server NIC to ensure that it is set for the correct duplex and speed settings from the following table, and that it is free from errors.