Real Time Monitoring Tool（RTMT）を使用した Cisco Unified Communications Manager 6.0 の CPU 高使用率の監視とトラブルシューティング

概要

このドキュメントでは、RTMT を使用して、Cisco Unified Communications Manager 6.0 でのプロセッサの高使用率に関連する問題の監視とトラブルシューティングを支援する手順を紹介しています。

前提条件

要件

次の項目に関する専門知識があることが推奨されます。

• Cisco Unified Communications Manager

使用するコンポーネント

このドキュメントでは、次の項目について説明します。

• システム時間、ユーザ時間、IOWait、ソフト IRQ、および IRQ

• CPU Pegging アラート

• 最も CPU を使用するプロセスの特定

• 高 IOWait

• 共通パーティションによるHighIOWait

• ディスク I/O を担当するプロセスの特定

• Code Yellow

• 合計 CPU 使用率が 25 % にすぎないのに Code Yellow が発生する理由

このドキュメントの情報は、Cisco Unified Communications Manager 6.0 に基づくものです。

このドキュメントの情報は、特定のラボ環境にあるデバイスに基づいて作成されました。このドキュメントで使用するすべてのデバイスは、初期（デフォルト）設定の状態から起動しています。対象のネットワークが実稼働中である場合には、どのようなコマンドについても、その潜在的な影響について確実に理解しておく必要があります。

表記法

ドキュメント表記の詳細は、『シスコ テクニカル ティップスの表記法』を参照してください。

システム時間、ユーザ時間、IOWait、ソフト IRQ、および IRQ

RTMT を使用して CPU に関する潜在的な問題を特定することは、非常に有用なトラブルシューティング手順となり得ます。

RTMT による CPU とメモリ ページのレポートでは、使用率が次の用語で示されています。

• %System：システム レベル（カーネル）での実行で発生した CPU 利用率のパーセンテージ表記

• %User：ユーザ レベル（アプリケーション）での実行で発生した CPU 利用率のパーセンテージ表記

• %IOWait：未処理のディスク I/O 要求を待機していて CPU がアイドル状態であった時間のパーセンテージ表記

• %SoftIRQ：プロセッサが遅延 IRQ 処理（ネットワーク パケットの処理など）を実行する時間のパーセンテージ表記

• %IRQ：プロセッサが（割り込みに対してデバイスに割り当てられる）割り込み要求を実行する時間、またはプロセッサが処理を終了した際にコンピュータに信号を送信する時間のパーセンテージ表記

CPU Pegging アラート

CPUPegging/CallProcessNodeCPUPegging アラートでは、設定されたしきい値に基づいて CPU 使用率が監視されます。

注： %CPUは%system + %user + %nice + %iowait + %softirq + %irqとして計算されます

アラート メッセージには、次の内容が含まれます。

• %system、%user、%nice、%iowait、%softirq、および %irq

• 最も CPU を使用するプロセス

• 「UNINTERRUPTIBLE DISK SLEEP」（割込不可ディスク スリープ）状態で待機するプロセス

CPU Pegging アラートは、CPU 使用率が水準点として定義されているレベルを超えると RTMT で発生します。CDR はロード時に CPU を多用するアプリケーションであるため、レポートを実行するように CDR が設定されている期間にアラートを受け取るかどうかを確認します。このとき、RTMT でしきい値の増加が必要になることがあります。RTMT アラートについての詳細は、『アラート』を参照してください。

最も CPU を使用するプロセスの特定

%system と %user の一方または両方が CpuPegging アラートを生成するのに十分高い値である場合、警告メッセージをチェックして最も CPU を使用しているプロセスを確認します。

注： RTMTプロセスのページに移動し、%CPUで並べ替えて高CPUプロセスを識別します。

注：事後分析では、RIS Troubleshooting PerfMon Logはプロセス%CPU使用率を追跡し、システムレベルで追跡します。

高 IOWait

%IOWait が高い状態は、ディスク I/O 処理が頻繁に行われていることを示しています。以下の点を考慮してください。

• 頻繁なメモリ スワッピングによる IOWait の増加。

  スワップ パーティションの %CPU 時間をチェックして、高レベルのメモリ スワッピング動作が発生しているかどうかを確認します。Cisco Unified Communications Manager 6.0 のサーバ上には少なくとも 2 GB の RAM が搭載されているため、頻繁なメモリ スワッピングはメモリ リークが原因である可能性が高くなります。

• DB 動作による IOWait の増加。

  DB は、主に、アクティブ パーティションにアクセスする唯一のプロセスです。アクティブ パーティションの %CPU 時間が高い場合は、DB 動作が頻繁に行われている可能性が高くなります。

共通パーティションによる高 IOWait

共通（またはログ）パーティションは、トレースおよびログ ファイルが保存される場所です。

注：次の点を確認してください。

• トレース収集動作が存在していますか。コール処理に影響している場合（つまり CodeYellow）、トレース収集スケジュールを調整します。また、zip オプションが使用されている場合、それをオフにします。

