cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1407
Views
0
Helpful
13
Replies

LMS provisioneer.exe process

helexis
Level 1
Level 1

I have LMS split on two servers.

Server 1: CM, IPM (DCR master)

Server 2: RME, DFM

Dual processor, 8G RAM

Managing ~370 devices

While conducting a small group training class where 8 simultaneous users were logged in and perusing the interface, the server was ridiculously slow to respond. Task Manager was showing 100% CPU usage with provisioneer.exe consuming nearly all of it.

Searching this forum I was advised that this process was for the CiscoWorks Assistant and that a reboot would fix the issue.

I rebooted the servers and as expected the CPU usage returned to normal (0-3%).

However, the problem came back. Since this is a production system I am simply unable to down the server every time this process decided to go 'wonky'.

Is there any more information on why this happens or other solutions besides reboot the server?

1 Accepted Solution

Accepted Solutions

Restarting these daemons is like a reboot only in terms of CWA. It is obviously not the same, though, as a reboot will definitely terminate any errant subprocesses (and the database is not restarted).

CWA is more than just one process. It consists of three Daemon Manager controlled daemons (ProcSysBus, OpsXMLRuntime, and OpsxmlDbEngine), and a number of subprocesses like the GG*.exe and Provisioneer processes. All of these processes must be in sync in order for CWA to function properly. None of these processes should take much CPU, especially if a CWA workflow is not being executed. But as I pointed out, there is at least one CPU hog issue in your version of LMS which has been fixed in the latest version.

View solution in original post

13 Replies 13

Joe Clarke
Cisco Employee
Cisco Employee

What version of LMS. As of the latest release, 3.2, all known CPU problems with CWA have been resolved.

helexis
Level 1
Level 1

CiscoWorks Common Services 3.2.0 Licensed Not applicable

Campus Manager 5.1.3 Purchased 1500

CiscoView 6.1.8 Licensed Not applicable

CiscoWorks Assistant 1.1.0 Licensed Not applicable

Internetwork Performance Monitor 4.1.0 Purchased 1500

Integration Utility 1.8.0 Licensed Not applicable

Device Fault Manager 3.1.3 Purchased 1500

Resource Manager Essentials 4.2.0 Purchased 1500

LMS Portal 1.1.0 Licensed Not applicable

Is this installed on VMWare?

No.

I am however a little confused in the registering applications process.

I struggle with what applications to register on the master and whether they should be imported from templates or from the remote server option (because I seem to be able to register remote apps using either option). I also can't decide if the master applications need to be registered with the hostname or the FQDN.

The master won't allow you to register Common Services or Setup Center but it will allow me to register CM and IPM which are all its local apps.

Clarification of this process and the consequences of each different setup directly affect the links available in Device Center. I also find it matters which Device Center you open the master or the slave via a remote portlet. The slave appears properly. In the master's Device Center the top half empty is empty, solid grey.

While replying just now, I tried running CiscoWorks Assistant for the Server Setup worklfow and after several minutes, received CWA025: Could not launch the workflow. CWA engine may not be running. Restart the daemon manager...etc

provisioneer.exe is not currently running

I can send whatever logs you wish just let me know which ones and where.

Thanks!

Also on the FQDN note, when registering each servers own apps it appears to matter if you register them with the FQDN and doesn't recognize what applications are native to which server.

I think you're seeing an engine bug CSCsy22783. This could explain the high CPU usage for Provisioneer.exe, and it is fixed in LSM 3.2. If Provisioneer is not currently running, then that would explain the CWA error. Post the output of the pdshow command.

The issue with application registration should be in its own thread.

pdshow attached

Thanks for your swift replies. :)

Go ahead and restart the ProcSysBus and OpsXMLRuntime daemons. After shutting them down, make sure you don't see any GG*.exe processes still running. If you do, kill them off. To stop the daemons, run:

pdterm ProcSysBus OpsXMLRuntime

Then, to restart them, run:

pdexec ProcSysBus OpsXMLRuntime

After about 10 minutes, you should be able to launch CWA.

OK...so isn't this the equivalent to a reboot?

Hence, a process that has to be monitored closely for misbehavior to prevent processor consumption?

This may help as well...

Yesterday I was able to use the CWA troubleshooting workflow successfully, but it produced the error noted in CSCsw35439 for CM and DFM unsupported application version.

I have submitted a TAC case for assistance editing the Supported Apps table in the database as per another thread of yours.

Is this yet another symptom...the high CPU?

No, this bug has nothing to do with high CPU, but it is also fixed in LMS 3.2.

OK...so isn't this the equivalent to a reboot?

Hence, a process that has to be monitored closely for misbehavior to prevent processor consumption?

Restarting these daemons is like a reboot only in terms of CWA. It is obviously not the same, though, as a reboot will definitely terminate any errant subprocesses (and the database is not restarted).

CWA is more than just one process. It consists of three Daemon Manager controlled daemons (ProcSysBus, OpsXMLRuntime, and OpsxmlDbEngine), and a number of subprocesses like the GG*.exe and Provisioneer processes. All of these processes must be in sync in order for CWA to function properly. None of these processes should take much CPU, especially if a CWA workflow is not being executed. But as I pointed out, there is at least one CPU hog issue in your version of LMS which has been fixed in the latest version.

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community:

Innovations in Cisco Full Stack Observability - A new webinar from Cisco