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

目次

パフォーマンスの監視

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

パフォーマンスの定義

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

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

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

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

パフォーマンス情報ツールの設定

Performance Information and Diagnostics(CUPID)の設定

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

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

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

のパフォーマンスに関する管理上の監視のガイドライン

パフォーマンス テスト

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

テスト実施の準備

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

テストの実施

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

パフォーマンス テスト結果の分析

修正措置計画の開発

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

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

テスト サイクルの完了

パフォーマンス カウンタ

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

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

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

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

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

パフォーマンスの監視

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

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

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

パフォーマンスの定義

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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 管理コンソール)にはそれぞれ、複数のサーバをリモートで一元管理する機能が用意されています。

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

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

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

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

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

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

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

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

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

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

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


ステップ 1 Windows の[スタート]メニューで、 [設定] >[コントロール パネル] >[ネットワークとダイヤルアップ接続] >[<ご使用のネットワーク アダプタ接続> ]をクリックします。

ステップ 2 [接続状態]ダイアログボックスで、 [プロパティ] をクリックします。

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

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

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

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


 

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

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

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

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

CUPID は、パフォーマンス情報と診断情報を収集するための Windows 用ユーティリティです。根本的には、CUPID は、Windows オペレーティング システムのパフォーマンス サブシステムと通信し、XML コンフィギュレーション ファイルに指定されているカウンタに基づいてデータを収集するサービスです。CUPID は、Cisco Unity バージョン 4.0(3) 以降の 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 ドキュメントを手動で作成します。


 

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


ステップ 1 [サービス]コントロール パネル アプレットを開きます。

ステップ 2 [Cisco Unity Performance Information and Diagnostics] サービスを選択します。

ステップ 3 そのサービスを右クリックし、 [プロパティ] を選択します。

ステップ 4 [スタートアップの種類]を [自動] に設定します。


 

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

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

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

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

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

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


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


 

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


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

ステップ 2 mmc と入力し、 Enter キーを押します。

ステップ 3 アプリケーション メニューで、 [コンソール] >[スナップインの追加と削除] をクリックします。

ステップ 4 [スナップインの追加と削除]ダイアログボックスで、 [追加] をクリックします。

ステップ 5 [スタンドアロン スナップインの追加]ダイアログボックスで、 [パフォーマンス ログと警告] コントロールを選択し、 [追加] をクリックします。

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

ステップ 7 [ActiveX コントロールの挿入]ウィザードで、 [次へ] をクリックします。

ステップ 8 [コントロールの分類]リストで、 [すべての分類] を選択します。

ステップ 9 [コントロールの種類]リストで、 [System Monitor Control] を選択します。

ステップ 10 コントロールの名前を選択するか、デフォルト名を受け入れて、 [完了] をクリックします。

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

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

ステップ 13 作成したコンソールを、後で使用するために MSC ファイルに保存します。


 

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


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

ステップ 2 アプリケーション メニューで、 [挿入] >[オブジェクト] をクリックします。

ステップ 3 [オブジェクトの挿入]ダイアログボックスで、 [System Monitor Control] を選択し、 [OK] をクリックします。

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


 

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

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

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


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

ステップ 2 ツリー ビューで、 [システム モニタ] をクリックします。

ステップ 3 右のパネルのコントロール ビューで、適切なコントロールを右クリックします。

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

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

ステップ 6 [システム モニタのプロパティ]ダイアログボックスの[データ]タブで、 表7-1 に示されているカウンタ、またはテストに必要な任意のカウンタを追加します。


 

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


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

ステップ 2 [パフォーマンス ログと警告]コントロールを展開し、 [カウンタ ログ] をクリックします。

ステップ 3 [カウンタ ログ] を右クリックします。

ステップ 4 ポップアップ メニューで、 [新しいログの設定] をクリックします。

ステップ 5 新しいログの設定の名前を入力し、 [OK] をクリックします。

ステップ 6 ダイアログボックスの[全般]タブで、 表7-1 に示されているカウンタ、またはテストに必要な任意のカウンタを追加します。

ステップ 7 [データのサンプル間隔]を 5 分 に設定します。

