Joe Clarke Fri, 05/01/2009 - 13:08

Is the RME home page the only thing that is slow? Is this server integrated with ACS? On what platform is it running? What is the CPU utilization on the server? What are the server specs?

A.Shchukin Fri, 05/01/2009 - 13:14

RME jobs take forewer to run

Server is not integrated with ACS

Platform Win2kServer SP4

CPU Utilization: around %60

Server specs: Xeon 3.2 Ghz RAM 4 Gig

page file 4048 MB. 25 Gig Free space where CWorks is installed

Joe Clarke Fri, 05/01/2009 - 13:26

What RME jobs take a long time to run? How many devices are in the job? What is a long time?

How many jobs do you have on the system? A system with a lot of jobs can cause the RME Homepage to take a long time to load. This is supposedly being corrected in LMS 3.2, but I haven't been able to test.

The CPU utilization can also be an issue. What processes are taking up the most CPU? If they are not Cisco processes, can they be stopped to see what effect that has on performance? If they are Cisco processes, what CiscoWorks daemons do their PIDs map to in the output of the pdshow command?

A.Shchukin Fri, 05/01/2009 - 13:43

Device credential verification job was running for 13 hours. I had to stop it.

As far as I can see there is no running jobs at this point and still takes a long time to open (approx 30 min). pdshow is attached.

Joe Clarke Fri, 05/01/2009 - 13:59

The next time a job gets stuck like that, open a TAC service request so a thread dump can be obtained from the running job.

The number of running jobs is not the problem with the RME Homepage. The issue is with the total number of scheduled and completed jobs on the system. If there are a lot of jobs, then RME will spend a long time filtering out its jobs to display on the homepage.

The pdshow alone does not do me any good. You need to map the PIDs in this pdshow to those taking up a lot of CPU time. If the box is otherwise idle, but there are Cisco processes taking up a lot of CPU, that could point to a problem.


This Discussion