CASD Slowness

[Legacy User]

Hi,

 

We have CASD 12.7 on Windows 2007 SP2 a Virtual Machine, and a Remote MSSQL Database 2008 R2 on a physical Windows 2008 R2 machine.

We had Slowness Issues which caused users 4,5 Mins to save a single ticket once it is saved from edit mode.

We checked the Connectivity from Database, and Application Server. It was fine as Pining took <1ms.

We checked the logs of CASD. There was no particular error pertains to Slowness.

We had checked the CPU, Memory utilization of Application server. It was  around 30%.

Currently running sessions were varying from 90- 150 on dom servers.

We checked in DB if there are any Suspended queries and killed those queries. and Rebooted the Application server once. But still the issue didn't get resolved.

 

After 2 hours we again rebooted the Application server. The issue got resolved this time.

I don't know how it resolved the slowness.

 

Can anyone share some insights on this?

 

Regards,

Gaspar.

[Paul Coccimiglio]

Gaspar........

 

First off, CA SDM 12.7 has been end of support for some time now.  Do you have any plans to upgrade to the latest CA SDM 14.1 release?

 

Slowness within the CA SDM application could be related to a number of factors, like:

 

1.  Long running queries (i.e. Scoreboard queries or report queries)

2.  Network issues between CA SDM server and DB server

3.  In a VM environment, the resources dedicated to CA SDM must be dedicated so that there is no resource swapping occurring on the VM host

4.  Anti-virus scan or backup activity on the CA SDM server

[Legacy User]

Hi Paul,

1. We didn't configure any new queries, so I guess long running queries won't be a concern.

2. we checked the connectivity between CA SDM Application and DB server during slow hours through ping command. But we found all the packets were received and the time taken for the same was <1ms.

3. VMs are having dedicated resources for them.

4. Queries related to Backup activity were running in DB when I checked with sp_who2 Active command in SQL.

 

Apart from these, we could see the below 2 things during slow hours;

We see the below error often while the tool becomes slow.

03/09 09:42:00.94 W-MUM-SDESKAPP spelsrvr:primary:    4548 ERROR        auditlog.spl           759  checkout error 'NO'

 

When I checked the CASDM server's task manager the Number of running processes being 170-200 during normal hours with CPU and RAM utilization being around 30%

But During the Slow hours the number of processes becoming more than 400, with CPU and RAM utilization being around 30%.

[Alexander Perretti]

Was anything specific noted in the logs during the slowness? Also how many database agents is your Service Desk configured for? It may be possible that if you did have long running queries (like Paul mentioned) it could be causing a bottleneck.

[Legacy User]

Hi,

We see the below error often while the tool becomes slow.

03/09 09:42:00.94 W-MUM-SDESKAPP spelsrvr:primary:    4548 ERROR        auditlog.spl           759  checkout error 'NO'

 

We are having 11 database agents in our environment.

We didn't configure any new queries, so I guess long running queries could cause issues.

 

When I checked the CASDM server's task manager the Number of processes being 170-200 during normal hours with CPU and RAM utilization being around 30%

But During the Slow hours the number of processes becoming more than 400, with CPU and RAM utilization being around 30%.

 

Regards,

Gaspar.

[JEROME MAYER]

If you have no use of the audit_log I will recommend you to disable it in option manager to save resource as this seems to be eventually a ssource of the problem.

as you mention backup was running during that time you may want to identify if this is really a pattern.

in that case i will recommend to schedule your backup in non pick hours but also verify the method used for backup as it may be that the backup was locking some records and then SDM can't access *** like for example insert a new record to the audit table...

my 2 cents

 

/J

 

P.S.: it's also maybe time now to run away from 12.7...