<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; color: rgb(0, 0, 0); font-size: 14px; font-family: Calibri, sans-serif; "><div>Try this.</div><div><pre style="font-family:monospace; font-size:12px; white-space:normal; white-space:-moz-pre-wrap; white-space:pre-wrap; white-space:-pre-wrap; white-space:-o-pre-wrap; word-wrap:break-word;">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. </pre><pre style="font-family:monospace; font-size:12px; white-space:normal; white-space:-moz-pre-wrap; white-space:pre-wrap; white-space:-pre-wrap; white-space:-o-pre-wrap; word-wrap:break-word;">This should help the spikes at midnight.</pre><pre style="font-family:monospace; font-size:12px; white-space:normal; white-space:-moz-pre-wrap; white-space:pre-wrap; white-space:-pre-wrap; white-space:-o-pre-wrap; word-wrap:break-word;"><br></pre><pre style="font-family:monospace; font-size:12px; white-space:normal; white-space:-moz-pre-wrap; white-space:pre-wrap; white-space:-pre-wrap; white-space:-o-pre-wrap; word-wrap:break-word;"><pre>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</pre><pre><br></pre><pre>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.</pre><pre><br></pre><pre>--Divin</pre><pre><br></pre></pre></div><div><br></div><span id="OLK_SRC_BODY_SECTION"><div style="font-family:Calibri; font-size:11pt; text-align:left; color:black; BORDER-BOTTOM: medium none; BORDER-LEFT: medium none; PADDING-BOTTOM: 0in; PADDING-LEFT: 0in; PADDING-RIGHT: 0in; BORDER-TOP: #b5c4df 1pt solid; BORDER-RIGHT: medium none; PADDING-TOP: 3pt"><span style="font-weight:bold">From: </span> "Jason Aarons (AM)" <<a href="mailto:jason.aarons@dimensiondata.com">jason.aarons@dimensiondata.com</a>><br><span style="font-weight:bold">Date: </span> Monday 11 June 2012 2:56 PM<br><span style="font-weight:bold">To: </span> "cisco-voip (<a href="mailto:cisco-voip@puck.nether.net">cisco-voip@puck.nether.net</a>)" <<a href="mailto:cisco-voip@puck.nether.net">cisco-voip@puck.nether.net</a>><br><span style="font-weight:bold">Subject: </span> [cisco-voip] FW: [RTMT-ALERT-StandAloneCluster] CallProcessingNodeCpuPegging<br></div><div><br></div><div xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40"><meta http-equiv="Content-Type" content="text/html; charset=us-ascii"><meta name="Generator" content="Microsoft Word 14 (filtered medium)"><style><!--
/* Font Definitions */
@font-face
{font-family:Tahoma;
panose-1:2 11 6 4 3 5 4 4 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman","serif";}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
p.MsoAcetate, li.MsoAcetate, div.MsoAcetate
{mso-style-priority:99;
mso-style-link:"Balloon Text Char";
margin:0in;
margin-bottom:.0001pt;
font-size:8.0pt;
font-family:"Tahoma","sans-serif";}
span.BalloonTextChar
{mso-style-name:"Balloon Text Char";
mso-style-priority:99;
mso-style-link:"Balloon Text";
font-family:"Tahoma","sans-serif";}
span.EmailStyle19
{mso-style-type:personal-reply;
font-family:"Calibri","sans-serif";
color:#1F497D;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]--><div bgcolor="white" lang="EN-US" link="blue" vlink="purple"><div class="WordSection1"><p class="MsoNormal" style="margin-bottom:12.0pt"><span style="color:#1F497D">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.<o:p></o:p></span></p><p class="MsoNormal" style="margin-bottom:12.0pt"><span style="color:#1F497D">Any ideas?<o:p></o:p></span></p><p class="MsoNormal" style="margin-bottom:12.0pt"><br><b>Subject:</b> <b>[RTMT-ALERT-StandAloneCluster] CallProcessingNodeCpuPegging</b><o:p></o:p></p><div><p class="MsoNormal">Server CPU is Pegging over 90% Processor load over configured threshold for configured duration of time . Configured high threshold is 90 % <br>cmoninit (7 percent) uses most of the CPU. <br><br>Processor_Info: <br><br>For processor instance _Total: %CPU= 99, %User= 13, %System= 6, %Nice= 0, %Idle= 0, %IOWait= 81, %softirq= 0, %irq= 0. <br><br>For processor instance 0: %CPU= 99, %User= 13, %System= 6, %Nice= 0, %Idle= 0, %IOWait= 81, %softirq= 0, %irq= 0. <br><br>The alert is generated on Mon Jun 11 00:02:46 EDT 2012 on node <span style="color:#1F497D">10.69.68.32</span><br><br>Memory_Info: %Mem Used= 66, %VM Used= 35. <br><br>Partition_Info: <br>Swap: %Disk Used=1. <br>Active: %Disk Used=81. <br>Common: %Disk Used=16. <br><br>Process_Info: processes with D-State: kjournald#1 cmoninit#6<o:p></o:p></p></div><p class="MsoNormal"><br><br><span style="color:white">itevomcid</span> <o:p></o:p></p></div></div></div>_______________________________________________
cisco-voip mailing list
<a href="mailto:cisco-voip@puck.nether.net">cisco-voip@puck.nether.net</a>
<a href="https://puck.nether.net/mailman/listinfo/cisco-voip">https://puck.nether.net/mailman/listinfo/cisco-voip</a>
</span></body></html>