CLM extend use case impacted due to performance  issues in BMC Service Level Management while running escalations against the sample data

This topic describes performance issues that can occur when using BMC Service Level Management (BMC SLM) in a BMC Cloud Lifecycle Management environment while running escalations against the sample data. It presents workarounds to resolve the issues.

Issues

The following BMC SLM escalations can cause performance issues:

• SLM:EventSchedule:TAD_PollingEscalation
• SLM:ConfigReviewPeriod:Check

The following are examples of the kinds of problems that can arise when these performance issues occur:

• When DSO pushes cloud contract line reference objects into the cloud AR System server, the SLM escalation blocks the DSO escalation.
• An update to the SLM Status field on the incident record does not show the update to the MeasurementStatus field on the service target SLM:Measurement record. This affects only BMC SLM use cases and not cloud use cases.
• Milestone notifications are sporadic or are not sent. Again, this is only a problem with BMC SLM use cases and not cloud use cases.

Workarounds

The following workarounds can prevent the performance issues related to the BMC SLM escalations mentioned above.

Delete BMC SLM sample data

The sample data that is installed with BMC SLM can unexpectedly cause a large increase in the number of records in the SLM:SLACompliance and SLM:SLAComplianceHistory forms. The resulting increase in compliance data can cause performance issues with the SLM:ConfigReviewPeriod:Check escalation.

For details on how to delete the sample data, see Knowledge Article KA368902.
 To access Knowledge Articles:

1. Log on to the BMC Software Customer Support Knowledge Base.
2. Enter the KA number in the Search field and click Ask.

Create escalation thread pools for certain escalations

To eliminate performance issues related to the listed escalations, create two thread pools so that the SLM escalations run in their own escalation pools:

1. Use BMC Developer Studio to log in to the AR System server, and then list the escalations in descending order by the escalation pool.
    The highest escalation pool number is the number of escalation pools that are configured.
2. Identify if the following escalations are running in escalation pools:
   • SLM:EventSchedule:TAD_PollingEscalation
   • SLM:ConfigReviewPeriod:Check

   • SLM:EventSchedule:TAD_PollingEscalation_Compliance 

     Note

     SLM:ConfigReviewPeriod:Check and SLM:EventSchedule:TAD_PollingEscalation_Compliance should be in the same pool.

3. Identify if any other escalations are configured to run in same pool.
4. Modify or create thread pools as needed (so that the escalations are running in their own pools).
    Move any escalations running in the same escalation pool to a different pool.
   1. Create one thread pool for SLM:EventSchedule:TAD_PollingEscalation where it is the only escalation in the pool.
   2. Configure this escalation to run in a pool that is higher than the highest escalation pool number already in use.
   3. Create a second thread pool in which SLM:ConfigReviewPeriod:Check and SLM:EventSchedule:TAD_PollingEscalation_Compliance are the only escalations in the pool.
   4. Configure these escalations to run in a pool higher than the pool configured for SLM:EventSchedule:TAD_PollingEscalation.
5. Determine if there are enough escalation threads configured to support the number of escalation pools.
   1. Open the BMC Remedy AR System Administrator Console.
   2. Click the Ports and Queues tab.
   3. Confirm the minimum and maximum threads configured for the escalation queue.
   4. If needed, configure the maximum threads to be equal to the highest escalation pool number configured for any escalation.
6. Restart the AR System server to implement the configuration of the escalation pools.

Related topics

Urgent-issues
What-s-new