Cisco Unity メンテナンス ガイド
Cisco Unity 8.x でのパフォーマンスの監視
Cisco Unity 8.x でのパフォーマンスの監視
発行日;2012/02/03 | 英語版ドキュメント(2010/02/02 版) | ドキュメントご利用ガイド | ダウンロード ; この章pdf , ドキュメント全体pdf (PDF - 1MB) | フィードバック

目次

Cisco Unity 8.x でのパフォーマンスの監視

8.x のパフォーマンス監視の概要

8.x でのパフォーマンスの定義

8.x でのパフォーマンスに対する期待の確定

8.x での オンボックスとオフボックスのメッセージ ストア環境でのパフォーマンス監視

8.x でのパフォーマンスの監視に必要な許可

8.x サーバと メッセージ ストア サーバでの Network Provider Monitor の設定

8.x での パフォーマンス情報ツールの設定

Cisco Unity Performance Information and Diagnostics(CUPID)の設定

パフォーマンス モニタの設定

サーバ用のパフォーマンス モニタ設定

オフボックスの メッセージ ストア サーバ用のパフォーマンス モニタ設定

8.x のパフォーマンスに関する監視のガイドライン

8.x システムでのパフォーマンス テスト

パフォーマンス テストのプロセス

テスト実施の準備

タスク リスト:パフォーマンス テストの準備

パフォーマンス テストの実施

パフォーマンスの測定と記録データの収集

収集したパフォーマンス テスト結果の分析

修正措置計画

修正措置計画を実装するためのシステム変更

識別されている問題の解決

テスト サイクルの完了

8.x のテストに使用するパフォーマンス カウンタ

必須のシステム パフォーマンス カウンタ

一般的なシステム パフォーマンス カウンタ

サーバのパフォーマンス カウンタ

メッセージ ストアのパフォーマンス カウンタ

8.x のパフォーマンス カウンタのトラブルシューティング

Cisco Unity 8.x でのパフォーマンスの監視

次の項を参照してください。

「Cisco Unity 8.x のパフォーマンス監視の概要」

「Cisco Unity 8.x でのパフォーマンスの定義」

「Cisco Unity 8.x でのパフォーマンスに対する期待の確定」

「Cisco Unity 8.x での オンボックスとオフボックスのメッセージ ストア環境でのパフォーマンス監視」

「Cisco Unity 8.x でのパフォーマンスの監視に必要な許可」

「Cisco Unity 8.x サーバと Cisco Unity メッセージ ストア サーバでの Network Provider Monitor の設定」

「Cisco Unity 8.x での Cisco Unity パフォーマンス情報ツールの設定」

「Cisco Unity 8.x のパフォーマンスに関する監視のガイドライン」

「Cisco Unity 8.x システムでのパフォーマンス テスト」

「Cisco Unity 8.x のテストに使用するパフォーマンス カウンタ」

「Cisco Unity 8.x のパフォーマンス カウンタのトラブルシューティング」

Cisco Unity 8.x のパフォーマンス監視の概要

パフォーマンス データは、トラブルシューティング、将来のシステム要件の予測、および Cisco Unity メッセージ インフラストラクチャの管理上の監視に有用です。パフォーマンス情報は、Cisco Unity 展開の健全性やスケーラビリティを判断するうえでも大きな役割を果たします。

Cisco Unity は、メッセージ サブシステム(Microsoft Exchange)に依存しています。メッセージ サブシステムで、障害、オフライン移行、機能低下、または使用不能化が起こった場合、Cisco Unity のユニファイド メッセージ機能とパフォーマンスが被害を受けます。このようにメッセージ インフラストラクチャに依存しているため、メッセージ ストアのアーキテクチャと Cisco Unity 展開の設計は、ユーザ エクスペリエンスへのパフォーマンス インパクトに関する最も重要な 2 つの検討要素となります。

Cisco Unity 8.x でのパフォーマンスの定義

クライアント/サーバ コンピューティングにおいて、パフォーマンスとは、コンピュータ動作の速度、効率、および最終的には応答性です。コンピューティング システムは論理的に交通道路網に例えられるため、交通の流れ(トラフィック フロー)はコンピューティングの良い例えになります。街の端から端への自動車移動は、輸送効率にとって特別な課題です。これは、コンピュータ システムの端から端へのデータ移動と同様です。タイミング、速度、負荷パターン、キューイング、システム効率などの問題はすべて、データ移動に影響を及ぼします。

ベースラインとは、比較の対象となる、観測され記録されたパフォーマンス測定値です。ベースラインは、記録後に過去または将来の測定値と積極的に比較される場合に限り有用となります。次に例を示します。

特定のパフォーマンス問題のトラブルシューティングを実行するために、システムのパフォーマンス特性をキャプチャする。

あるシステムが別のシステムより優れている点を理解するために、異種のシステムのパフォーマンス動作を比較する。

実稼動システムのキャパシティおよび将来の拡張のための計画支援として。

アプリケーション レベルでは、通常、コンピュータ パフォーマンスは次の 4 つのパフォーマンス要素に分類されます。

メモリ :測定されるシステムまたはアプリケーションが使用できる物理メモリの容量と速度

プロセッサ :システム CPU がコマンドをタイムリーかつ効率的に実行する能力

ディスク :物理的な固定ストレージ サブシステムの容量と速度

ネットワーク :ネットワークとのデータの送受信に関連する帯域幅と待ち時間

これら以外にもパフォーマンスの低下を引き起こす可能性のある要素があります。たとえば、熱、電磁放射、不良コンポーネントなどです。ただし、それらは、ここで取り扱うものより低レベルのコンピュータ設計および実装での検討材料です。

Cisco Unity 8.x でのパフォーマンスに対する期待の確定

ユニファイド メッセージ展開において、電子メール メッセージおよびボイス メッセージに対するユーザの期待は同じとは限りません。電子メール メッセージでは、完全には時間依存でない電子メール内のテキストまたはイメージの転送が必要です。許容可能な送信速度は、数秒から数分まで多岐に渡ります。その一方、ボイス メッセージではユーザにオーディオ情報をリアルタイムで転送することが必要で、遅延または待ち時間の発生が少ないことが要求されます。どのようなパフォーマンスを許容可能と見なすかは、サイトごとおよびユーザごとに異なります。パフォーマンスの監視に何が要求されるかを確定することは、許容可能なパフォーマンスを確定して伝達することに相当します。

サイトでは、業務需要の現実に照らして、メッセージ パフォーマンスに対するユーザの想定および期待を均一化する必要があります。メッセージ インフラストラクチャの堅実な設計および実装計画は、通常、期待を裏切らないための最良の防御策ですが、それでも問題は発生します。パフォーマンスの問題が発生する場合や期待が満たされない場合の一般的な原因は、次のとおりです。

システムに対する負荷の予測が最初から誤っていたか、当初の設計時から大幅に変わったため。たとえば、ビジネスが成功して拡大し、当初の展開計画における成長の見通しを上回り、結果的にユーザが増えてシステムが当初の設計パラメータを超える場合があります。

既存の電子メール メッセージ インフラストラクチャが、ユニファイド コミュニケーションのパフォーマンス ニーズを満たすことができないため。これは、必ずしも、音声通信によって発生する追加のオーバーヘッドがあることを意味しているわけではありません。単に、パフォーマンスの期待に対する許容度がかなり低いということです。

期待がどの程度満たされているかを測る正しい尺度は、単に、要求したサービスがソリューションによって提供されているかどうかを尋ねることです。そこから始めて、次に、アクセス可能性、応答速度、および他のサイト固有の要素についての質問を追加していきます。これらの質問は主観的であるため、答えるのが非常に難しいことに留意してください。

サーバおよびネットワーク(またはそのいずれか)のパフォーマンスは適切ですか。適切なパフォーマンスをどう定義しますか。

ユーザが不要な遅延を体験していませんか。不要な遅延とは何ですか。

パフォーマンスが不十分であった期間、または不要な遅延が発生していた期間、アプリケーション、サーバ、またはネットワークは何を実行していましたか。それは計画されていたことですか。どうすれば問題を切り分けることができますか。

Cisco Unity 8.x での オンボックスとオフボックスのメッセージ ストア環境でのパフォーマンス監視

Cisco Unity のアーキテクチャでは、音声通話処理を行う Cisco Unity サーバと同じ物理サーバ ハードウェア(オンボックス)に Cisco Unity メッセージ ストアを置く必要はありません。構成によっては、そのような配置が最適ではなく、またサポートされていない場合さえもあります (通常、オフボックス メッセージ ストア構成と呼ばれるのは、別個の物理サーバ(複数可)にユーザ メッセージを格納する Cisco Unity システムです)。オフボックス構成では、必要なパフォーマンス リソースを複数のシステムに分散させることで、パフォーマンス上の大きな利点が得られます。

他の実装設計と同様に、オフボックス構成に対する警告があります。たとえば、Cisco Unity とメッセージ ストア間の通信が行われるネットワークが、ボトルネックまたは障害ポイントとなる可能性があります。したがって、Cisco Unity によって使用されているサーバおよびメッセージ ストアをすべて監視して、パフォーマンスの問題がないかを確認する必要があります。このようなタスクに役立つよう、Cisco Unified Performance Information and Diagnostics(CUPID)ツール、Microsoft パフォーマンス モニタ、Microsoft Management Console(MMC; Microsoft 管理コンソール)にはそれぞれ、複数のサーバをリモートで一元管理する機能が用意されています。

Cisco Unity 8.x でのパフォーマンスの監視に必要な許可

