使用即時監控工具(RTMT)監控和故障排除Cisco Unified Communications Manager 6.0高CPU

簡介

本文檔提供用於幫助監控和排除與帶RTMT的Cisco Unified Communications Manager 6.0上的處理器高利用率相關問題的步驟。

必要條件

需求

思科建議您瞭解以下主題：

• 思科整合通訊管理員

採用元件

本檔案中的資訊是根據以下議程專案：

• 系統時間、使用者時間、IOWait、軟IRQ和IRQ

• CPU追溯警報

• 使用最多CPU的進程的標識

• 高IOWait

• 公共分割槽導致的HighIOWait

• 確定負責磁碟I/O的進程

• 黃色代碼

• 代碼為黃色，但總CPU使用率僅為25% — 原因是什麼？

本檔案中的資訊是根據思科整合通訊管理員6.0。

本文中的資訊是根據特定實驗室環境內的裝置所建立。文中使用到的所有裝置皆從已清除（預設）的組態來啟動。如果您的網路正在作用，請確保您已瞭解任何指令可能造成的影響。

慣例

如需文件慣例的詳細資訊，請參閱思科技術提示慣例。

系統時間、使用者時間、IOWait、軟IRQ和IRQ

利用RTMT來隔離CPU的潛在問題是非常有用的故障排除步驟。

這些術語表示RTMT CPU和記憶體頁面報告的使用情況：

• %System:在系統級別（核心）執行時發生的CPU利用率百分比

• %User:在使用者級別（應用程式）執行時發生的CPU利用率百分比

• %IOWait:cpu等待未完成的磁碟I/O請求時處於空閒狀態的時間百分比

• %SoftIRQ:處理器執行延遲IRQ處理（例如處理網路資料包）的時間百分比

• %IRQ處理器執行中斷請求（分配給中斷裝置）或在完成處理後向電腦傳送訊號的時間百分比

CPU追溯警報

CPUPegging/CallProcessNodeCPUPegging警報根據配置的閾值監視CPU使用情況：

注意：%CPU的計算結果為%system + %user + %nice + %iowait + %softirq + %irq

警報消息包括：

• %system、%user、%nice、%iowait、%softirq和%irq

• 使用最多CPU的進程

• 等待不間斷磁碟休眠的進程

由於CPU使用率高於水印級別，RTMT中可能會出現CPU追溯警報。由於CDR在載入時是CPU密集型應用程式，因此請檢查您是否在CDR配置為運行報告的同一時間段內收到警報。在這種情況下，您需要增加RTMT上的閾值。有關RTMT警報的詳細資訊，請參閱警報。

使用最多CPU的進程的標識

如果%system和/或%user足夠高以生成CpuPegging警報，請檢查警報消息以檢視哪些進程佔用的CPU最多。

注意：轉到「RTMT進程」頁並按%CPU排序以標識高CPU進程。

注意：為了事後分析，RIS故障排除PerfMon日誌會跟蹤進程%CPU使用情況，並在系統級別進行跟蹤。

高IOWait

高%IOWait表示磁碟I/O活動高。請考慮以下事項：

• IOWait是由於大量記憶體交換造成的。

  檢查交換分割槽的%CPU時間，檢視是否有高級別的記憶體交換活動。由於Muster至少具有2G RAM，因此可能由於記憶體洩漏而導致高記憶體交換。

• IOWait是由資料庫活動引起的。

  資料庫是訪問活動分割槽的唯一資料庫。如果活動分割槽的%CPU時間過長，則可能是存在大量資料庫活動。

由於公共分割槽而導致的高IOWait

公用（或日誌）分割槽是儲存跟蹤檔案和日誌檔案的位置。

注意：請檢查以下專案：

• 跟蹤與日誌中心 — 是否存在任何跟蹤收集活動？如果呼叫處理受到影響（即CodeYellow），請調整跟蹤收集計畫。此外，如果使用zip選項，請將其關閉。

• 跟蹤設定 — 在詳細級別，CallManager會生成相當多的跟蹤。如果高%IOWait和/或CCM處於CodeYellow狀態且CallManager服務跟蹤設定處於Detailed，請嘗試將其更改為「Error」。

確定負責磁碟I/O的進程

