[cisco-voip] FW: [RTMT-ALERT-StandAloneCluster] CallProcessingNodeCpuPegging

[Jason Aarons (AM)]

So these are in Service Parameters for CCM?  Exactly where do you change these? CLI?

It is VMWare ESXi 4.1Update2 with direct disks/storage. No NAS.SAN

From: Divin John [mailto:dijohn at cisco.com]
Sent: Monday, June 11, 2012 5:45 AM
To: Jason Aarons (AM); cisco-voip (cisco-voip at puck.nether.net)
Subject: Re: [cisco-voip] FW: [RTMT-ALERT-StandAloneCluster] CallProcessingNodeCpuPegging

Try this.

In order to flatten the midnight maintenance spike, we would like to change the default service parameters for DB throttling, specifically: Maintenance Throttling for Tables: change from 0 to 500ms Maintenance Throttling for Stored Procedures: change from 0 to 1000ms. These should be changed only on VMware-based systems on fresh installs.

This should help the spikes at midnight.



Maintenance Throttling for Tables:



This parameter determines the number of milliseconds of delay to insert in the daily Unified CM database maintenance job when Unified CM is performing maintenance on the table and index portion of the database.

Another service parameter, Maintenance Throttling for Stored Procedures, inserts a similar delay during the daily maintenance job. Use these throttling service parameters to decrease the I/O caused by daily database maintenance. Especially in VMware environments, the frequency of unthrottled database maintenance I/O operations can cause performance issues or problems accessing the attached network storage. For traditional Unified CM deployments, the default value is usually sufficient. In a VMware environment with 15,000 phones (for example), a

500 millisecond delay may help if you are experiencing spikes in I/O. A value greater than zero in this parameter will also slow L2 upgrades.



      This is a required field.

      Default:  0

      Minimum:  0

      Maximum:  3000

      Unit: ms



Maintenance Throttling for Stored Procedures:



This parameter determines the number of milliseconds of delay to insert in the daily Unified CM database maintenance job when Unified CM is performing maintenance on the stored procedures portion of the database.

Another service parameter, Maintenance Throttling for Tables, inserts a similar delay during the daily maintenance job. Use these throttling service parameters to decrease the I/O caused by daily database maintenance. Especially in VMware environments, the frequency of unthrottled database maintenance I/O operations can cause performance issues or problems accessing the attached network storage. For traditional Unified CM deployments, the default value is usually sufficient. In a VMware environment with 15,000 phones (for example), a

1000 millisecond delay may help if you are experiencing spikes in I/O. A value greater than zero in this parameter will also slow L2 upgrades.



      This is a required field.

      Default:  0

      Minimum:  0

      Maximum:  3000

      Unit: ms



To verify this, change the database timer from 00:00 to something else, you would see a spike 1 or 2 minutes after that time.



--Divin



From: "Jason Aarons (AM)" <jason.aarons at dimensiondata.com<mailto:jason.aarons at dimensiondata.com>>
Date: Monday 11 June 2012 2:56 PM
To: "cisco-voip (cisco-voip at puck.nether.net<mailto:cisco-voip at puck.nether.net>)" <cisco-voip at puck.nether.net<mailto:cisco-voip at puck.nether.net>>
Subject: [cisco-voip] FW: [RTMT-ALERT-StandAloneCluster] CallProcessingNodeCpuPegging

After upgrading to CallManager 8.5.1SU3, every night I get a RTMT alert regarding high cpu with %IOWait  being the culprit. Never happens during day, just between midnight and 4am.
Any ideas?

Subject: [RTMT-ALERT-StandAloneCluster] CallProcessingNodeCpuPegging
Server CPU is Pegging over 90%  Processor load over configured threshold for configured duration of time . Configured high threshold is 90 %
cmoninit (7 percent) uses most of the CPU.

Processor_Info:

For processor instance _Total: %CPU= 99, %User= 13, %System= 6, %Nice= 0, %Idle= 0, %IOWait= 81, %softirq= 0, %irq= 0.

For processor instance 0: %CPU= 99, %User= 13, %System= 6, %Nice= 0, %Idle= 0, %IOWait= 81, %softirq= 0, %irq= 0.

The alert is generated on Mon Jun 11 00:02:46 EDT 2012 on node 10.69.68.32

Memory_Info: %Mem Used= 66, %VM Used= 35.

Partition_Info:
Swap: %Disk Used=1.
Active: %Disk Used=81.
Common: %Disk Used=16.

Process_Info: processes with D-State:  kjournald#1 cmoninit#6


itevomcid
_______________________________________________ cisco-voip mailing list cisco-voip at puck.nether.net<mailto:cisco-voip at puck.nether.net> https://puck.nether.net/mailman/listinfo/cisco-voip
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20120611/08f0bfe9/attachment.html>