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

[Divin John]

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>
Date:  Monday 11 June 2012 2:56 PM
To:  "cisco-voip (cisco-voip at puck.nether.net)" <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
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/4a538682/attachment.html>