沒有直接方法可以瞭解每個進程的%IOWait使用情況。目前，最好的方法是檢查磁碟上等待的進程。

如果%IOWait足夠高以引起CpuPegging警報，請檢查警報消息以確定等待磁碟I/O的進程。

• 轉到RTMT進程頁並按狀態排序。檢查進程是否處於不間斷磁碟休眠狀態。TLC用於計畫收集的SFTP進程處於不間斷磁碟休眠狀態。

  

  注意：可以下載RIS Troubleshooting PerfMon日誌檔案來檢查更長時間的進程狀態。

1. 在即時監視工具中，轉至System > Tools > Trace > Trace & Log Central。

   

2. 按兩下Collect Files，然後選擇Next。

   

3. 選擇Cisco RIS Data Collector PerfMonLog，然後選擇Next。

   

4. 在「Collection Time」欄位中，配置檢視相關期間的日誌檔案所需的時間。在「Download File Options」欄位中，瀏覽到下載路徑（從中可以啟動Windows效能監控器來檢視記錄檔的位置），選擇「Zip Files」，然後選擇「Finish」。

   

5. 注意Collect Files進度和下載路徑。此處不報告錯誤。

   

6. 使用Microsoft效能監視器工具檢視效能日誌檔案。選擇開始>設定>控制面板>管理工具>效能。

   

7. 在應用程式視窗中，按一下右鍵並選擇屬性。

   

8. 在系統監視器屬性對話方塊中選擇Source頁籤。選擇Log files:作為資料來源，然後按一下Add按鈕。

   

9. 瀏覽至您下載PerfMon日誌檔案的目錄，然後選擇perfmon csv文件。日誌檔案包括以下命名約定：

   PerfMon_<node>_<month>_<day>_<year>_<hour>_<minute>.csv;例如，PerfMon_10.89.35.218_6_20_2005_11_27.csv。

10. 按一下「Apply」。

11. 按一下Time Range按鈕。為了在PerfMon日誌檔案中指定要檢視的時間範圍，請將條形拖到相應的開始和結束時間。

12. 若要開啟「新增計數器」對話方塊，請按一下Data頁籤，然後按一下Add。在「效能對象」下拉框中，新增進程。選擇Process Status，然後按一下All instances。完成計數器選擇後，按一下關閉。

    

13. 檢視日誌時的提示：

    • 將圖形垂直縮放設定為「最大6」。

    • 關注每個流程，檢視最大值2或更高。

    • 刪除未處於不間斷磁碟休眠狀態的進程。

    • 使用突出顯示選項。

    

    注意：進程狀態2 =不間斷磁碟休眠是可疑的。其他可能的狀態包括0運行、1睡眠、2不間斷磁碟睡眠、3殭屍、4跟蹤或停止、5尋呼、6未知

黃色代碼

當CallManager服務進入Code Yellow狀態時，會生成Code Yellow警報。有關代碼黃色狀態的詳細資訊，請參閱呼叫限制和Code Yellow狀態。可以將CodeYellow警報配置為下載跟蹤檔案以進行故障排除。

AverageExpectedDelay計數器表示處理任何入站消息的當前平均預期延遲。如果該值大於「Code Yellow Entry Latency」服務引數中指定的值，將生成CodeYellow警報。此計數器可以是呼叫處理效能的關鍵指標。

CodeYellow但總CPU使用率僅為25% — 原因是什麼？

在4個虛擬處理器盒中總CPU使用率僅約為25-35%時，CallManager可能會由於缺少處理器資源而進入CodeYellow狀態。

註：在啟用超執行緒後，一台帶有兩個物理處理器的伺服器具有四個虛擬處理器。

注意：類似地，在雙處理器伺服器上，CodeYellow可能佔總CPU使用率約50%。

警報：「服務狀態為關閉。思科報文傳送介面。」

如果RTMT傳送服務狀態為DOWN。思科訊息介面。警報，如果CUCM未與第三方語音消息傳遞系統整合，則必須取消啟用思科消息傳遞介面服務。如果禁用思科報文傳送介面服務，它將停止來自RTMT的進一步警報。

相關資訊

• 語音技術支援
• 語音和整合通訊產品支援
• Cisco IP電話故障排除
• 技術支援與文件 - Cisco Systems

修訂記錄