監視対象の各サーバに対する管理特権が必要です。管理アカウントを使用するか、パフォーマンスの監視を担当する特定のアカウントまたはグループに次の最小限の許可を割り当ててください。

サービスとしてログオン(CUPID の監視の場合)

システム パフォーマンス プロファイル

ローカルでログオン(CUPID の設定およびパフォーマンス モニタの設定/監視の場合)

単一プロセス プロファイル

Network Provider Monitor のインストール(管理特権)

パフォーマンス モニタを使用してターゲット システムをリモートで監視できます。場合によっては、このような監視が必要となることもあります。ただし、「パフォーマンス ログと警告」サービスのサービス権限の問題やネットワーク接続の問題がテストの妨げになることがあります。したがって、可能な場合は、パフォーマンス テストをターゲット マシンでローカルに実行することを推奨します。

Cisco Unity 8.x サーバと Cisco Unity メッセージ ストア サーバでの Network Provider Monitor の設定

ネットワーク トラフィック情報をキャプチャするには、Network Monitor Provider のインストールが必要となることがあります。Network Monitor Provider はパフォーマンスに影響を及ぼすため、システムのオフピーク使用時に短時間でデータを収集することを推奨します。

Network Monitor Provider をインストールする


ステップ 1 Windows の [スタート(Start)] メニューで、[設定(Settings)] > [ネットワーク接続(Network Connections)] をクリックします。

ステップ 2 [ネットワーク接続(Network Connections)] ウィンドウで、ネットワーク接続を右クリックし、[プロパティ(Properties)] をクリックします。

ステップ 3 [接続のプロパティ(Connections Properties)] ダイアログボックスの [全般(General)] タブで、[インストール(Install)] をクリックします。

ステップ 4 [プロトコル(Protocol)] を選択し、[追加(Add)] をクリックします。

ステップ 5 [ネットワーク プロトコル ドライバの選択(Select Network Protocol Driver)] ウィンドウで、製造元のリストから [Microsoft] を選択します。

ステップ 6 リストから [ネットワーク モニタ ドライバ(Network Monitor Driver)] を選択し、[OK] をクリックします。

ステップ 7 [接続のプロパティ(Connections Properties)] ダイアログボックスで、[閉じる(Close)] をクリックします。

ステップ 8 [ネットワーク接続(Network Connections)] ウィンドウを閉じます。


 

Cisco Unity 8.x での Cisco Unity パフォーマンス情報ツールの設定

ローカル サーバ上での CUPID ユーティリティまたはパフォーマンス モニタの実行は、アクティブな半侵入型の監視形式です。ただし、その影響は、CUPID またはパフォーマンス モニタの長いサンプル間隔と比較的小さなアプリケーション フットプリントによって緩和されます。監視ツールのオーバーヘッドや負荷の影響は最小限である必要があり、結果の分析において識別不能である必要があります。

Cisco Unity の実行ファイルも Exchange または SQL Server からのデータも保持せず、かつ診断トレースとログ データの収集に使用できる十分な領域を持つ物理ディスクまたは論理ボリュームに、パフォーマンス ログ データをキャプチャすることを推奨します。そのようにすることで、トラフィックの多いシステム上のスループット問題が軽減されます。

Cisco Unity Performance Information and Diagnostics(CUPID)の設定

CUPID は、パフォーマンス情報と診断情報を収集するための Windows 用ユーティリティです。根本的には、CUPID は、Windows オペレーティング システムのパフォーマンス サブシステムと通信し、XML コンフィギュレーション ファイルに指定されているカウンタに基づいてデータを収集するサービスです。CUPID は、Tools Depot で利用できます。アップデートは、 http://www.CiscoUnityTools.com で定期的にダウンロード可能になります。

CUPID に使用されるコンフィギュレーション ファイルは、収集するカウンタを定義するいくつかの Counter 要素を含む XML ドキュメントから成ります。CUPID インストールに付属のコンフィギュレーション ファイルは、パフォーマンス テストを実行するときに収集する最新の推奨パフォーマンス カウンタを示します。テスト対象のシステム固有のニーズに合せてコンフィギュレーション ファイルを見直してください。通常のメッセージ アクティビティに加えて、サードパーティのバックアップ ソリューションやアンチウイルス ソリューションを監視するために追加のカウンタが必要となる場合もあります。

CUPID を使用してリモートで Cisco Unity または Cisco Unity メッセージ ストアのパフォーマンスを監視することはサポートされていないことに注意してください。詳細については、CUPID のオンライン ヘルプを参照してください。

CUPID のコンフィギュレーション設定を変更する


ステップ 1 Cisco Unity サーバのデスクトップ上にある [Cisco Unity Tools Depot] アイコンをダブルクリックします。

ステップ 2 左ペインで、[診断ツール(Diagnostic Tool)] の [CUPID] をダブルクリックします。このサーバで以前に CUPID を実行したことがない場合は、メッセージが表示されたら、CUPID サービスをインストールします。

ステップ 3 ご使用の構成のニーズに応じて、CUPID の設定オプションを選択します。

ステップ 4 ご使用の Cisco Unity 構成を反映する XML ファイルを選択するか、測定する構成のニーズに合う XML ドキュメントを手動で作成します。

ステップ 5 [変更を適用(Apply Changes)] をクリックします。

ステップ 6 [終了(Exit)] をクリックします。


 

システムの起動時に CUPID のパフォーマンス情報収集を自動的に開始する


ステップ 1 Windows の [スタート(Start)] メニューで、[すべてのプログラム(Programs)] > [管理サービス(Administrative Services)] > [サービス(Services)] をクリックします。

ステップ 2 [サービス(Services)] ウィンドウで、[Cisco Unity Performance Information and Diagnostics] を右クリックし、[プロパティ(Properties)] をクリックします。

ステップ 3 [全般(General)] タブの [スタートアップの種類(Startup Type)] フィールドで、[自動(Automatic)] をクリックします。

ステップ 4 [OK] をクリックします。

ステップ 5 [サービス(Services)] ウィンドウを閉じます。


 

パフォーマンス モニタの設定

Microsoft 管理コンソール(MMC)は、モジュラ式管理ツールの集まりで、ローカル システムまたはリモート システム上でさまざまな保守機能や管理機能を実行するための中央集中型インターフェイスを提供します。MMC のパフォーマンス モニタは、2 つのコンポーネントで構成されています。MMC には、一元管理を行ったり、カスタム インターフェイスやカスタム コンソールで共通のタスクを実行したりするための十分な柔軟性があります。

Cisco Unity を使用する管理者は、Active Directory ユーザーとコンピュータ、Exchange サーバ、または SQL サーバを扱う MMC の要素にアクセスする必要が生じることがあります。ただし、Cisco Unity のパフォーマンスを評価する場合、全体的な分析では、[システム モニタ(System Monitor)] コントロールと [パフォーマンス ログと警告(Performance Logs and Alerts)] コントロールで構成されるパフォーマンス モニタを使用することを推奨します。

システム モニタは、MMC コンソールに追加することも、Web ページや同様のドキュメントに組み込むこともできる ActiveX コントロール コンポーネントです。作成済みのコンソール バージョンのパフォーマンス モニタには、[システム モニタ(System Monitor)] コントロールと [パフォーマンス ログと警告(Performance Logs and Alerts)] コントロールの両方が含まれています。Windows リソース キットから、スタンドアロンの実行可能バージョンを入手することもできます。

Cisco Unity のパフォーマンス要素の中には、パフォーマンス モニタだけで測定するのが難しいまたは不可能なものがあることに注意してください。たとえば、Message Waiting Indication(MWI; メッセージ ウェイティング インジケータ)の応答時間、メッセージ送信速度、ディレクトリ検索や宛先検索の遅延などは、測定が難しいパフォーマンス要素です。一部の動作は大規模システムの分散要素(たとえば、ネットワーク帯域幅、リモート メッセージ ストア サーバのパフォーマンス、連動のパフォーマンス)に依存しているため、パフォーマンス モニタでは特定のパフォーマンス問題の一部しか表示できないことがあります。完全な Cisco Unity 実装の特性を明らかにするために必要なパフォーマンス情報を入手するには、追加のハードウェア ツールまたはソフトウェア ツール(ネットワーク パケット アナライザなど)および追加の方法が必要となることがあります。

作成済みコンソールとしてのパフォーマンス モニタを起動する


ステップ 1 Windows の [スタート(Start)] メニューで、[すべてのプログラム(Programs)] > [管理ツール(Administrative Tools)] > [パフォーマンス(Performance)] をクリックします。

[パフォーマンス モニタ(Performance Monitor)] が開きます。


 

MMC コンソールにパフォーマンス監視機能を組み込む


ステップ 1 Windows の [スタート(Start)] メニューの [ファイル名を指定して実行(Run)] をクリックします。

ステップ 2 mmc と入力し、[OK] をクリックします。

ステップ 3 [ファイル(File)] メニューで、[スナップインの追加と削除(Add/Remove Snap-In)] をクリックします。

ステップ 4 [スナップインの追加と削除(Add/Remove Snap-In)] ダイアログボックスで、[追加(Add)] をクリックします。

ステップ 5 [スタンドアロン スナップインの追加(Add Standalone Snap-In)] ダイアログボックスで、[パフォーマンス ログと警告(Performance Logs and Alerts)] コントロールを選択し、[追加(Add)] をクリックします。

ステップ 6 [スタンドアロン スナップインの追加(Add Standalone Snap-In)] ダイアログボックスで、[ActiveX コントロール(ActiveX Control)] を選択し、[追加(Add)] をクリックします。

ステップ 7 [ActiveX コントロールの挿入(Insert ActiveX Control)] ウィザードの [ようこそ(Welcome)] ページで、[次へ(Next)] をクリックします。

