|
2010 年 4 月 2 日 - ライター翻訳版 |
その他のバージョン： PDF | 機械翻訳版 (2011 年 11 月 18 日) | 英語版 (2009 年 1 月 30 日) | フィードバック |
目次
概要
前提条件
要件
使用するコンポーネント
表記法
システム時間、ユーザ時間、IOWait、ソフト IRQ、および IRQ
CPU Pegging アラート
最も CPU を使用するプロセスの特定
高 IOWait
共通パーティションによる高 IOWait
ディスク I/O を担当するプロセスの特定
Code Yellow
合計 CPU 使用率が 25 % にすぎないのに CodeYellow が発生する理由
アラート：「Service Status is DOWN.Cisco Messaging Interface.」
Cisco サポート コミュニティ - 特集対話
関連情報
このドキュメントでは、Cisco Unified Communications Manager 6.0 でのプロセッサの高使用率に関連する問題を、RTMT を使用して監視およびトラブルシューティングを行う手順について説明します。
次の項目に関する知識があることが推奨されます。
このドキュメントでは、次の項目について説明します。
このドキュメントの情報は、Cisco Unified Communications Manager 6.0 に基づくものです。
このドキュメントの情報は、特定のラボ環境にあるデバイスに基づいて作成されたものです。このドキュメントで使用するすべてのデバイスは、クリアな（デフォルト）設定で作業を開始しています。対象のネットワークが実稼働中である場合には、どのような作業についても、その潜在的な影響について確実に理解しておく必要があります。
ドキュメント表記の詳細は、『シスコ テクニカル ティップスの表記法』を参照してください。
RTMT を使用して CPU に関する潜在的な問題を特定することは、トラブルシューティングの際に非常に役立つことがあります。
RTMT による CPU とメモリ ページのレポートでは、使用率が次の用語で示されています。
-
%System：システム レベル（カーネル）での実行で発生した CPU 利用率のパーセンテージ表記
-
%User：ユーザ レベル（アプリケーション）での実行で発生した CPU 利用率のパーセンテージ表記
-
%IOWait：未処理のディスク I/O 要求を待機していて CPU がアイドル状態であった時間のパーセンテージ表記
-
%SoftIRQ：プロセッサが遅延 IRQ 処理（ネットワーク パケットの処理など）を実行する時間のパーセンテージ表記
-
%IRQ：プロセッサが（割り込みに対してデバイスに割り当てられる）割り込み要求を実行する時間、またはプロセッサが処理を終了した際にコンピュータに信号を送信する時間のパーセンテージ表記
CPUPegging/CallProcessNodeCPUPegging アラートでは、設定されたしきい値に基づいて CPU 使用率が監視されます。
注：%CPU は、%system + %user + %nice + %iowait + %softirq + %irq で計算されます。
アラート メッセージには、次の内容が含まれます。
CPU Pegging アラートは、CPU 使用率が水準点として定義されているレベルを超えると RTMT で発生します。CDR はロード時に CPU を多用するアプリケーションであるため、レポートを実行するように CDR が設定されている期間にアラートを受け取るかどうかを確認します。このとき、RTMT でしきい値の増加が必要になることがあります。RTMT アラートについての詳細は、『アラート』を参照してください。
%system と %user の一方または両方が CpuPegging アラートを生成するのに十分高い値である場合、警告メッセージをチェックして最も CPU を使用しているプロセスを確認します。
注：RTMT の [Process] ページにアクセスし、[%CPU] でソートして、高 CPU のプロセスを特定します。
注：事後分析用に、RIS Troubleshooting PerfMon Log はプロセスの %CPU 使用率を追跡し、またシステム レベルでの追跡を行います。
%IOWait が高い状態は、ディスク I/O 処理が頻繁に行われていることを示しています。以下の点を考慮してください。
-
頻繁なメモリ スワッピングによる IOWait の増加。
スワップ パーティションの %CPU 時間をチェックして、高レベルのメモリ スワッピング動作が発生しているかどうかを確認します。Cisco Unified Communications Manager 6.0 のサーバ上には少なくとも 2 GB のメモリが搭載されているため、頻繁なメモリ スワッピングはメモリ リークが原因である可能性が高くなります。
-
DB 動作による IOWait の増加。
DB は、主に、アクティブ パーティションにアクセスする唯一のプロセスです。アクティブ パーティションの %CPU 時間が高い場合は、DB 動作が頻繁に行われている可能性が高くなります。
共通（またはログ）パーティションは、トレースおよびログ ファイルが保存される場所です。
注：次の点をチェックしてください。
-
Trace & Log Central。トレース収集動作が存在していますか。コール処理に影響している場合（つまり CodeYellow）、トレース収集スケジュールを調整します。また、zip オプションが使用されている場合、それをオフにします。
-
トレース設定。Detailed レベルでは、CallManager により大量のトレースが生成されます。高 %IOWait/CCM の一方または両方が CodeYellow 状態であり、CallManager サービス トレース設定が Detailed である場合、それを Error に変更してみてください。
プロセスごとの %IOWait 使用率を直接検出する方法はありません。現時点で最善の方法は、ディスクに関して待機状態にあるプロセスをチェックする方法です。
%IOWait が CpuPegging アラートを引き起こすのに十分高い値である場合、警告メッセージをチェックして、ディスク I/O を待機しているプロセスを判別します。
-
RTMT の [Process] ページにアクセスし、[Status] でソートします。「UNINTERRUPTIBLE DISK SLEEP」の状態にあるプロセスをチェックします。ここでは、スケジュールされた収集のために TLC により使用される SFTP プロセスが、「UNINTERRUPTIBLE DISK SLEEP」の状態にあります。
注：RIS Troubleshooting PerfMon Log ファイルをダウンロードすると、より長い期間のプロセスの状態を調べることができます。
-
Real Time Monitoring Tool で、[System] > [Tools] > [Trace] > [Trace & Log Central] の順にアクセスします。
-
[Collect Files] をダブルクリックし、[Next] を選択します。
-
[Cisco RIS Data Collector PerfMonLog] を選択し、[Next] を選択します。
-
[Collection Time] フィールドでは、問題の期間のログ ファイルを表示するのに必要な時間を設定します。[Download File Options] フィールドでは、ダウンロード パス（Windows Performance Monitor を起動してログ ファイルを表示できる場所）を参照し、[Zip Files] を選択して、[Finish] を選択します。
-
Collect Files の進行状況とダウンロード パスに注目してください。ここではエラーは報告されないはずです。
-
Microsoft Performance Monitor Tool を使用して Performance Log Files を表示します。[Start] > [Settings] > [Control Panel] > [Add New Hardware] の順に選択します。
-
アプリケーション ウィンドウで、右クリックして [Properties] を選択します。
-
[System Monitor Properties] ダイアログ ボックスの [Source] タブを選択します。データ ソースとして [Log files:] を選択し、[Add] ボタンをクリックします。
-
PerfMon Log ファイルをダウンロードしたディレクトリをブラウズし、perfmon csv ファイルを選択します。ログ ファイルの命名規則は次のとおりです。
PerfMon_<node>_<month>_<day>_<year>_<hour>_<minute>.csv（たとえば、PerfMon_10.89.35.218_6_20_2005_11_27.csv）
-
[Apply] をクリックします。
-
[Time Range] ボタンをクリックします。表示する PerfMon Log ファイルで時間の範囲を指定するには、適切な開始時刻と終了時刻までバーをドラッグします。
-
[Add Counters] ダイアログ ボックスを開くには、[Data] タブをクリックし、[Add] をクリックします。[Performance Object] ドロップダウン ボックスから、[Process] を追加します。[Process Status] を選択し、[All instances] をクリックします。カウンタの選択を完了したら、[Close] をクリックします。
-
ログを表示する場合のヒント。
注：Process Status が 2 の場合、「UNINTERRUPTIBLE DISK SLEEP」（割込不可ディスク スリープ）状態の疑いがあります。その他のステータスは、次の可能性を示します。0 - 実行中、1 - スリープ中、2 - 割込不可ディスク スリープ、3 - ゾンビ、4 - トレース済みまたは停止、5 - ページング、6 - 不明。
Code Yellow アラートは、CallManager サービスが Code Yellow 状態になると生成されます。Code Yellow 状態についての詳細は、『コールの抑制および Code Yellow 状態』を参照してください。CodeYellow アラートは、トラブルシューティング用のトレース ファイルをダウンロードするように設定できます。
AverageExpectedDelay カウンタは、着信メッセージを処理する現在の平均予想遅延を表します。値が、「Code Yellow Entry Latency」サービス パラメータで指定されている値を上回っている場合、CodeYellow アラームが生成されます。このカウンタは、コール処理パフォーマンスの主要な指標の 1 つになります。
4 仮想プロセッサ ボックスで合計 CPU 使用率が約 25 〜 35 % にすぎない場合であっても、プロセッサ リソースの不足により、CallManager が CodeYellow 状態になる可能性があります。
注：ハイパー スレッディングをオンにすると、2 つの物理プロセッサを搭載したサーバには 4 つの仮想プロセッサが存在します。
注：同様に、2 プロセッサ サーバでは、合計 CPU 使用率が約 50 % で CodeYellow になる可能性があります。
RTMT から「Service status is DOWN.Cisco Messaging Interface.」アラートが送られてきた場合、CUCM がサード パーティのボイス メッセージング システムに組み込まれていないのであれば、Cisco Messaging Interface サービスを無効にする必要があります。Cisco Messaging Interface サービスを無効にすると、それ以降、RTMT からアラートが送られてくることはありません。
Cisco サポート コミュニティ - 特集対話
Cisco サポート コミュニティでは、フォーラムに参加して情報交換することができます。現在、このドキュメントに関連するトピックについて次のような対話が行われています。