ステップ 8 ダイアログボックスの[ログ ファイル]タブで、[ログ ファイルの種類]を [テキスト ファイル - CSV] に変更します。


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


ステップ 9 CSV ファイルの最大サイズを 10000K に設定します。

ステップ 10 最大ファイル サイズに達したときに新しいログ ファイルを開始するためのオプションを選択します。

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


 

オフボックスの 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 の[スタート]メニューで、 [プログラム] >[管理ツール] >[パフォーマンス] をクリックします。

ステップ 2 ツリー ビューで、 [システム モニタ] をクリックします。

ステップ 3 右のパネルのコントロール ビューで、適切なコントロールを右クリックします。

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

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

ステップ 6 [システム モニタのプロパティ]ダイアログボックスの[データ]タブで、 表7-1 に示されているカウンタを追加します。


 

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


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

ステップ 2 [パフォーマンス ログと警告]コントロールを展開し、 [カウンタ ログ] をクリックします。

ステップ 3 [カウンタ ログ] を右クリックします。

ステップ 4 ポップアップ メニューで、 [新しいログの設定] をクリックします。

ステップ 5 新しいログの設定の名前を入力し、 [OK] をクリックします。

ステップ 6 ダイアログボックスの[全般]タブで、 表7-1 に示されているカウンタを追加します。

ステップ 7 [データのサンプル間隔]を 5 分 に設定します。

ステップ 8 ダイアログボックスの[ログ ファイル]タブで、[ログ ファイルの種類]を [テキスト ファイル - CSV] に変更します。

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


 

Cisco Unity のパフォーマンスに関する管理上の監視のガイドライン

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

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

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

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

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

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

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

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

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

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

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

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

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

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

パフォーマンス テスト

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


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

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

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

図7-1 に示すパフォーマンス テスト プロセスをお勧めします。

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

 

テスト実施の準備

次の「タスク リスト:パフォーマンス テストの準備」で、パフォーマンス テストの準備として実行する必要のある高レベルのタスクについて詳細に説明します。次の各手順も参照してください。

「Cisco Unity Diagnostic Tool で診断トレースを設定する」

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


ステップ 1 Windows の[スタート]メニューで、 [プログラム] >[Cisco Unity] >[Cisco Unity Diagnostic Tool] をクリックします。

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

パフォーマンスの問題がポート ロックアップの原因であると思われる場合は、 [System Locks] マクロ トレースを選択することをお勧めします。

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


 

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


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

ステップ 2 左ペインで、[Diagnostic Tool]の [CUPID] をダブルクリックします。


 

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


ステップ 1 Microsoft パフォーマンス モニタ を開きます。

ステップ 2 「Microsoft パフォーマンス モニタの設定」でテスト用に準備した カウンタ ログ を右クリックします。

ステップ 3 ポップアップ メニューで、 [開始] をクリックします。


 

テストの実施

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

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


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


テストを停止する


ステップ 1 Windows の[スタート]メニューで、CUPID コントロール アプリケーションを開き、 [ファイル] >[Stop Service] をクリックします。

ステップ 2 適切なパフォーマンス モニタ カウンタ ログ(複数可)を右クリックし、ポップアップ メニューで [停止] をクリックします。


 

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

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

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


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

ステップ 2 ツリー ビューで、 [システム モニタ] をクリックします。

ステップ 3 右のパネルのコントロール ビューで、適切なコントロールを右クリックします。

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

ステップ 5 [システム モニタのプロパティ]ダイアログボックスの[ソース]タブで、 [ログ ファイル] をクリックします。

ステップ 6 分析するログ ファイルを参照します。

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

ステップ 7 [システム モニタのプロパティ]ダイアログボックスの[データ]タブで、調査対象のカウンタを追加します。ログに記録されたカウンタだけを選択できることに注意してください。


 

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


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

ステップ 2 アプリケーション メニューで、 [ファイル] >[開く] をクリックします。

ステップ 3 パフォーマンス テストで生成された CSV ファイルを参照します。

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


 

テスト対象のシステムに関する情報の収集は、システムからのパフォーマンス データの収集と同様に重要です。ほとんどの場合は、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 Unity System Info] をダブルクリックします。