ステップ 8 [コントロールの分類と種類(Control Category and Type)] ページの [コントロールの分類(Control Categories)] リストで、[すべての分類(All Categories)] を選択します。

ステップ 9 [コントロールの種類(Control Type)] リストで、[システム モニタ コントロール(System Monitor Control)] を選択し、[次へ(Next)] をクリックします。

ステップ 10 [フレンドリ名(Friendly Name)] ページで、コントロールの名前を入力するか、デフォルト名を受け入れて、[完了(Finish)] をクリックします。

ステップ 11 [スタンドアロン スナップインの追加(Add Standalone Snap-In)] ダイアログボックスで、[閉じる(Close)] をクリックします。

ステップ 12 [スナップインの追加と削除(Add/Remove Snap-In)] ダイアログボックスで、[OK] をクリックします。

ステップ 13 [ファイル(File)] メニューで、[名前を付けて保存(Save As)] をクリックします。

ステップ 14 [名前を付けて保存(Save As)] ダイアログボックスの [ファイルの種類(Save As Type)] フィールドで、[Microsoft Management Console ファイル(*.msc)(Microsoft Management Console Files (*.msc))] を選択します。

ステップ 15 [ファイル名(File Name)] フィールドに、作成したコンソールの名前を入力し、[保存(Save)] をクリックします。

作成したコンソールを、後で使用できるようになります。


 

ドキュメントにパフォーマンス監視機能を組み込む


ステップ 1 OLE 対応ドキュメント(たとえば、Microsoft Word や Microsoft PowerPoint のドキュメント)を開きます。

ステップ 2 [挿入(Insert)] メニューで、[オブジェクト(Object)] をクリックします。

ステップ 3 [オブジェクト(Object)] ダイアログボックスで、[システム モニタ コントロール(System Monitor Control)] を選択し、[OK] をクリックします。

ステップ 4 組み込まれたコントロールを、必要に応じてサイズ変更および設定します。


 

Cisco Unity サーバ用のパフォーマンス モニタ設定

Microsoft パフォーマンス モニタを Cisco Unity 用に設定するには、適切なパフォーマンス カウンタをカウンタ ログに追加する必要があります。パフォーマンス監視プロセスを開始するために収集する必要のあるカウンタのリストについては、「必須のシステム パフォーマンス カウンタ」を参照してください。特定のパフォーマンス調査で目的を絞り込むには、追加のカウンタが必要になることがあります。

適切な手順を実行してください。

Cisco Unity サーバのリアルタイム パフォーマンス監視用にパフォーマンス モニタを手動で設定する


ステップ 1 Windows の [スタート(Start)] メニューで、[すべてのプログラム(Programs)] > [管理ツール(Administrative Tools)] > [パフォーマンス(Performance)] をクリックします。

ステップ 2 左ペインで、[システム モニタ(System Monitor)] をクリックします。

ステップ 3 右ペインで、適切なコントロールを右クリックします。

ステップ 4 ポップアップ メニューで、[プロパティ(Properties)] をクリックします。

ステップ 5 [システム モニタのプロパティ(System Monitor Properties)] ダイアログボックスの [全般(General)] タブで、[自動更新間隔(Update Automatically)] フィールドが 5 秒 以上に設定されていることを確認します。

ステップ 6 [システム モニタのプロパティ(System Monitor Properties)] ダイアログボックスの [データ(Data)] タブで、「必須のシステム パフォーマンス カウンタ」に示されているカウンタ、またはテストに必要な任意のカウンタを追加します。


 

データ収集(パフォーマンス監視ログ)用にパフォーマンス モニタを手動で設定する


ステップ 1 Windows の [スタート(Start)] メニューで、[すべてのプログラム(Programs)] > [管理ツール(Administrative Tools)] > [パフォーマンス(Performance)] をクリックします。

ステップ 2 左ペインで、[パフォーマンス ログと警告(Performance Logs and Alerts)] を展開します。

ステップ 3 [カウンタ ログ(Counter Logs)] を右クリックし、[新しいログの設定(New Log Settings)] をクリックします。

ステップ 4 [新しいログの設定(New Log Settings)] ダイアログボックスの [名前(Name)] フィールドに、新しいログの設定の名前を入力し、[OK] をクリックします。

ステップ 5 ダイアログボックスの [全般(General)] タブで、[カウンタの追加(Add Counters)] をクリックします。

ステップ 6 [カウンタの追加(Add Counters)] ダイアログボックスで、「必須のシステム パフォーマンス カウンタ」に示されているカウンタ、またはテストに必要な任意のカウンタを追加して、[追加(Add)] をクリックします。

ステップ 7 [閉じる(Close)] をクリックします。

ステップ 8 [全般(General)] タブで、[サンプル データの入力(Sample Data Every)] の [間隔(Interval)] フィールドに 5 と入力します。

ステップ 9 [単位(Units)] フィールドで、[分(Minutes)] をクリックします。

ステップ 10 [ログ ファイル(Log Files)] タブをクリックします。

ステップ 11 [ログ ファイルの種類(Log File Type)] フィールドで、[テキスト ファイル - CSV(Text File - (Comma Delimited))] をクリックします。


) カンマ区切り(CSV)ファイル形式を使用することを推奨します。CSV ファイルは、外部データ操作やスプレッドシート アプリケーション(Perl スクリプティングや Microsoft Excel など)に使用できるためです。


ステップ 12 必要に応じて追加のパラメータを設定します。

ステップ 13 [OK] をクリックします。


 

オフボックスの Cisco Unity メッセージ ストア サーバ用のパフォーマンス モニタ設定

通常、オフボックスの Cisco Unity メッセージ ストア サーバを監視している場合、ローカルの Cisco Unity プロセスを監視する必要はありません。その代わり、オペレーティング システムとメッセージ ストアのリソースだけを監視する必要があります。ただし、Microsoft Exchange プロセスがローカルで実行される Voice Messaging(VM; ボイス メッセージ)構成では、Cisco Unity と Exchange の両方を監視する必要があります。

監視する必要のあるメイン プロセスは、Cisco Unity サーバ上のすべてのデータベースのホームとなる情報ストア(Store.exe)です。Store.exe の使用率は、Cisco Unity システムのユーザ数、各データベースのサイズ、およびデータベースと格納域グループの数に正比例します。他の Exchange プロセスがメモリ リソースを消費する可能性があることに注意してください。

適切な手順を実行してください。

オフボックスのメッセージ ストア サーバのリアルタイム パフォーマンス監視用にパフォーマンス モニタを手動で設定する


ステップ 1 Windows の [スタート(Start)] メニューで、[すべてのプログラム(Programs)] > [管理ツール(Administrative Tools)] > [パフォーマンス(Performance)] をクリックします。

ステップ 2 左ペインで、[パフォーマンス ログと警告(Performance Logs and Alerts)] を展開し、[システム モニタ(System Monitor)] をクリックします。

ステップ 3 右ペインで、適切なコントロールを右クリックし、[プロパティ(Properties)] をクリックします。

ステップ 4 [システム モニタのプロパティ(System Monitor Properties)] ダイアログボックスで、[全般(General)] タブをクリックします。

ステップ 5 [自動サンプリング間隔(Sample Automatically Every)] フィールドに、 5 秒~ 10 秒の間の値を入力します。

ステップ 6 [データ(Data)] タブをクリックします。

ステップ 7 [追加(Add)] をクリックします。

ステップ 8 [カウンタの追加(Add Counters)] ダイアログボックスで、「必須のシステム パフォーマンス カウンタ」に示されているカウンタを選択し、[追加(Add)] をクリックします。

ステップ 9 [閉じる(Close)] をクリックします。

ステップ 10 [システム モニタのプロパティ(System Monitor Properties)] ダイアログボックスで、[OK] をクリックします。


 

データ収集パフォーマンス監視用にパフォーマンス モニタを手動で設定する


ステップ 1 Windows の [スタート(Start)] メニューで、[すべてのプログラム(Programs)] > [管理ツール(Administrative Tools)] > [パフォーマンス(Performance)] をクリックします。

ステップ 2 [パフォーマンス ログと警告(Performance Logs and Alerts)] コントロールを展開します。

ステップ 3 [カウンタ ログ(Counter Logs)] を右クリックし、[新しいログの設定(New Log Settings)] をクリックします。

ステップ 4 [新しいログの設定(New Log Settings)] ダイアログボックスの [名前(Name)] フィールドに、新しいログの設定の名前を入力し、[OK] をクリックします。

ステップ 5 ダイアログボックスの [全般(General)] タブで、[カウンタの追加(Add Counters)] をクリックします。

ステップ 6 [カウンタの追加(Add Counters)] ダイアログボックスで、「必須のシステム パフォーマンス カウンタ」に示されているカウンタを選択し、[追加(Add)] をクリックします。

ステップ 7 [閉じる(Close)] をクリックします。

ステップ 8 [全般(General)] タブで、[サンプル データの入力(Sample Data Every)] の [間隔(Interval)] フィールドに 5 と入力します。

ステップ 9 [単位(Units)] フィールドで、[分(Minutes)] をクリックします。

ステップ 10 [ログ ファイル(Log Files)] タブをクリックします。

ステップ 11 [ログ ファイルの種類(Log File Type)] フィールドで、[テキスト ファイル - CSV(Text File - (Comma Delimited))] をクリックします。


) カンマ区切り(CSV)ファイル形式を使用することを推奨します。CSV ファイルは、外部データ操作やスプレッドシート アプリケーション(Perl スクリプティングや Microsoft Excel など)に使用できるためです。


