1. If the version of CA Service Desk Manager (CA SDM) is prior to 12.7, install the CA Support Diagnostics utility on all SDM servers - this utility is detailed in TEC46921
If you are running version 12.7 or later of CA SDM, the diagnostic tool is automatically installed with CA SDM.
IMPORTANT: Clean out the NX_ROOT\log directory so that the CA Support Diagnostics utility only sends what it has to. Do not have old unneeded dump, trace or other files in the NX_ROOT/log directory. Do not have backup folders under the NX_ROOT/log directory.
2. Install the Microsoft PSLIST utility on all CA SDM servers.
When invoking PSLIST from within a batch file, please invoke it in the following manner to ensure that it generates an easy to read CPU and memory output:
'pslist -m' and 'pslist -s 2'
3. Install the performance logging script from CA Support on all CA SDM servers and have it running at all times. Please refer to TEC473185 for further details
4. Using a performance monitoring utility, monitor the main CA SDM processes in real time and, if possible, also from a historical perspective.
a. Monitor the CPU, Memory and Thread count metrics for the following processes:
b. If the monitoring utility can set baselines on the above metrics, allow it to do so.
- Use those baseline metrics to set threshold levels
- When the thresholds are exceeded, have alarms triggered, appropriate staff notified, and if possible dynamically invoke a script that runs the CA Support Diagnostics tool which will gather the performance logging files.
5. Monitor the CA SDM service on all CA SDM servers. When the CA SDM service is down, dynamically invoke a script that runs the CA Support Diagnostics tool which will gather the performance logging files.
6. Set up SQL profiler trace logging on the SQL server where the MDB is hosted. Refer to the following Microsoft document for further details - https://docs.microsoft.com/en-us/sql/tools/sql-server-profiler/create-a-trace-sql-server-profiler
7. Monitor the MDB for long running queries and any queries which are returning a large number of rows.
8. Create a script/batch file that will copy the STDLOGs from the NX_ROOT\log directory to another location and schedule this script/batch file to run every day around midnight. Be sure that the script creates a unique name for the copied STDLOGs that contains the date they were copied. This way, if you happen to have a problem occur and CA Support asks for the STDLOGs for a certain time period, you will have a copy of the STDLOGs available.
9. As far as database maintenance is concerned, it seems that every DBA has their own take on when to perform re-indexing and other maintenance tasks. We recommend that when a large amount of data is loaded into the MDB (i.e. pdm_load), you should execute a re-index before and check to ensure that there is enough disk space available for database growth. In addition, a database re-indexing can be helpful when SQL performance issues are seen on the MDB database. The drawback to database re-indexing is that it does have a tendency to cause deadlocked tables when it is executed while the CA SDM is up and active. Therefore, if you plan to run database re-indexing or other database maintenance tasks on a scheduled basis, we would strongly suggest that you shutdown the CA SDM service on the CA SDM server(s) prior to performing these tasks.