ステップ 3 Gather Cisco Unity System Information ユーティリティを実行します。

ステップ 4 Cisco Unity のシステム情報を含む .CAB ファイルの場所を選択します。

ステップ 5 [Write to File] をクリックし、指定した場所にシステム情報を保存します。


 

WinMSD を実行する


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

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

ステップ 3 [システム情報]ルートを右クリックし、 [テキスト ファイルとして保存] を選択します。

ステップ 4 比較と参照のために、生成されたテキスト ファイルを収集されたパフォーマンス データと一緒に保存します。


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



 

イベント ログを収集する


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

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

ステップ 3 [アプリケーション ログ]を右クリックし、 [ログ ファイルの名前を付けて保存] を選択します。

ステップ 4 後で参照するためにログ ファイルを保存します。

ステップ 5 [システム ログ]を右クリックし、 [ログ ファイルの名前を付けて保存] を選択します。

ステップ 6 後で参照するためにログ ファイルを保存します。


 

パフォーマンス テスト結果の分析

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

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

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

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

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

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

音声再生時の途切れ

Cisco Unity Assistant、Cisco Unity システム管理、および 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 システム管理、および 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 サーバ間の移動中に失われたか、破壊されたか、または破損した場合、パケット損失となります。この状況が発生した場合は、データを再送信する必要があります。

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

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

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

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

テスト サイクルの完了

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

パフォーマンス カウンタ

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

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

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

 

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

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

\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(_Total)\% Usage Peak

\PhysicalDisk(_Total)\% Disk Time

\PhysicalDisk(_Total)\Avg.Disk Bytes/Transfer

\PhysicalDisk(_Total)\Avg.Disk Queue Length

\PhysicalDisk(_Total)\Avg.Disk sec/Read

\PhysicalDisk(_Total)\Avg.Disk sec/Write

\PhysicalDisk(_Total)\Current Disk Queue Length

\PhysicalDisk(_Total)\Disk Reads/sec

\PhysicalDisk(_Total)\Disk Writes/sec

\System\Processes

\System\Processor Queue Length

\System\System Calls/sec

\System\Threads

\Processor(_Total)\% Interrupt Time

\Processor(_Total)\% Processor Time

\Processor(_Total)\Interrupts/sec

\Processor(_Total)\% Privileged Time

\Processor(_Total)\% User Time

\PhysicalDisk(_Total)\% Idle Time

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

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

 

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

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

メモリ

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-3 に、Cisco Unity サーバの重要なカウンタと、その推奨される安全値を示します。

 

表7-3 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: セッション(音声)

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

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

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

Cisco Unity: セッション(音声)

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

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

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

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

Private Bytes

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

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

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

プロセス\ AvCsMgr

% Processor Time

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

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

プロセス\ AvCsGateway

% Processor Time

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

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

プロセス\ AvCsMgr

Handle Count

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

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

プロセス\ AvCsMgr

Virtual Bytes

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

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

プロセス\ inetinfo

% Processor Time

Inetinfo プロセスは、Cisco Unity システム管理および 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 と同様に、平均的なボイス セッション トラフィックの優れた指標です。

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

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

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

 

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

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

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

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


ステップ 1 Cisco Unity サーバで、 [スタート] >[プログラム] >[管理ツール] >[サービス] をクリックします。

ステップ 2 Cisco Unity Performance Information and Diagnostics サービスが Cisco Unity サーバにインストールされている場合は、このサービスを停止します。

ステップ 3 Cisco Unity Performance Information and Diagnostics サービスの[スタートアップの種類]を[手動]に設定します。

ステップ 4 [スタート] >[プログラム] >[管理ツール] >[パフォーマンス] をクリックします。

ステップ 5 動作中のカウンタまたはトレース ログを停止します。

ステップ 6 Regedit を起動します。


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

ステップ 7 現在のレジストリのバックアップがない場合は、 [レジストリ]>[レジストリ ファイルの書き出し] をクリックし、レジストリ設定をファイルに保存します。

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

HKLM\Software\Active Voice\AvLogMgr\1.0\PerformanceCounterVariables

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

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