ステップ 12 必要に応じて追加のパラメータを設定します。

ステップ 13 [OK] をクリックします。


 

Cisco Unity 8.x のパフォーマンスに関する監視のガイドライン

健全でスケーラブルなメッセージ システムの主な要素の 1 つは、システムのアクティブな監視です。これを実現するための良い方法は、Cisco Unity によって使用されている各サーバの展開全体でサポートされるパフォーマンス保守ポリシーを実装することです。スケーラビリティ計画やキャパシティ監査の目的で、また、人事異動があっても手順が引き継がれるように、必要なパフォーマンス アクティビティをすべて文書化することも重要です。

次のタスクを含む綿密な計画を作成することを推奨します。

1. システムの健全性を示すための中核的な測定値を開発する。

2. パフォーマンスの監視に使用するツールと方法を定義し、ツールの使用方法を文書化する。

1 つのアプリケーション(CUPID やパフォーマンス モニタなど)を使用してメッセージ システムのパフォーマンスを監視することを決定できます。または、Cisco Unity とメッセージ システムの監視を管理上の既存の監視インフラストラクチャに組み込むことを選択することもできます。サードパーティの監視ソリューション(たとえば、SNMP や WMI を使用するもの)を、大規模なエンタープライズ環境で Cisco Unity とその他のシスコ製品を監視するために使用することもできます。

3. 監視期間を定義する。

これには、監視する時間枠の指定、および収集されたログの循環と確認を行うタイミングの決定が含まれます。たとえば、小規模な会社では、週末にメッセージ システムを監視する人員も、毎日欠かさずにメッセージ システムを監視する人員も確保できない場合があります。したがって、そのような会社では、通話量の最も多い時間である月曜日の朝にパフォーマンスのスナップショットを作成するように決定できます。

4. ベースラインを定義する。

パフォーマンス保守のベースラインは、通常の業務からの偏差を検出するために重要です。通常の業務は、一般的な営業日からの平均測定値として定義される必要があります。測定値は、監視対象のビジネス ソリューションに応じて、8 時間のコア時間、日中、終日(24 時間)、または特定のシフト時間のいずれかで収集できます。

5. 収集された情報を定期的に確認および精緻化する。

6. パフォーマンスに関する有用な警告および通知を設定する。

7. 問題解決ポリシーを確立する。

8. データ ウェアハウジング ポリシーを確立する。

アーカイブ保存する必要のあるデータを決定します。さらに、情報の保管場所およびアーカイブ期限を検討します。

Cisco Unity 8.x システムでのパフォーマンス テスト

パフォーマンス テストは、さまざまな状況が Cisco Unity サーバまたは Cisco Unity メッセージ ストアによって適切に処理されているかどうかを評価する際に有用です。たとえば、フェールオーバー動作中や、Web ベースのクライアントから大きな負荷がかかっているときや、非常に多くのユーザが初期登録するときなどに、Cisco Unity サーバのパフォーマンスを評価することが必要になる場合があります。


注意 アップグレード中、および電話システム連動の設定を変更しているときに、パフォーマンス監視サービス(CUPID または PerfMon)を実行しないでください。サービスを実行すると、アップグレード後または連動に対する変更後に、Cisco Unity 連動のパフォーマンス カウンタが使用できなくなることがあります。この問題が発生した場合は、「Cisco Unity 8.x のパフォーマンス カウンタのトラブルシューティング」を参照してください。

パフォーマンス テストのプロセス

問題を理解するには調査結果の再現性が重要であるという点で、パフォーマンス テストのプロセスは科学的な分析方法に似ています。ほとんどの場合、パフォーマンス テストのプロセスは循環的です。どの測定セッションでも、新しい問題や、当初の問題への対処法が生み出される可能性があります。テスト対象の動作を完全に理解するまで、サイクルを何度も繰り返さなければならない場合があります。

図 7-1 に示すパフォーマンス テスト プロセスを推奨ます。

図 7-1 推奨されるパフォーマンス テスト プロセス

 

テスト実施の準備

次のタスク リストで、パフォーマンス テストの準備として実行する必要のある高レベルのタスクについて詳細に説明します。

タスク リスト:パフォーマンス テストの準備

1. テスト基準を決定する。

Cisco Unity のアーキテクチャは複雑であるため、可能な場合は必ずテストの焦点を絞ることを推奨します。システム コンポーネント間のパフォーマンス依存関係により、すぐに調査が非常に複雑になることがあります。

2. テスト基準におけるユーザ フィードバックの役割を決定する。

一部の展開では、これがパフォーマンスを考慮するうえでの主要な問題になります。たとえば、ユーザ入力で最大の予測遅延またはシステム パフォーマンスしきい値が確立される場合があります。

3. パフォーマンス テストの目的を決定する。

たとえば、Cisco Unity のパフォーマンスを監視することで、既存の展開における低速な対話応答を調査したり、Cisco Unity のインストール準備として既存のメッセージ ストア インフラストラクチャのベースライン測定値を検証および収集したりすることが必要になる場合があります。

4. システム全体を監視するか、特定の機能または領域だけを監視するかを決定する。

1 つの機能を監視する場合は、必要な監視量を減らすことができる可能性があります。一方、システム レベルの監視では、広範なパフォーマンス データ ポイントが必要となることがあります。特定の領域がボトルネックになっていると思われますか。新しいハードウェアやソフトウェアの追加など、Cisco Unity システムに対する変更があり、その変更がパフォーマンスに影響を及ぼしていると思われる場合は、特定の領域を監視する必要があります。システム パフォーマンス全体を把握することは大切ですが、特定のボトルネックの原因を識別することが目的である場合は、調査の範囲を絞り込むことが重要であることに留意してください。

5. 測定期間を指定し、その情報をパフォーマンス ログとは別に記録する。

プリセットされた測定期間を指定すると、調査対象となる問題のフレーミングに役立ちます。たとえば、月曜日の朝に Cisco Unity にログインするときのアクセス時間が長すぎるが、火曜日の朝にはそのようなことはないとユーザから報告があった場合は、日曜日の午前 0 時から次の火曜日の午前 0 時までのサンプルを取ることを計画します。この情報によって、同じ結果セット内で、月曜日のデータと火曜日のデータを比較できます。また、開始、停止、および期間のサンプル時間をパフォーマンス ログとは別に記録することで、誤ったシステム時刻、同期化されていないシステム時刻、またはリモートのシステム時刻の問題を回避できます。

6. 適切なレベルの診断トレースを選択する。

パフォーマンス テストは、正常に稼動または設定されているターゲット システムに対して実施する必要があるため、ほとんどのパフォーマンス テストでは、Cisco TAC による指示がない限り、Cisco Unity の診断トレースを無効にすることを推奨します。

7. Cisco Unity 診断ツール(Diagnostic Tool)で診断トレースを設定する。「Cisco Unity Diagnostics Tool で診断トレースを設定する」を参照してください。

8. パフォーマンス監視ツールを起動する。「パフォーマンス監視ツールを起動する」を参照してください。

9. パフォーマンス モニタのカウンタ ログを開始する。「パフォーマンス モニタのカウンタ ログを開始する」を参照してください。

Cisco Unity Diagnostics Tool で診断トレースを設定する

ベスト プラクティスとして、パフォーマンス調査に直接関係する診断トレースと Cisco TAC から指示があった診断トレースを除き、すべての診断トレースを無効にすることを推奨します。


ステップ 1 Windows の [スタート(Start)] メニューで、[すべてのプログラム(Programs)] > [Cisco Unity] > [Cisco Unity 診断ツール(Diagnostic Tool)] をクリックします。

ステップ 2 システム固有のパフォーマンス調査に適切な、または Cisco TAC によって指定された、マクロ トレースまたはマイクロ トレースを選択します。

診断トレースの設定の詳細については、『 Troubleshooting Guide for Cisco Unity Release 8.x の「 Diagnostic Trace Utilities and Logs 」の章を参照してください。このマニュアルは、 http://www.cisco.com/en/US/docs/voice_ip_comm/unity/8x/troubleshooting/guide/8xcutsgx.html から入手できます。

Cisco TAC によって、ターゲット システムで追加のツール、診断、および手順を実行するように要求されることがあります。これらのいずれを実行しても、関連するパフォーマンスが影響を受ける可能性があります。


 

パフォーマンス監視ツールを起動する


ステップ 1 Cisco Unity サーバのデスクトップ上にある [Cisco Unity Tools Depot] アイコンをダブルクリックします。

ステップ 2 左ペインで、[診断ツール(Diagnostic Tool)] を展開し、[CUPID] をダブルクリックします。

ステップ 3 [ファイル(File)] メニューで、[サービスの開始(Start Service)] をクリックします。

ステップ 4 サービスが開始されるときにメッセージが表示されたら、[OK] をクリックします。


 

パフォーマンス モニタのカウンタ ログを開始する


ステップ 1 Windows の [スタート(Start)] メニューで、[すべてのプログラム(Programs)] > [管理ツール(Administrative Tools)] > [パフォーマンス(Performance)] をクリックします。

ステップ 2 左ペインで、[パフォーマンス ログと警告(Performance Logs and Alerts)] を展開し、[カウンタ ログ(Counter Logs)] をクリックします。

ステップ 3 右ペインで、「パフォーマンス モニタの設定」でテスト用に設定したカウンタ ログを右クリックし、[開始(Started)] をクリックします。


 

パフォーマンス テストの実施

パフォーマンス テストで再現される状況によっては、テストの実施にさまざまな期間のさまざまなアクティビティが伴うことがあります。テストの目的としては、1 つのアプリケーション プロセスのメモリ使用状況を把握するといった限定的な目的や、システム全体のパフォーマンスを把握するといった広範な目的が考えられます。