• Detailed レベルでは、CallManager により大量のトレースが生成されます。高 %IOWait/CCM の一方または両方が CodeYellow 状態であり、CallManager サービス トレース設定が Detailed である場合、それを Error に変更してみてください。

ディスク I/O を担当するプロセスの特定

プロセスごとの %IOWait 使用率を直接検出する方法はありません。現時点で最善の方法は、ディスクに関して待機状態にあるプロセスをチェックする方法です。

%IOWait が CpuPegging アラートを引き起こすのに十分高い値である場合、警告メッセージをチェックして、ディスク I/O を待機しているプロセスを判別します。

• RTMT の [Process] ページにアクセスし、[Status] でソートします。Uninterruptible ディスク スリープ状態にあるプロセスをチェックします。スケジュールされた収集のために TLC により使用される SFTP プロセスは、Uninterruptible ディスク スリープ状態にあります。

  

  注：RIS Troubleshooting PerfMon Logファイルをダウンロードして、プロセスのステータスを長時間調べることができます。

1. Real Time Monitoring Tool で、[System] > [Tools] > [Trace] > [Trace & Log Central] の順にアクセスします。

   

2. [Collect Files] をダブルクリックし、[Next] を選択します。

   

3. [Cisco RIS Data Collector PerfMonLog] を選択し、[Next] を選択します。

   

4. [Collection Time] フィールドでは、問題の期間のログ ファイルを表示するのに必要な時間を設定します。[Download File Options] フィールドでは、ダウンロード パス（Windows Performance Monitor を起動してログ ファイルを表示できる場所）を参照し、[Zip Files] を選択して、[Finish] を選択します。

   

5. Collect Files の進行状況とダウンロード パスに注目してください。ここではエラーは報告されないはずです。

   

6. Microsoft Performance Monitor Tool を使用して Performance Log Files を表示します。[Start] > [Settings] > [Control Panel] > [Add New Hardware] の順に選択します。

   

7. アプリケーション ウィンドウで、右クリックして [Properties] を選択します。

   

8. [System Monitor Properties] ダイアログ ボックスの [Source] タブを選択します。データ ソースとして [Log files:] を選択し、[Add] ボタンをクリックします。

   

9. PerfMon Log ファイルをダウンロードしたディレクトリをブラウズし、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 Log ファイルで時間の範囲を指定するには、適切な開始時刻と終了時刻までバーをドラッグします。

12. [Add Counters] ダイアログ ボックスを開くには、[Data] タブをクリックし、[Add] をクリックします。[Performance Object] ドロップダウン ボックスから、[Process] を追加します。[Process Status] を選択し、[All instances] をクリックします。カウンタの選択を完了したら、[Close] をクリックします。

    

13. ログを表示する場合のヒント。

    • グラフの垂直スケールを最大の 6 に設定します。

    • 各プロセスにフォーカスし、最大値が 2 以上であることを確認します。

    • 「UNINTERRUPTIBLE DISK SLEEP」状態ではないプロセスを削除します。

    • ハイライト オプションを使用します。

    

    注：プロセスステータス2 =無停電可能なディスクスリープが疑われます。その他のステータスは、次の可能性を示します。0 – 実行中、1 – スリープ中、2 – 割込不可ディスク スリープ、3 – ゾンビ、4 – トレース済みまたは停止、5 – ページング、6 – 不明。

Code Yellow

Code Yellow アラートは、CallManager サービスが Code Yellow 状態になると生成されます。Code Yellow 状態についての詳細は、『コールの抑制および Code Yellow 状態』を参照してください。CodeYellow アラートは、トラブルシューティング用のトレース ファイルをダウンロードするように設定できます。

AverageExpectedDelay カウンタは、着信メッセージを処理する現在の平均予想遅延を表します。値が、「Code Yellow Entry Latency」サービス パラメータで指定されている値を上回っている場合、CodeYellow アラームが生成されます。このカウンタは、コール処理パフォーマンスの主要な指標の 1 つになります。

CodeYellowがCPUの総使用率はわずか25 % – なぜですか。

4 仮想プロセッサ ボックスで合計 CPU 使用率が約 25 ～ 35 % にすぎない場合であっても、プロセッサ リソースの不足により、CallManager が CodeYellow 状態になる可能性があります。

注：ハイパースレッディングがオンの場合、2つの物理プロセッサを搭載したサーバには4つの仮想プロセッサがあります。

注：同様に、2プロセッササーバでは、CPU使用率の合計が約50 %でCodeYellowが可能です。

アラート：「Service Status is DOWN.Cisco Messaging Interface.」

RTMT から「Service status is DOWN.Cisco Messaging Interface.」アラートが送られてきた場合、CUCM がサード パーティのボイス メッセージング システムに組み込まれていないのであれば、Cisco Messaging Interface サービスを無効にする必要があります。Cisco Messaging Interface サービスを無効にすると、それ以降、RTMT からアラートが送られてくることはありません。

関連情報

• 音声に関する技術サポート
• 音声とユニファイド コミュニケーションに関する製品サポート
• Cisco IP Telephony のトラブルシューティング
• テクニカル サポートとドキュメント – Cisco Systems