LMS provisioneer.exe process

Answered Question

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?

Correct Answer by Joe Clarke about 7 years 7 months ago

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.

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 5 (1 ratings)
Loading.
Joe Clarke Thu, 10/01/2009 - 12:44
User Badges:
  • Cisco Employee,
  • Hall of Fame,

    Founding Member

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

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


Joe Clarke Thu, 10/01/2009 - 12:52
User Badges:
  • Cisco Employee,
  • Hall of Fame,

    Founding Member

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!


Joe Clarke Thu, 10/01/2009 - 13:11
User Badges:
  • Cisco Employee,
  • Hall of Fame,

    Founding Member

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.

Joe Clarke Thu, 10/01/2009 - 13:23
User Badges:
  • Cisco Employee,
  • Hall of Fame,

    Founding Member

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.

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?

Joe Clarke Thu, 10/01/2009 - 13:25
User Badges:
  • Cisco Employee,
  • Hall of Fame,

    Founding Member

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

Correct Answer
Joe Clarke Thu, 10/01/2009 - 16:21
User Badges:
  • Cisco Employee,
  • Hall of Fame,

    Founding Member

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.

Actions

This Discussion