パフォーマンス テストが終了した後、パフォーマンス データの収集を停止して、動作オーバーヘッドを減らし、パフォーマンス ログに不要なデータが入力されないようにすることを推奨します。次の「テストを停止する」の手順を実行します。


) パフォーマンス モニタを使用している場合は、必要に応じてテストを繰り返すことができるように、作成済みまたは標準のコンソール設定を保存してください。


テストを停止する


ステップ 1 [CUPID] ウィンドウで、[ファイル(File)] メニューの [サービスの停止(Stop Service)] をクリックします。

ステップ 2 サービスが停止されるときにメッセージが表示されたら、[OK] をクリックします。


 

パフォーマンスの測定と記録データの収集

監視付きセッション中に作成されたデータ ファイルを見つけます。パフォーマンス モニタまたは適切なスプレッドシート アプリケーション(Microsoft Excel など)を使用して、収集されたデータを分析します。CUPID ログは、Microsoft パフォーマンス モニタでも Microsoft Excel でも開くことができます。

キャプチャされたパフォーマンス ログ ファイルをパフォーマンス モニタで開く


ステップ 1 Windows の [スタート(Start)] メニューで、[すべてのプログラム(Programs)] > [管理ツール(Administrative Tools)] > [パフォーマンス(Performance)] をクリックします。

ステップ 2 左ペインで、[システム モニタ(System Monitor)] をクリックします。

ステップ 3 右ペインで、適切なコントロールを右クリックし、[プロパティ(Properties)] をクリックします。

ステップ 4 [システム モニタのプロパティ(System Monitor Properties)] ダイアログボックスで、[ソース(Source)] タブをクリックします。

ステップ 5 [データ ソース(Data Source)] で、[ログ ファイル(Log File)] をクリックします。

ステップ 6 [追加(Add)] をクリックします。

ステップ 7 [ログ ファイルの選択(Select Log File)] ダイアログボックスで、分析するログ ファイルを参照します。

パフォーマンス モニタ ログのデフォルトの場所は C:¥PerfLogs です。

ステップ 8 [システム モニタのプロパティ(System Monitor Properties)] ダイアログボックスで、[データ(Data)] タブをクリックします。

ステップ 9 [追加(Add)] をクリックします。

ステップ 10 [カウンタの追加(Add Counters)] ダイアログボックスで、調査対象となるカウンタを選択し、[追加(Add)] をクリックします。

ログに記録されたカウンタだけを選択できることに注意してください。

ステップ 11 [閉じる(Close)] をクリックします。

ステップ 12 [システム モニタのプロパティ(System Monitor Properties)] ダイアログボックスで、調査対象ではないカウンタを選択し、[削除(Remove)] をクリックします。

ステップ 13 [OK] をクリックします。

[パフォーマンス(Performance)] ウィンドウの右ペインに、パフォーマンス ログ ファイルのデータが表示されます。


 

キャプチャされたパフォーマンス ログ ファイルを Microsoft Excel で開く


ステップ 1 Microsoft Excel を開きます。

ステップ 2 [ファイル(File)] メニューで、[開く(Open)] をクリックします。

ステップ 3 [開く(Open)] ダイアログボックスで、パフォーマンス テストで生成された CSV ファイルを参照し、[開く(Open)] をクリックします。

ファイルの最初の行は、ターゲット システムでパフォーマンス モニタによって追跡された使用可能なカウンタを示します。最初のカラムはサンプルの時刻を示します。各行のエントリは、システムで取られたサンプルです。この数値は、サンプリング間隔によって異なります。


 

テスト対象のシステムに関する情報の収集は、システムからのパフォーマンス データの収集と同様に重要です。ほとんどの場合は、Tools Depot から利用可能な Gather Cisco Unity System Information(GUSI)ツールを実行し、さらに Cisco Unity サーバと Cisco Unity メッセージ ストアの両方で Microsoft WinMSD を実行する必要があります。

これらのツールはどちらも、システムのパフォーマンスに影響を与える可能性があることに注意してください。可能な場合は、保守期間中にシステム テスト情報の収集を行うようにスケジューリングしてください。

Gather Cisco Unity System Information(GUSI)ツールを実行する


ステップ 1 Cisco Unity サーバのデスクトップ上にある [Cisco Unity Tools Depot] アイコンをダブルクリックします。

ステップ 2 左ペインで、[レポート ツール(Reporting Tools)] を展開し、[Gather Cisco Unity System Info] をダブルクリックします。[Gather Cisco Unity System Information] ユーティリティ ウィンドウにシステム情報が表示されます。

ステップ 3 [CAB ファイルを保存するディレクトリの選択(Select Directory to Save CAB File To)] フィールドに、Cisco Unity システム情報を含む CAB ファイルを保存するディレクトリへのパスを入力します。

ステップ 4 [ファイルに書き込み(Write to File)] をクリックし、システム情報を指定の場所に保存します。

ステップ 5 [Gather Cisco Unity System Information] ユーティリティ ウィンドウを閉じます。


 

WinMSD を実行する


ステップ 1 Windows の [スタート(Start)] メニューの [ファイル名を指定して実行(Run)] をクリックします。

ステップ 2 [ファイル名を指定して実行(Run)] ダイアログボックスで、 winmsd と入力し、[OK] をクリックします。

ステップ 3 [システム情報(System Information)] ウィンドウの左ペインで、[システムの概要(System Summary)] ウィンドウをクリックします。

ステップ 4 [ファイル(File)] メニューで、[エクスポート(Export)] をクリックします。

ステップ 5 エクスポートしたファイルを保存するディレクトリを参照します。

ステップ 6 [ファイル名(File Name)] フィールドに、エクスポートしたファイルの名前を入力し、[保存(Save)] をクリックします。


) 情報収集プロセスが完了するまでにかなり時間がかかることがあり、このプロセス中にプログラムがストールまたはハングしているように見える場合があります。


ステップ 7 [システム情報(System Information)] ウィンドウを閉じます。


 

イベント ログを収集する


ステップ 1 Windows の [スタート(Start)] メニューの [ファイル名を指定して実行(Run)] をクリックします。

ステップ 2 [ファイル名を指定して実行(Run)] ダイアログボックスで、 eventvwr と入力し、[OK] をクリックします。

ステップ 3 [イベント ビューア(Event Viewer)] ウィンドウの左ペインで、[アプリケーション(Application)] を右クリックし、[ログ ファイルの名前を付けて保存(Save Log File As)] をクリックします。

ステップ 4 [アプリケーションの名前を付けて保存(Save "Application" As)] ダイアログボックスで、後で参照するためにログ ファイルを保存するディレクトリを参照します。

ステップ 5 [ファイル名(File Name)] フィールドに、ログ ファイルの名前を入力し、[保存(Save)] をクリックします。

ステップ 6 [イベント ビューア(Event Viewer)] ウィンドウの左ペインで、[システム(System)] を右クリックし、[ログ ファイルの名前を付けて保存(Save Log File As)] をクリックします。

ステップ 7 [アプリケーションの名前を付けて保存(Save "Application" As)] ダイアログボックスで、後で参照するためにログ ファイルを保存するディレクトリを参照します。

ステップ 8 [ファイル名(File Name)] フィールドに、ログ ファイルの名前を入力し、[保存(Save)] をクリックします。

ステップ 9 [イベント ビューア(Event Viewer)] ウィンドウを閉じます。


 

収集したパフォーマンス テスト結果の分析

収集されたパフォーマンス テスト結果の分析は、Cisco Unity の全体的なパフォーマンスを把握するうえで非常に重要です。次のガイドラインに従うことにより、パフォーマンス テストで生成された情報を検証、理解、および評価できます。

収集されたデータを検証するには、キャプチャされたログ ファイルをパフォーマンス モニタまたはスプレッドシート アプリケーションで開き、データが実際に記録されていることを確認します。開いたドキュメントのカラムには、サンプルが取られた順にデータが表示されています(ほとんどのエントリの場合)。空白のカラムは、サンプル収集期間中ターゲット システムに存在しなかったオブジェクトまたはカウンタを示します。

Cisco Unity システムのパフォーマンスが低いことを示す、ユーザが認識可能な外部指標は、次のとおりです。

Cisco Unity にダイヤルインするときの予期しない遅延

ボイス メッセージにアクセスするとき、またはボイス メッセージを削除するときの予期しない遅延

ボイス プロンプト間の長い遅延

音声再生時の途切れ

Cisco Unity Assistant、Cisco Unity Administrator、および Cisco Unity Inbox のいずれかまたは複数の応答の遅れ

ローカルでログインしたときのウィンドウ リフレッシュまたは入力デバイスの応答の遅れ

これらの指標の一部、特に Cisco Unity カンバセーション中にユーザが体験する無音または遅延の量に焦点を当てているものは、主観的であることに注意してください。

Cisco Unity システムのパフォーマンスが低いことを示す指標の中には、管理上測定可能な次のような内部指標もあります。

プロセッサ使用率が非常に高い

メモリ ページングが多い

ディスク使用率が高い

メモリ使用量が不安定またはメモリ リークが発生している

ネットワーク帯域幅の消費量またはトラフィック キューイングが多い

ターゲット システムの初期評価用の主要オブジェクトは、Memory、Process、Processor、Telephony、および Cisco Unity パフォーマンス オブジェクトです。これらのオブジェクトには、システム アクティビティの確認に役立つ多くの中核的なデータ ポイントが含まれています。たとえば、Telephony オブジェクトを使用する場合、Current Incoming Calls カウンタと Current Outgoing Calls カウンタは Cisco Unity サーバへのコール アクティビティと Cisco Unity サーバからのコール アクティビティを示すため、平均的なボイス セッション トラフィックの優れた指標になります。

