Ciscoworks LMS 3.1 performance problems VM or Java??

Unanswered Question
Nov 21st, 2008
User Badges:

I am having performance problems with our LMS installation on a VM server. The ESX host is plenty big and the guest has maximum resources allocated for Win2k3 Standard, 4 processors, 4GB of memory.


As far as the VM is concerned, is there any special settings that I need to have set to optimize performance?


I have also noticed a very large number of cwjava.exe, java.exe, dbsrv10.exe and sm_server.exe processes running. Depending on when I look, there may be as many as 40 instances of cwjava.exe running. I am not sure if this is normal or not but it seems suspect.


Is there a way to ensure user sessions are not kept open too long to allow the LMS system to recover resources consumed by unused processes?

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 4.5 (2 ratings)
Loading.
Joe Clarke Fri, 11/21/2008 - 12:16
User Badges:
  • Cisco Employee,
  • Hall of Fame,

    Founding Member

LMS 3.1 includes 72 daemons (if HUM is installed). Most of these daemons spawn or are themselves Java processes. Seeing 40 cwjava processes is not problematic.


We do not have any VM tuning information available at this time. Although, you may see a boost with VM-optimized hardware (e.g. CPUs with built-in virtualization support). What performance issues are you noticing? How many devices are you managing? What applications do you have installed?

m-harrison Fri, 11/21/2008 - 12:27
User Badges:

We have installed the basic list of LMS apps:

CS, DFM, CM, RME, IPM. We are not using HUM.


The performance issues are the basics: Long page opening times, long refresh times, displaying selected reports or management windows.

Checking the performance tab on task manager shows that the CPUs are cranking away. The network utilization stays at about 0-.5% of traffic on a 1 GB link. I have attached the SS of the processors tab for reference.



Joe Clarke Fri, 11/21/2008 - 12:31
User Badges:
  • Cisco Employee,
  • Hall of Fame,

    Founding Member

How many devices are being managed? What process are taking up the most CPU? You will need to get those PIDs, then map them to CiscoWorks daemons using the output of the pdshow command.

m-harrison Fri, 11/21/2008 - 12:52
User Badges:

We are managing about ~700 devices.


I am corolating the high CPU and high memory processes. Here is what I have:


SyslogCollector

ANIServer

EPMServer

EPMDbEngine

ANIDbEngine

UTMajorAcquisition

NOSServer

ESS

ConfigMgmtServer

CampusOGSServer







Joe Clarke Fri, 11/21/2008 - 13:14
User Badges:
  • Cisco Employee,
  • Hall of Fame,

    Founding Member

Okay. You're within supported VM limitations. Most of these processes only operate when there is work to do (otherwise they are idle). SyslogCollector, on the other hand, is interrupt-driven. That is, it will take CPU every time the device receives a new syslog message. Its CPU impact can be mitigated if you reduce the number of syslog messages being sent to the server (e.g. by offloading them to a remote collector).


ANIServer is one of the work driven daemons. It will only run hot when it is performing a Campus Data Collection or servicing Campus Manager client requests. The client requests are short-lived, but Data Collection can put a sustained load on the server. However, if Data Collection is not running, then this process should fall back to near idle.


EPMServer is like SyslogCollector. It will take more CPU the more events are found by DFM. If your network is particularly problematic in terms of faults, then you will see this process along with its associated database take a big CPU hit. Reducing DFM polling frequencies, and adjusting thresholds to be more in tune with your requirements will help here.


UTMajorAcquisition is also work-driven. It will only run when a User Tracking acquisition is running. When the acquisition finishes, it will quit.


NOSServer is similar to EPMServer. It translates the EPM events and alerts into email, trap, and syslog notifications. If you reduce the events coming in and/or reduce what is sent as notifications, then you can reduce NOSServer's CPU impact.


ESS is an event bus. It is used for inter-process communication, and will be mostly idle unless processes are generating a lot of IPC events. This typically occurs when jobs are running.


ConfigMgmtServer is responsible for fetching configs from devices. It will generally be idle unless one runs a Sync Archive job.


CampusOGSServer is related to ANIServer. This process will take CPU time when clients connect to Topology Services, or launch Campus Manager device selectors. Its overall hit will be bursty and short-lived.

Actions

This Discussion