呼び出し期間、着信転送、Cisco Unity への電話システム転送などの情報を入手するには、Port Usage Analyzer ツール(Tools Depot から利用可能)を使用します。また、電話システム レポートやコール詳細レコードなど、外部の情報源を使用します。このデータを、Cisco Unity システムから収集されたデータと一緒に使用すると、監視対象期間中の電話システム アクティビティの全体像を把握できます。

少なくとも、次の電話システム情報を収集する必要があります。

呼び出し期間または平均保留時間

Cisco Unity ユーザに録音されたメッセージの平均長

Cisco Unity サーバに着信したコール種別の分布を示す統計情報(たとえば、一般の着信、転送(応答なし)、転送(通話中))

Web クライアントからシステムへのセッション トラフィックも収集する必要があります。この情報は、Cisco Unity Assistant、Cisco Unity Administrator、および Cisco Unity Inbox のログオンと接続を追跡できる Web Services オブジェクトを使用して入手できます。

修正措置計画

収集されたデータの分析を使用して、パフォーマンスを向上させるために焦点を当てることができる領域を特定します。Cisco Unity のベスト プラクティスを修正措置計画の基礎とすることもできます。

Cisco Unity のパフォーマンスに関する管理上のベスト プラクティス

次のベスト プラクティスに従うと、Cisco Unity のパフォーマンスに良い影響がもたらされます。

Cisco Unity サーバ上で関係のないサーバやアプリケーションを実行しないでください。

バックグラウンド処理用のプロセスを設定します。

メッセージ ストアでは、リアルタイムのウイルス スキャンを実装しないでください。メッセージ環境への接続ポイントでスキャンを実施します。

ユニファイド メッセージ ユーザに、100 MB または 1,000 個のメッセージを超える受信ボックスを持たせないようにします。ユーザがログオンしてメッセージを確認するときにメッセージがリアルタイムで処理されるため、メールボックスのサイズが Cisco Unity カンバセーションのパフォーマンスに直接影響します。特定のタイプのメッセージは非常に大きいことがあるため、比較的少ないメッセージを格納しているユーザのメールボックスでも、格納域制限を超過する場合があることに留意してください。

Unity<サーバ名> メールボックスに対してメールボックスのサイズ制限を設定しないでください。このメールボックスには、メッセージが格納されないようにする必要があることに注意してください。ただし、Exchange が誤って設定され、このメールボックスにサイズ制限がある場合、このメールボックスはすぐに一杯になって Cisco Unity のパフォーマンスに深刻な影響を及ぼす可能性があります。

Cisco Unity(Microsoft Exchange 版)に固有のベスト プラクティス

Cisco Unity(Microsoft Exchange 版)を使用する場合は、上記のベスト プラクティスの推奨事項に加えて、直列方式の MAPI 対話に関連する次のベスト プラクティスにも注意してください。

Cisco Unity は、Exchange サーバごとに 1 つの MAPI セッションを使用します。MAPI 通信プロセスは、直列/順次方式で実行されます。Exchange サーバに対して MAPI 要求が行われると、Cisco Unity は応答を待ちます。待機中、そのサーバに新しい MAPI 要求を行うことはできません。待機中、元の MAPI 要求が返されるかまたはタイムアウトになるまで(タイムアウト期間は 10 分を超える)、新しい MAPI 要求はキューイングされます。遅延の原因となる次の状況が確認されています。これらの状況が発生した場合は、できる限り迅速に回避または解決する必要があります。

ログのストール。Exchange メッセージ ストアに対する負荷が原因でトランザクション ログが作成される速度がディスクに書き込まれる速度よりも速い場合、ログのストールが発生します。トランザクション ログは重要であるため、ログがディスクに書き込まれるまで Exchange は停止します (詳細については、Microsoft 社のサポート記事 188676 を参照してください)。

Store.exe のユーザ ダンプ。Store.exe プロセスのユーザ ダンプは、ダンプが完了するまですべての MAPI I/O を停止します。Store.exe プロセスのユーザ ダンプは、Exchange のデバッグに使用されるまれな動作です。ユーザ ダンプ中、Exchange サーバは Cisco Unity で使用できるように見えます。

待ち時間。待ち時間とは、データが Cisco Unity と Exchange サーバ間のネットワークを通過するまでの所要時間と定義されます。

不十分なスループット。Cisco Unity と Exchange サーバ間の通信に必要なスループット量が、使用可能な量を超えた場合、この状況が発生します。不十分なスループットが発生した場合は、信頼できるスループットが達成されるまで、TCP/IP バックオフ アルゴリズムによって転送速度が引き下げられます。

パケット損失。データが Cisco Unity と Exchange サーバ間の移動中に失われたか、破壊されたか、または破損した場合、パケット損失となります。この状況が発生した場合は、データを再送信する必要があります。

修正措置計画を実装するためのシステム変更

収集されたパフォーマンス データの分析に基づいて、必要に応じて変更を行い、パフォーマンスを向上させるための決定事項を実装します。

識別されている問題の解決

パフォーマンス テストを再度実行し、実装した修正措置計画によってパフォーマンスが向上したかどうか、識別されているパフォーマンス問題が解決したかどうか、および新しいパフォーマンス問題が発生していないかどうかを確認します。

テスト サイクルの完了

調査結果、講じた修正措置、および再度実施したパフォーマンス テストの結果を文書化します。

Cisco Unity 8.x のテストに使用するパフォーマンス カウンタ

物理ディスクのパフォーマンス情報を監視するには、サーバ上のディスク パフォーマンス カウンタを有効にする必要があります。Windows では、物理ディスクのパフォーマンス カウンタがデフォルトで有効になっています。Cisco Unity のデータ ポイントを測定するためのパフォーマンス カウンタもデフォルトで有効になっています。

必須のシステム パフォーマンス カウンタ

次に示すカウンタは、任意の Cisco Unity サーバまたは Cisco Unity メッセージ ストアのパフォーマンス監視セッションから収集する必要があります。

\Cache\Data Map Hits%

\Memory\Available Bytes

\Memory\Commit Limit

\Memory\Committed Bytes

\Memory\Free System Page Table Entries

\Memory\Page Faults/sec

\Memory\Pages Input/sec

\Memory\Pages Output/sec

\Memory\Pages/sec

\Network Interface(*)\Bytes Received/sec

\Network Interface(*)\Bytes Sent/sec

\Paging File\% Usage Peak

\PhysicalDisk\% Disk Time

\PhysicalDisk\% Idle Time

\PhysicalDisk\Avg.Disk Bytes/Transfer

\PhysicalDisk\Avg.Disk Queue Length

\PhysicalDisk\Avg.Disk sec/Read

\PhysicalDisk\Avg.Disk sec/Write

\PhysicalDisk\Current Disk Queue Length

\PhysicalDisk\Disk Reads/sec

\PhysicalDisk\Disk Writes/sec

\Processor\% Interrupt Time

\Processor\% Privileged Time

\Processor\% Processor Time

\Processor\% User Time

\Processor\Interrupts/sec

\System\Processes

\System\Processor Queue Length

\System\System Calls/sec

\System\Threads

一般的なシステム パフォーマンス カウンタ

表 7-1 に、Cisco Unity サーバと Cisco Unity メッセージ ストアの両方に適用できるカウンタと、その推奨される安全値を示します。

 

表 7-1 一般的なシステム パフォーマンス カウンタ

オブジェクト
カウンタ
説明
推奨値

メモリ

Available Bytes

Available Bytes は、コンピュータ上で実行されているプロセスが使用できる物理メモリの量です。ゼロ メモリ リスト、空きメモリ リスト、およびスタンバイ メモリ リストの領域を合計して算出されます。

ゼロ メモリは、ゼロで埋められたメモリのページで、以前のプロセスが使用したデータを後のプロセスが参照しないようにします。

空きメモリは、使用可能なメモリです。

スタンバイ メモリは、ディスクへのルート上にあるプロセスのワーキング セット(物理メモリ)から削除されているが、再呼び出しが可能なメモリです。スタンバイ メモリは、平均値ではなく最後の観測値だけです。

Available Bytes の推奨値は、システムが必要とする使用可能メモリ量とアクティビティ タイプを反映する値です。ユニファイド メッセージの場合、使用可能なメモリが常に物理メモリの合計の約 8 分の 1 となっているシステムは、さらにメモリ トラブルシューティングを進める対象となります。また、このようなシステムはメモリ アップグレードの対象となることも考えられます。Available Bytes が 4 MB にまで落ちている場合は、メモリの問題があり、パフォーマンスが悪影響を受け始める可能性があります。Available Bytes が 1 MB まで落ちると、サーバのパフォーマンスが低下します。

メモリ

Free System Page Table Entries

Free System Page Table Entries(PTE)は、各仮想アドレスを対応する物理アドレスにマップするために使用されるが、現在システムで使用されていないページ テーブル エントリの数です。このカウンタは、最後の観測値だけを表示します。平均値ではありません。PTE プール サイズは、システムの起動時に自動的に決定されます。PTE プールが減るにつれて、システムの他の部分の機能が低下し、スレッドが作成されなくなったり、システムがストールしたり、その他のシステム障害が発生したりします。

システムの安定性を確保するには、Cisco Unity サーバ上の空き PTE の総数が 15,000 以上である必要があります。

メモリ

Page Faults/sec

Page Faults/sec は、プロセッサがページ フォルトを処理する全体的な率です。これは、1 秒あたりのページ フォルト数で測定されます。ページ フォルトは、プロセスが要求するコードまたはデータが、ワーキング セット(物理メモリ内の領域)に存在しない場合に発生します。このカウンタは、ハード フォルト(ディスク アクセスが必要)とソフト フォルト(物理メモリ内の別の場所でフォルト ページを検出)の両方を含みます。このカウンタは、最後の 2 つのサンプルで観測された値の差をサンプル間隔の持続時間で割った値を表示します。

この値を Pages Input/sec または Pages Output/sec の数値と照らして検討することによって、メモリ ボトルネックを識別することができます。ソフト フォルトは、必ずしもメモリ不足を示しているのではなく、単にシステムが非常にアクティブであることを示している場合もあります。一方、ハード フォルトは、実行する必要のあるプロセス タスク用の物理メモリが十分になく、動作を継続させるためにメモリと物理ディスクの間のページ移動が激化していることを示します。必然的に、この種のメモリ問題は、ページング ファイルがホームとする物理ディスクのアクティビティが対応して増加することを示します。ハード ページ フォルトを、システム上で発生しているフォルトの割合として算出するには、Page Inputs/sec を Page Faults/sec で割ります。

メモリ

Pages Input/sec

Pages Input/sec は、ハード ページ フォルトを解決するためにディスクから読み取られたページ数です (ハード ページ フォルトが発生するのは、プロセスが要求するコードまたはデータが、ワーキング セットにも物理メモリ内の別の場所にも存在せず、ディスクから取り出される必要がある場合です)。このカウンタは、システム全体の遅延を引き起こすフォルトのプライマリ インジケータとして設計されています。このカウンタは、(通常、アプリケーションが要求する)ファイル システム キャッシュ内のフォルト、および非キャッシュのマップされたメモリ ファイル内のフォルトを解決するために取り出されたページを含みます。このカウンタはページ数をカウントするため、変換せずに他のページ カウント(Page Faults/sec など)と比較できます。このカウンタは、最後の 2 つのサンプルで観測された値の差をサンプル間隔の持続時間で割った値を表示します。

このカウンタの値は、物理メモリに存在しないページの仮想メモリ要求を満たすために、物理ディスクから取り出されたページ数です(ハード ページ フォルト)。そのため、この値は小さいほど望ましい状態です。

メモリ

Pages Output/sec

Pages Output/sec は、物理メモリの領域を解放するためにディスクに書き込まれたページ数です。ページは、物理メモリ内で変更された場合にだけディスクに書き込まれるため、多くの場合、コードではなくデータを保持しています。物理メモリが不足している場合、Windows は領域を解放するためにより多くのページをディスクに書き戻します。このカウンタはページ数をカウントするため、変換せずに他のページ カウントと比較できます。このカウンタは、最後の 2 つのサンプルで観測された値の差をサンプル間隔の持続時間で割った値を表示します。

このカウンタは、物理ディスクへのページ移動を示す可能性のあるメモリ ページング アクティビティの追跡に役立ちます。Pages Output/sec の値が大きいと、メモリが不足している可能性があります。

メモリ

Pages/sec

このカウンタの値は、物理メモリに存在しないページの仮想メモリ要求を満たすための物理ディスク ページング アクティビティを示します。

このカウンタは、システム全体の遅延を引き起こすフォルトのプライマリ インジケータです。この値が小さいほど望ましい状態です。1 秒あたり平均 10 ページ未満である必要があります。

ネットワーク インターフェイス

Bytes Received/ sec

Bytes Received/sec は、インターフェイス上で 1 秒間に受信されたバイト数です(フレーム文字を含みます)。

この値は、ネットワーク インターフェイス上の使用可能帯域幅の 20 % を超えないことが必要です。

ネットワーク インターフェイス

Bytes Sent/sec

Bytes Sent/sec は、インターフェイス上で 1 秒間に送信されたバイト数です(フレーム文字を含みます)。

この値は、ネットワーク インターフェイス上の使用可能帯域幅の 50 % を超えないことが必要です。

プロセッサ

% Processor Time

% Processor Time は、プロセッサが非アイドル スレッドを実行している時間の割合です。このカウンタは、プロセッサ アクティビティのプライマリ インジケータとして設計されています。これは、各サンプル間隔でプロセッサがアイドル プロセスのスレッド実行に費やす時間を測定し、その値を 100 % から引いて算出されます (各プロセッサには、他のスレッドの実行準備ができていない場合にサイクルを消費するアイドル スレッドがあります)。これは、サンプル間隔で有用な処理に費やされた時間の割合と見なすことができます。このカウンタは、サンプル間隔中に観測されたビジー時間の平均割合を表示します。これは、サービスが非アクティブであった時間を監視し、その値を 100 % から引いて算出されます。

1 プロセッサあたりの高いアクティビティが、即座にプロセッサのボトルネックを示すわけではありません。値が常に 100 % または 100 % 近くになっている場合、プロセッサのボトルネックが発生している可能性があります。オンボックスの Exchange を搭載した Cisco Unity サーバの場合、この値は 75 ~ 80 % 以下であると理想的です。メッセージ ストアがオフボックスである場合、この値は 85 % を下回っていれば、動作基準内であると見なされます。

システム

Processor Queue Length

Processor Queue Length は、プロセッサ キューにあるスレッドの数です。コンピュータにプロセッサが複数ある場合でも、プロセッサ時間のキューは 1 つです。ディスク カウンタとは異なり、このカウンタは、実行中のスレッドではなく実行準備ができているスレッドだけをカウントします。このカウンタは、平均値ではなく最後の観測値だけを表示します。

システム上のプロセッサ数にもよりますが、通常は、この値がプロセッサ数の 2 倍を超えると、ボトルネックと見なされます。この値を % Processor Time と併せて確認すると、システム上のプロセッサ アクティビティを明確に把握できます。

Cisco Unity サーバのパフォーマンス カウンタ

表 7-2 に、Cisco Unity サーバの重要なカウンタと、その推奨される安全値を示します。

 

表 7-2 Cisco Unity サーバのパフォーマンス カウンタ

オブジェクト
カウンタ
説明
推奨値

Cisco Unity セッション(音声)

遅延 - ヘッダー取得

「遅延 - ヘッダー取得」は、Cisco Unity がメッセージ ヘッダー情報を収集しているときに、発信者が体験する遅延(0.1 秒単位)です。

これは主観的な値ですが、この値が 40(4 秒)を超えた場合は、遅延の原因を特定するためにさらに調査を実施する必要があります。

Cisco Unity セッション(音声)

遅延 - オープニング グリーティング

「遅延 - オープニング グリーティング」は、音声が聞こえるまでに発信者が体験する遅延(0.1 秒単位)です。システムが呼び出しを受け取ってから発信者へのオーディオ ストリームが開始されるまでの時間を測定します。

これは主観的な値ですが、この値が 40(4 秒)を超えた場合は、遅延の原因を特定するためにさらに調査を実施する必要があります。

Cisco Unity セッション(音声)

遅延 - ユーザ削除メッセージ

「遅延 - ユーザ削除メッセージ」は、メッセージを削除しようとしているときに、Cisco Unity ユーザが体験する遅延(0.1 秒単位)です。最後の削除メッセージ プロンプトが流れてから削除の確認をするまでの時間を測定します。

これは主観的な値ですが、この値が 40(4 秒)を超えた場合は、遅延の原因を特定するためにさらに調査を実施する必要があります。

Cisco Unity セッション(音声)

遅延 - ユーザのログオン

「遅延 - ユーザのログオン」は、ログオン時に Cisco Unity ユーザが体験する遅延(0.1 秒単位)です。ユーザ パスワードの最終キーが押されてから最初のメニュー プロンプトが流れるまでの時間を測定します。

これは主観的な値ですが、この値が 40(4 秒)を超えた場合は、遅延の原因を特定するためにさらに調査を実施する必要があります。

Cisco Unity セッション(音声)

遅延 - ユーザ メッセージ アクセス

「遅延 - ユーザ メッセージ アクセス」は、メッセージにアクセスしようとしているときに、Cisco Unity ユーザが体験する遅延(0.1 秒単位)です。ユーザがメッセージを聞くためにキーを押してから実際にメッセージが再生されるまでの時間を測定します。

これは主観的な値ですが、この値が 40(4 秒)を超えた場合は、遅延の原因を特定するためにさらに調査を実施する必要があります。

Cisco Unity セッション(音声)

遅延 - ユーザ録音メッセージ

「遅延 - ユーザ録音メッセージ」は、メッセージ録音をしようとしているときに、Cisco Unity ユーザが体験する遅延(0.1 秒単位)です。最後の録音メッセージ プロンプトが流れてから録音発信音が鳴るまでの時間を測定します。

これは主観的な値ですが、この値が 40(4 秒)を超えた場合は、遅延の原因を特定するためにさらに調査を実施する必要があります。

プロセス\ [Cisco Unity プロセス]

Private Bytes

Private Bytes は、各 Cisco Unity プロセスによって割り当てられており、他のプロセスと共有できない現在のバイト数です。

このカウンタの値は大幅に変動することがありますが、プライベート バイトが継続的に使用されて解放されないという状況(一般にメモリ リークと呼ばれる)が発生していないかどうか注意することが重要です。

たとえば、Cisco Unity システムを初めて使用している日のメモリ使用量が、当初メモリ リークの存在を示唆することがあります。これは、必要に応じてコンポーネントがロードされているためです。ただし、時間の経過とともに、メモリ使用量は横ばいになって安定します。

プロセス\ AvCsGateway

% Processor Time

ゲートウェイ(AvCsGateway)プロセスは、安全なインターフェイスをマネージャに提供します。このインターフェイスにより、外部プロセスは、マネージャの状態の問い合せ、マネージャの起動または停止、あるいは(許可されている場合)マネージャ コンポーネントに対する内部インターフェイスの要求を行うことができます。

% Processor Time の値は、平均 25 % を超えないことが必要です。超えている場合は、アクティビティがシステムの処理能力を上回っている可能性があります。

プロセス\ AvCsMgr

% Processor Time

マネージャ(AvCsMgr)は、中核的な音声処理システムで、他のすべての Cisco Unity コンポーネントを管理し、コンポーネントの状態を示し、他の内部および外部コンポーネントに対するインターフェイスを明確にします。

% Processor Time の値は、平均 60 % を超えないことが必要です。超えている場合は、アクティビティがシステムの処理能力を上回っている可能性があります。

プロセス\ AvCsMgr

Handle Count

AvCsMgr の Handle Count は、マネージャ プロセスによって現在使用されているハンドルの合計数です。この数値は、このプロセスの各スレッドによって現在開かれているハンドルの総数です。

最初の立ち上がり後、使用されているハンドル数は一定を保つ必要があります。最大値は 25,000 ハンドルを超えないことが必要です。

プロセス\ AvCsMgr

Virtual Bytes

Virtual Bytes は、マネージャ プロセスによって使用されている仮想アドレス領域の現在のサイズ(バイト単位)です。仮想領域は有限であるため、大量に使用されると、プロセスがライブラリをロードする能力が制限される可能性があります。

最初の立ち上がり後、仮想バイト数はほぼ一定を保つ必要があります。最大値は 1.65 GB を超えないことが必要です。

プロセス\ inetinfo

% Processor Time

Inetinfo プロセスは、Cisco Unity Administrator および Cisco Personal Communications Assistant アプリケーションに対するインターフェイスを提供します。

% Processor Time の値は、平均 25 % を超えないことが必要です。超えている場合は、アクティビティがシステムの処理能力を上回っている可能性があります。

テレフォニー

Current Incoming Calls

Current Incoming Calls カウンタは、Cisco Unity サーバに着信するコール アクティビティを測定します。Current Outgoing Calls と同様に、平均的なボイス セッション トラフィックの優れた指標です。

Incoming Calls の推奨値は、使用可能なポート数を反映する値です。すべての着信ポートが常にビジーであるシステムには、追加のポートが必要である可能性があります。

テレフォニー

Current Outgoing Calls

Current Outgoing Calls カウンタは、Cisco Unity サーバから発信するコール アクティビティです。Current Incoming Calls と同様に、平均的なボイス セッション トラフィックの優れた指標です。

Incoming Calls の推奨値は、使用可能なポート数を反映する値です。すべての発信ポートが常にビジーであるシステムには、追加のポートが必要である可能性があります。

Cisco Unity メッセージ ストアのパフォーマンス カウンタ

表 7-3 に、Cisco Unity メッセージ ストアの重要なカウンタと、その推奨される安全値を示します。

 

表 7-3 Cisco Unity メッセージ ストアのパフォーマンス カウンタ

オブジェクト
カウンタ
説明
推奨値

データベース

Log Record Stalls/sec

Log Record Stalls/sec は、ログ バッファが一杯であったためにログ バッファに追加できなかった 1 秒あたりのログ レコードの数です。

この値は、できる限り 0(ゼロ)に近い状態を保つ必要があります。一般的には、通常の動作中に記録された平均値が 2 を超える場合、ボトルネックを示します。

データベース

Table Opens/sec

Table Opens/sec は、1 秒あたりに開かれたデータベース テーブルの数です。

このカウンタは、全体的なシステム使用状況を示す優れたインジケータです。

物理ディスク

% Disk Time

% Disk Time は、選択したディスク ドライブが読み取り要求または書き込み要求の処理でビジー状態であった経過時間の割合です。

この値が継続的に 60 %(平均)を超える場合、システムのパフォーマンス調査が必要となることがあります。

物理ディスク

Avg. Disk sec/ Read

Avg. Disk sec/Read は、ディスクからのデータ読み取りの平均時間(秒単位)です。

.02 を超える平均値は、物理ディスクのボトルネックを示します。これはディスクから情報を読み取るために必要な時間を直接的に示すインジケータであるため、最大値に注意する必要があります。この値が急上昇した場合は、ディスクからの情報読み取りの遅延を示します。

物理ディスク

Avg. Disk sec/ Write

Avg. Disk sec/Write は、ディスクへのデータ書き込みの平均時間(秒単位)です。

.02 を超える平均値は、物理ディスクのボトルネックを示します。これはディスクに情報を書き込むために必要な時間を直接的に示すインジケータであるため、最大値に注意する必要があります。この値が急上昇した場合は、ディスクへの情報書き込みの遅延を示します。

物理ディスク

Current Disk Queue Length

Current Disk Queue Length は、パフォーマンス データの収集時にディスクに残っていた未処理の要求数です。マルチスピンドル ディスク デバイスは一度に複数の要求をアクティブにできますが、その他の同時要求は処理待ちになります。このカウンタが表示するキューの長さの値は一時的に大きくなったり小さくなったりすることがありますが、ディスク ドライブに対して継続的に負荷がかかっている場合、この値が常に大きい状態となる可能性があります。要求は、このキューの長さとディスク上のスピンドル数の差に比例して遅延します。

この値は、平均 2 ~ 4 を超えないことが必要です。これはオペレーティング システム レベルで測定される値であるため、ドライバ レベルでのキューの遅延がパフォーマンスに影響を及ぼす可能性があります。

Cisco Unity 8.x のパフォーマンス カウンタのトラブルシューティング

パフォーマンス監視サービス(CUPID または PerfMon)の実行中にアップグレードまたは電話システム連動に対する変更を行うと、アップグレード後または連動に対する変更後に、Cisco Unity 連動のパフォーマンス カウンタが使用できなくなることがあります。

アップグレード後または電話システム連動に対する変更後にパフォーマンス カウンタを再び有効にする


ステップ 1 Cisco Unity サーバで、Windows の [スタート(Start)] メニューから、[すべてのプログラム(Programs)] > [管理ツール(Administrative Tools)] > [サービス(Services)] をクリックします。

ステップ 2 [サービス(Services)] ウィンドウの右ペインで、Cisco Unified Performance Information and Diagnostics サービスを探します。

Cisco Unified Performance Information and Diagnostics サービスが Cisco Unity サーバにインストールされていない場合は、この手順の残りのステップは省略してください。

ステップ 3 [Cisco Unified Performance Information and Diagnostics] をダブルクリックします。

ステップ 4 [Cisco Unified Performance Information and Diagnostics のプロパティ(Cisco Unified Performance Information and Diagnostics Properties)] ダイアログボックスの [サービスの状態(Service Status)] で [停止(Stop)] をクリックします。

ステップ 5 [スタートアップの種類(Startup Type)] フィールドで、[手動(Manual)] をクリックします。

ステップ 6 [OK] をクリックします。

ステップ 7 [サービス(Services)] ウィンドウを閉じます。

ステップ 8 Windows の [スタート(Start)] メニューで、[すべてのプログラム(Programs)] > [管理ツール(Administrative Tools)] > [パフォーマンス(Performance)] をクリックします。

ステップ 9 [パフォーマンス(Performance)] ウィンドウの左ペインで [パフォーマンス ログと警告(Performance Logs and Alerts)] を展開し、[カウンタ ログ(Counter Logs)] をクリックします。

ステップ 10 右ペインで、最初のカウンタ ログを右クリックし、[停止(Stop)] をクリックします。

ステップ 11 残りのすべてのカウンタ ログについて、ステップ 10 を繰り返します。

ステップ 12 左ペインで、[トレース ログ(Trace Logs)] をクリックします。

ステップ 13 右ペインで、最初のトレース ログを右クリックし、[停止(Stop)] をクリックします。

ステップ 14 残りのすべてのトレース ログについて、ステップ 13 を繰り返します。

ステップ 15 [パフォーマンス(Performance)] ウィンドウを閉じます。

ステップ 16 Windows の [スタート(Start)] メニューの [ファイル名を指定して実行(Run)] をクリックします。

ステップ 17 regedit と入力し、[OK] を押します。


注意 間違ったレジストリ キーを変更、または不正な値を入力すると、サーバが正しく動作しなくなることがあります。レジストリを編集する前に、問題が発生した場合にレジストリを復元する方法を知っておく必要があります (レジストリ エディタ ヘルプの「Restoring」トピックを参照してください)。レジストリの変更は複製されないため、Cisco Unity フェールオーバーが設定されている状況で、一方の Cisco Unity サーバでレジストリを変更した場合は、手動でもう一方の Cisco Unity サーバのレジストリも変更する必要があることにも注意してください。レジストリ キー設定の変更に関する質問がある場合は、Cisco TAC に連絡してください。

ステップ 18 現在のレジストリのバックアップがない場合は、[レジストリ(Registry)] > [レジストリ ファイルのエクスポート(Export Registry File)] をクリックし、レジストリ設定をファイルに保存します。

ステップ 19 次の場所にある PerformanceCounterVariables レジストリ キーを削除します。

HKEY_LOCAL_MACHINE¥Software¥Active Voice¥AvLogMgr¥1.0¥PerformanceCounterVariables
 

ステップ 20 レジストリ エディタを閉じます。

ステップ 21 Cisco Unity サーバを再起動します。

Cisco Unity の再起動後、Cisco Unity 連動のパフォーマンス カウンタが使用できるようになり、ステップ 19 で削除したレジストリ キーが自動的に再作成されます。