test

Sun Identity Manager 8.1 システム管理者ガイド

第 4 章 チューニングの実行

適切にチューニングを行えば、ほぼすべての動作に渡って Sun Identity Manager (Identity Manager) ソフトウェアのパフォーマンスを大幅に向上させることができます。このソフトウェア内の設定を変更する以外にも、アプリケーションサーバー、JavaTM Virtual Machine (JVMTM マシン)、ハードウェア、オペレーティングシステム、およびネットワークトポロジをチューニングすることによって、パフォーマンスを向上させることができます。

また、パフォーマンスの診断や監視には、複数のツールを使用することもできます。トレースやメソッドタイマーなど、パフォーマンスの診断や監視を行うための複数のツールが Identity Manager 内に用意されています。また、ほかの Sun Microsystems のツールや他社製のツールを使用して、Identity Manager のパフォーマンスに関する問題をデバッグすることもできます。

この章では、パフォーマンスの向上とパフォーマンス関連問題のデバッグに使用できるツール、方法、および参考資料について説明します。

注 –

チューニング処理は、多数のエンティティーに渡り、配備環境によって変わります。この章では、Identity Manager のパフォーマンスを最適化する各種チューニング方法を説明しますが、これらの方法はガイドラインとしてのみご利用ください。これらの方法は配備環境に応じて調整することが必要な場合があります。

この章では、次のトピックについて説明します。

チューニングを開始する前に

Identity Manager のチューニングを開始する前に、ここで説明することにすべて目を通してください。

重要な注意点

注 –

この章で説明するチューニング方法は、ガイドラインとしてのみご利用ください。配備に合わせてこれらのチューニングの一部の変更が必要になる場合があります。さらに、本稼働環境に変更内容を適用する前に、チューニング内容を必ず検証しておいてください。

Identity Manager をチューニングする前に、次の項目が必要です。

関連ドキュメントと Web サイト

Identity Manager のチューニングに関しては、この章の説明のほかに、この節で紹介しているドキュメントや Web サイトも参照してください。

推奨ドキュメント

パフォーマンスのチューニングについては、次のドキュメントを参照してください。

表 4–1 関連ドキュメント

ドキュメントのタイトル 

説明 

『IBM Developer Kit and Runtime Environment, Java Technology Edition, Version 5.0 Diagnostics Guide』

AIX JVM を使用したパフォーマンス問題の診断方法について説明します。  

『Java Tuning White Paper』

Java パフォーマンスのチューニングに関する情報、テクニック、およびポインタが記載されています。  

『Oracle MetaLink: Note:114671.1: Gathering Statistics for the Cost Based Optimizer』

システム統計と Oracle ® の Cost-Based Optimizer (CBO) の使用方法について説明します。

注意: このドキュメントは、Oracle Metalink 購読者が入手できるものです。登録が必要です。

『Solaris Dynamic Tracing Guide』

DTrace を使用したシステム動作の監視、デバッグ、およびチューニング方法について説明します。 

『Sun JavaTM System Application Server Performance Tuning Guide』

お使いの Sun Java System アプリケーションサーバーから最適なパフォーマンスを得る方法について説明します。Sun Microsystems ドキュメント Web サイト から、必要なバージョンの本書をダウンロードしてください。

『Tuning Garbage Collection with the 5.0 Java Virtual Machine』

JVM を使用したガベージコレクションアプリケーションのチューニング方法について説明します。 

『Turbo-charging Java HotSpot Virtual Machine, v1.4.x to Improve the Performance and Scalability of Application Servers』

PrintGCStats スクリプトのダウンロード方法と使用方法、および JVM チューニングを最適なものにするための統計を収集する方法について説明します。

『Understanding System Statistics』

Oracle の Cost-Based Optimizer がシステム統計を使用する仕組みについて説明します。 

『Using JConsole to Monitor Applications』

JConsole を使用して、Java プラットフォームで実行中のアプリケーションの監視方法について説明します。 

有用な Web サイト

Identity Manager パフォーマンスをチューニングする際に有用と思われる Web サイトをいくつか次の表に示します。

表 4–2 有用な Web サイト

Web サイト URL 

説明 

http://sunsolve.sun.com/

診断ツール、フォーラム、機能と記事、セキュリティー情報、パッチの内容を含む Sun の Web サイト。 

注意: このサイトの情報は、次の 3 分野に分かれています。

  • 社内。Sun 従業員のみ。

  • 契約。契約アクセス権をお持ちのお客様のみ。

  • 公開。すべての人に公開。

http://forum.java.sun.com/

フォーラムを参照したり、質問を投稿したりできる SDN (Sun Developer Network) Web サイト。 

http://jrat.sourceforge.net/

Java プラットフォーム用オープンソースのパフォーマンスプロファイラである Java Runtime Analysis Toolkit の使用方法を説明する JRat Web サイト。 

https://metalink.oracle.com/

Oracle データベースのチューニング情報を記載した、Oracle の社内フォーラムサイト。 

注意: このサイトに記載されている情報にアクセスするには、Oracle Metalink の購読者になる必要があります。

http://performance.netbeans.org/howto/jvmswitches/index.html

パフォーマンスの向上に役立つ JVM スイッチのチューニング情報が記載された NetBeansTM Web サイト。

https://sharespace.sun.com/gm/folder-1.11.60181?

Sun の Share Space の Identity Manager リンク。 

注意: このサイトに記載されている情報にアクセスするには、Share Space ID を登録する必要があります。

https://sharespace.sun.com/gm/document-1.26.2296

Sun の Share Space の Identity Manager FAQ。 

注意: この FAQ にアクセスするには、Share Space ID を登録する必要があります。

http://www.slamd.com/

SLAMD Distributed Load Generation Engine の Web サイト。 

http://www.opensolaris.org/os/community/dtrace/

OpenSolaris Community: DTrace の Web ページ。 

http://www.solarisinternals.com/

http://docs.sun.com/app/docs/prod/solaris.10

Solaris OS のチューニングに関する情報が記載されている Web サイト。 

チューニングのロードマップ

Identity Manager のソリューションのパフォーマンスは、次の配備固有の設定によって決まります。

パフォーマンス問題をデバッグする際には、まず問題を解析して記述してください。次の設問に答えます。

配備環境のチューニング

ここでは、次のような配備環境のチューニングについて説明します。

Java EE 環境のチューニング

ここでは、Java プラットフォームである Enterprise Edition (Java EE プラットフォーム) 環境の最適化に使用できるチューニング案をいくつか説明します。

これらのチューニング案は、一連の実験結果のうち、ユースケースのテストにおいてスループットにかなりの増加が確認されたものを基にしています。この向上は、JVM のサイズ変更と、ガベージコレクタの動作に影響を及ぼすスイッチによるものです。

注 –

Java、JConsole、または JVM のチューニングの詳細は、表 4–1 および 表 4–2 に記載されている Web サイトをご覧ください。

次の節では、Java EE 環境で Java と JVM をチューニングする方法について説明します。

Java のチューニング

Java パフォーマンスのチューニングの詳細、ベストプラクティス、および用例については、次の『Java Tuning White Paper』を参照してください。

http://java.sun.com/performance/reference/whitepapers/tuning.html

JVM のチューニング

この節に記載したチューニング案は、次のチューニングスクリプトを基にしています。これらのスクリプトは、Sun Java System Application Server の domain.xml ファイル (ドメイン設定ディレクトリにあり、通常は domain-dir/config です。) に追加されました。

最良の JVM パフォーマンスを得られるようにするには、次の点を確認してください。

アプリケーションサーバーのチューニング

アプリケーションサーバーのチューニングには、次のガイドラインが役立ちます。

注 –

ヒープサイズ以外にも、大半のアプリケーションサーバーにはデフォルトのパラメータ設定が使用できます。ご使用中のリリースに応じて、サーバーのヒープサイズを変更してください。

Sun Application Server のチューニング

最新の『Sun Java System Application Server パフォーマンスのチューニングガイド』の「アプリケーションサーバーのチューニング」の章では、Sun Java System Application Server のチューニング方法について説明しています。このドキュメントは、次の URL から入手できます。http://docs.sun.com/app/docs

また、Sun Application Server 8.2 Enterprise Edition をお使いの場合は、次のように変更すれば「並列モードのエラー」が解決され、パフォーマンスが改善され予測しやすくなるはずです。

この値は、さらに調整する必要があります。

WebSphere Application Server のチューニング

IBM WebSphere ® アプリケーションサーバーに搭載した Identity Manager をチューニングする場合、ヒープメモリーはスレッドに使用するメモリーに影響するため、ヒープに割り当てるメモリー量を制限するようにしてください。

多数のスレッドが同時に作成されてヒープサイズが増えると、アプリケーションのディスク空き容量限度を直ちに超えて、次のエラーが返されます。

JVMCI015:OutOfMemoryError

リポジトリデータベースのチューニング

Identity Manager は、ID と構成データの保存と管理にリポジトリデータベースを基にしています。このため、データベースのパフォーマンスが Identity Manager のパフォーマンスに大きく影響することがあります。

注 –

データベースのパフォーマンスチューニングと管理の詳細は、データセットやベンダーによって異なるので、このドキュメントでは説明しません。また、データベース管理者 (DBA) は、すでにお使いのデータベースに精通している必要があります。

ここでは、データベースの計画、チューニング、および管理に役立つよう、Identity Manager アプリケーションの特徴を説明し、Identity Manager のデータとその典型的な使用法パターンの概要を説明します。

この情報は、次の節で構成されています。

リポジトリテーブルの種類

Identity Manager のリポジトリには、3 種類のテーブルがあり、テーブルごとに使用方法の特徴が多少異なります。このテーブルについての情報は、次の節で構成されています。

属性テーブル

属性テーブルを使用すると、定義済みの単一値または複数値のオブジェクト属性を照会できます。

大半のオブジェクト型のストアド属性はハードコードされます。

注 –

User オブジェクト型と Role オブジェクト型は、この規則における例外です。User と Role オブジェクトテーブルに格納されるインライン属性は構成可能なため、追加のカスタム属性をクエリー可能として設定できます。

属性状態を基にオブジェクトを検索すると、Identity Manager は対応するオブジェクトテーブルを使用して結合内の属性テーブルにアクセスします。結合の形式 (JOIN、EXISTS 述語、SUB-SELECT など) によっては、属性の状態ごとに発生するものもあります。

属性テーブルの行数は、対応するオブジェクトテーブルの行数に比例しています。この値は傾斜 (スキュー) の形に分布することがあります。複数値の属性には値ごとに行があります。オブジェクトの中にはほかと比べて属性や属性値が多いものもあります。通常、属性テーブルの行とオブジェクトテーブルの行には、多対 1 の関係があります。

属性テーブルのテーブル名は ATTR です。

変更テーブル

Identity Manager では、対応するオブジェクトテーブルに加えた変更内容の履歴を追跡するのに変更テーブルを使用します。これらのテーブルのサイズは、オブジェクトの変更率に比例しますが、際限なく増えることはありません。Identity Manager は、自動的に変更テーブルを切り捨てます。

変更テーブルは、行の有効期間が比較的短く新しい行が頻繁に作成されるため、変動率が高くなることがあります。

変更テーブルへのアクセスは、通常、タイムスタンプフィールドの範囲スキャンで実行されます。

変更テーブルのテーブル名は CHANGE です。

オブジェクトテーブル

Identity Manager のリポジトリは、オブジェクトテーブルを使用してラージオブジェクト (LOB) などの直列化データオブジェクトを保持します。オブジェクトテーブルでは、よく問い合わされる単一値のオブジェクト属性も保持できます。

大半のオブジェクト型のストアド属性はハードコードされます。

注 –

User オブジェクト型と Role オブジェクト型は、この規則における例外です。オブジェクトテーブルに格納されるインライン属性は構成可能なため、User と Role は、追加のカスタム属性をクエリー可能として設定できます。

オブジェクトテーブル内の行数と、格納されるオブジェクト数は一致します。オブジェクトテーブルごとに格納されるオブジェクト数は、そのテーブルに格納されるオブジェクト型によって決まります。オブジェクト型によっては多数のものもあれば、少数のものもあります。

Identity Manager は通常、オブジェクト ID またはオブジェクト名を使ってオブジェクトテーブルにアクセスしますが、テーブル内に格納されている属性のうちの 1 つを使ってアクセスすることもできます。オブジェクト ID とオブジェクト名は単一のオブジェクト型をとおして一意ですが、属性値は一意ではなかったり均等に分布されていたりします。属性によっては値が多いものもあれば、比較的少ないものもあります。さらに、複数のオブジェクト型で同じ属性を使用することもあります。属性の中には、あるオブジェクト型に対する値は多く、別のオブジェクト型に対する値は少ないものもあります。値の分布が均一でないと、インデックスページの分布も均一でなくなり、スキューと呼ばれる状態になります。

オブジェクトテーブルは、テーブル名に ATTR または CHANGE 接尾辞が付かないテーブルです。

XML 列

オブジェクトテーブルにはそれぞれ 1 つの XML 列があり、LOG テーブルセットを除く各直列化オブジェクトを格納するのに使用されます。特定の LOG テーブルセットのオプションの属性は、それが存在する場合には XML 列に格納されます。たとえば、デジタル署名が有効に設定されている場合などがあります。

データクラス

Identity Manager のデータは、アクセスパターン、カーディナリティー、有効期間、データの変更頻度などの点で類似したプロパティーを持つクラスにほぼ分類できます。リポジトリのテーブルセットに対応しているクラスは、次のとおりです。

ユーザーデータ

ユーザーデータは、ユーザーオブジェクトから構成されます。

管理対象 ID ごとにオブジェクトがあるため、このデータはかなり大きくなることが予想されます。大部分の演算は既存オブジェクトを更新したものになるため、最初に生成してからは、作成されるものはあまりないはずです。

ユーザーオブジェクトは有効期間が長いものが多く、削除される確率は比較的低くなります。

ユーザーデータは、USEROBJ テーブル、USERATTR テーブル、および USERCHANGE テーブルに格納されます。

ロールデータ

ロールデータは、ビジネスロール、IT ロール、アプリケーション、アセットなどのロールのサブタイプを含む Role オブジェクトから構成されます。

ロールデータは組織データと似ており、お客様が Identity Manager を配備した後、このオブジェクトは比較的固定されます。

注 –

ただし、権限ロールセットがある外部ソースと一体化した配備は例外です。たとえば、一体化型にすると Identity Manager にロール変更の入力が必要になり、Identity Manager の Role データが変動しやすくなります。

(複数のユーザーが各ロールを共有しているとすれば) ロールオブジェクト数は、ユーザーなどの ID オブジェクト数よりも少ないと言えますが、これは企業のロール定義の仕方によって異なります。

ロールデータは、ROLEOBJ テーブル、ROLEATTR テーブル、および ROLECHANGE テーブルに格納されます。

アカウントデータ

アカウントデータは、Account Index のアカウントオブジェクトからのみ構成されます。

ユーザーデータと同様、既知のリソースアカウントごとにオブジェクトがあるため、アカウントデータは大きくなりがちです。アカウントオブジェクトは、一般的に有効期間が長く、削除される確率は比較的低く、最初に生成されてからは、作成されることはあまりありません。ネイティブアカウントの追加や削除を頻繁に行わない限り、またはネイティブ変更の検出を有効に設定しない限り、アカウントオブジェクトの変化はあまり発生しません。

Identity Manager は、アカウントデータを ACCOUNT テーブル、 ACCTATTR テーブル、および ACCTCHANGE テーブルに格納します。

コンプライアンス違反データ

コンプライアンス違反データには、監査ポリシーの評価に失敗した時期を表す違反レコードが記載されます。この違反レコードは、同じユーザーに対して同じ監査ポリシーが評価され、評価に合格するまで保持されます。違反レコードは、監査ポリシーのスキャンまたはアクセスレビューの一環として作成、変更、または削除されます。

違反レコードの数は、スキャンで使用される監査ポリシー数とユーザー数に比例します。インストールユーザー数が 5000、監査ポリシー数が 10 とすると、違反レコードは 500 (5000 x 10 x 0.01) と考えられます。この乗数 0.01 は、ポリシーの厳密度とユーザーアカウントの変更の仕方によって変わります。

Identity Manager は、コンプライアンス違反レコードを OBJECT テーブル、ATTRIBUTE テーブル、および OBJCHANGE テーブルに格納します。

権限付与データ

権限付与データは、コンプライアンスのアクセスレビューを実行する場合にのみ作成される、ユーザー権限付与オブジェクトから主に構成されます。

権限付与レコードは大きなバッチに作成され、最初の作成から (何日もかけて) ゆっくりと変更され、その後は手つかずのままになります。このレコードは、アクセスレビューが削除されてから削除されます。

Identity Manager は、権限付与データをENTITLE テーブル、ENTATTR テーブル、および ENTCHANGE テーブルに格納します。

組織データ

組織データは、オブジェクトグループまたは組織オブジェクトから構成されます。

オブジェクトグループデータは構成データと似ており、このデータは配備された後は比較的固定されます。一般的に、タスクオブジェクトと比べたり、ユーザーやアカウントなどの ID オブジェクトと比べるとオブジェクト数は (定義されている組織を単位とすると) 少ないですが、ほかの構成オブジェクトと比べるとこの数の方が多くなることがあります。

組織データは、ORG, ORGATTR テーブルと ORGCHANGE テーブルに格納されます。

タスクデータ

タスクデータは、状態と結果データを含むタスクとワークフローに関するオブジェクトから構成されます。

オブジェクトが高速で作成、変更、および削除されるため、これらのテーブルにあるこのデータの有効期間は、ほかのクラスと比べると短いです。このテーブルのデータ量は、使用システムの動作量に比例します。

タスクデータは、TASK テーブル、TASKATTR テーブル、TASKCHANGE およびテーブルに格納されます。

構成データ

構成データは、フォーム、ロール、ルールなどの Identity Manager のシステム構成に関するオブジェクトから構成されます。

構成データの特徴は、一般的に次のとおりです。

Identity Manager は、構成データを ATTRIBUTE テーブル、OBJCHANGE テーブル、および OBJECT テーブルに格納します。

エクスポートキューデータ

データのエクスポートを有効に設定すると、レコードの中には、エクスポートタスクがレコードをデータウェアハウスに書き込むまで、Identity Manager のキューに入れられるものがあります。キューに入れられるレコードの数は、データエクスポートの構成と、キューの中のすべての型に対するエクスポート間隔と相関関係にあります。

デフォルトでキューに入れられるデータ型は次のとおりです。これ以外のデータ型はすべてキューに入れられません。

これらのテーブルのレコード数は、エクスポートタスクがキューを排出するまで増えます。最新のテーブルサイズは、JMX TM Bean から表示できます。

このテーブルに追加されたレコードは、変更されることがありません。これらのレコードは、調整、プロビジョニング、ワークフローの実行など、ほかの Identity Manager 動作中に書き込まれます。このデータエクスポータがタスク実行をエクスポートすると、タスクがテーブルを排出します。

Identity Manager は、エクスポートキューデータレコードを QUEUE テーブル、QATTR テーブル、および QCHANGE テーブルに格納します。

ログデータ

ログデータは、監査オブジェクトとエラーログオブジェクトから構成されます。ログデータは 1 度限り書き込めるので、新規の監査オブジェクトとエラーログオブジェクトは作成できても、これらのオブジェクトを変更することはできません。

ログデータは明示的要求によってのみ消去できるため、ログデータの有効期間は非常に大きくなりがちです。ログデータに頻繁にアクセスするかどうかは、属性テーブル内ではなくオブジェクトテーブル内に格納されている属性によって決まります。ログに対する属性値の分布もクエリーも、具体的には Identity Manager の使い方によって決まります。

たとえば、ログテーブル内の属性値の分布は、次によって決まります。

ログテーブルに対するクエリーのパターンは、お客様がそのログテーブルに対して実行する Identity Manager レポート、カスタムレポート、または外部データマイニングのクエリーによっても異なります。

Identity Manager は、監査ログレコードを LOG テーブルと LOGATTR テーブルに、そしてエラーログレコードを SYSLOG テーブルと SLOGATTR テーブルに格納します。このデータには、対応する変更テーブルがありません。

オブジェクト ID

Identity Manager は、JDK ソフトウェアに用意されている VMID クラスでオブジェクトにグローバル一意識別子 (GUID) を生成します。

これらの GUID 値は、オブジェクトが作成された順に基づいて、格納されたプロパティーを文字列表現で表します。たとえば、Identity Manager でオブジェクトを新規作成すると、古い方のオブジェクトより新しい方のオブジェクトに大きいオブジェクト ID が付きます。このため、Identity Manager がデータベースに複数の新しいオブジェクトを挿入すると、オブジェクト ID に基づいたインデックスが同じブロックを競合することがあります。

準備済み文

Identity Manager は、準備済み文を動作 (データベース行の挿入や更新など) に使用することはあっても、クエリーに使用することは通常ありません。

Oracle® を使用している場合は、この動作のためにライブラリキャッシュに問題が生じることがあります。特に、文のバージョンが多数存在するとライブラリキャッシュのラッチに競合が起こることがあります。

この競合を解決するには、Oracle CURSOR_SHARING パラメータ値を EXACT から SIMILAR に変更します。この値を変更すると、SQL 文のリテラルが Oracle によってバインド変数に置き換えられるため、バージョンの数が減ります。

文字コードセットとエンコーディング

Identity Manager はバイトよりも文字データを通常読み書きする Java アプリケーションのため、データベースが用いるエンコーディングは制限されません。

Identity Manager は、データが正しく送信および返信されることだけを要求します。たとえば、書き込み時と再読み取り時にデータが破損することはありません。複数バイト文字をサポートし、データに合ったエンコーディングを使用してください。通常は UTF-8 エンコーディングで十分ですが、日本語やアラビア語などの真の複数バイト文字を多数用いる企業では、UTF-16 の方が良いかもしれません。

大多数のデータベース管理者が複数バイト文字をサポートしているエンコーディングの方を望む理由は、次のとおりです。

リポジトリデータベースのチューニングのガイドライン

ここでは、リポジトリデータベースをチューニングする際のガイドラインをいくつか説明します。

各テーブルセットに格納されるオブジェクト型の詳細は、「データクラス」を参照してください。

ベンダー固有データベースのチューニングに関するガイドライン

ここでは、Oracle と SQL Server のリポジトリデータベースをチューニング際のベンダー固有のガイドラインについていくつか説明します。

注 –

現在、開発とデモ用にサポートされているのは、MySQLTM データベースだけです。

Oracle データベース

ここでは、Oracle リポジトリデータベースをチューニングする際のガイドラインについて説明します。

Identity Manager は、SGA サイズ変更、バッファサイズ変更、オープンカーソル、プロセスなどに Oracle の init.ora パラメータ設定を必要としません。

SQL Server データベース

SQL Server 2000 データベースをリポジトリとして使用している顧客より、並行処理が増加するときに SQL Server の内部で悲観的 (Pessimistic) ロックを使用すること (主にロックエスカレーション) によるデッドロックの問題が SQL Server 2000 に発生するという報告がありました。

これらのデッドロックエラーは、次の形で表示されます。


com.waveset.util.IOException:
  ==> com.microsoft.sqlserver.jdbc.SQLServerException: Transaction (Process ID 51) 
was deadlocked on lock | communication buffer resources with another 
process and has been chosen as the deadlock victim. Rerun the transaction.

    このデッドロック問題を回避または解決するには、次の項目を実行します。

  1. SQL Server 2005 データベースを使用します。

  2. 次のようにコマンドを初期化して、READ_COMMITTED_SNAPSHOT パラメータを設定します。

    ALTER DATABASE waveset SET READ_COMMITTED_SNAPSHOT ON

    READ_COMMITTED_SNAPSHOT パラメータを有効にすると、次のようになります。

    • SELECT 文の実行中にブロックの原因となりうる競合がなくなります。そのため、SQL Server 内部へのデッドロックの危険性が大幅に減少します。

    • 不確実なデータが読まれなくなります。そのため、SELECT 文が確実なデータの一貫したビューを受信できるようになります。

    READ_COMMITTED_SNAPSHOT パラメータの詳細は、http://msdn2.microsoft.com/en-us/library/ms188277.aspx を参照してください。

Identity Manager パフォーマンスのチューニング

Identity Manager のパフォーマンスを最適化するための推奨は、次の領域に分かれています。

一般的なパフォーマンスのチューニング

通常は、次のとおり実行すると Identity Manager のパフォーマンスを最適化できます。

Active Sync アダプタのパフォーマンスのチューニング

同期はバックグラウンドタスクであるため、Active Sync アダプタ設定によってはサーバーのパフォーマンスが影響を受ける可能性があります。

Active Sync アダプタの管理には、「リソース」リストを使用します。Active Sync アダプタを選択し、「リソースアクション」リストの「同期」セクションから処理を制御する実行、停止、ステータス更新を利用してください。

Active Sync アダプタのパフォーマンスを向上するには、次のとおり実行します。

一括ロードのチューニング

一括ロード操作中のパフォーマンスを向上させるには、次のとおり実行します。

設定を変更可能な XML オブジェクト設定のチューニング

設定可能な XML オブジェクトを使用すると、広範囲のユーザーインタフェース仕様が利用でき、タスクごとにユーザーへのデータ表示方法を定義したり、複雑な業務プロセスを自動化したりできるようになります。ただしこの柔軟性は、効率、パフォーマンス、および信頼性に影響を与えることがあります。

ここでは、フォーム、ルール、およびワークフローから構成される、Identity Manager の設定可能な XML オブジェクトをチューニングする際のガイドラインをいくつか説明します。これらの情報は、次のように構成されています。

フォームのチューニング

実行中タスクのビューや変数コンテキストと相互に作用するインタフェースを定義するには、Identity Manager のフォームを使用します。フォームには、データ要素のセットにビジネスロジックと変換ロジックに使用する実行コンテキストがあります。各種タスクを実行する非常に強力で動的なフォームを作成できるとはいえ、フォームの複雑さを抑えれば効率が上がります。

次に、カスタマイズしたフォームのパフォーマンスを向上させる方法をいくつか説明します。

新しいフォームの最適化

Identity Manager の新しいフォームを設計する際、システムインテグレーターは次の手順に従えばフォームのパフォーマンスを最適化できます。

管理者フォームの最適化

管理者フォームのパフォーマンスを向上させるには、次の項目を実行します。

エンドユーザーフォームの最適化

エンドユーザーフォームのパフォーマンスを向上させるには、次の項目を実行します。

フォームフィールド内の式の最適化

フォームで実行される動作の中には、Identity Manager 外部のリソースを呼び出すものがあります。特にグループリストや電子メール配信リストのコンパイルなど、結果の値が長いリストになるような外部リソースへのアクセスは、Identity Manager のパフォーマンスに影響を与えることがあります。

このような呼び出し中のパフォーマンスを向上させるには、『Sun Identity Manager Deployment Reference』の「Java クラスを使用したフィールドデータの取得」のガイドラインに従ってください。

また、<Disable> 式のようなパフォーマンスに影響を受けやすい式で JavaScriptTM を使用するのは避けてください。組み込まれたトレース機能を使用する場合は、短い XPRESS 式の方がデバッグしやすいです。ワークフローアクションの複雑なロジックには JavaScript を使用します。

フォームの表示速度が低下した場合、debug/Show_Timings.jsp ページで問題を見つけ出すことができます。Formconvert.convertField() への呼び出しを探してください。これで、フィールドごとにその値の計算にどれくらい時間が掛かっているかがわかります。

ルールのチューニング

Identity Manager ルｰﾙを使用して、本製品の中でフォームやワークフローなど設定可能なコンポーネントで再利用できる定数と XPRESS ロジックをカプセル化します。

ルールを記述する際は、最適なパフォーマンスを得られるよう、必要に応じて次のガイドラインを使用してください。

ワークフローのチューニング

さまざまな人的および電子的タッチポイントを使用した複雑な業務処理を、使いやすく自動化できるように Identity Manager のワークフローをカスタマイズします。

カスタムのワークフローのパフォーマンスを向上させるには、次の方法に従ってください。

WorkItems (ManualActions ) のチューニング

WorkItems (ワークフロー内では ManualActions と表示されています) の数とサイズによって、メモリーとシステムパフォーマンスが著しく影響を受けることがあります。デフォルトでは、WorkItem に Identity Manager が全体ワークフローのコンテキストをコピーしてから、送信後にこのワークフローコンテキストを書き戻します。

WorkItems と ManualActions のパフォーマンスを向上させるには、次の手順に従ってください。

データベース統計のチューニング

データベース管理者の場合、頻繁に統計を実行してリポジトリデータベースを監視しているはずです。

パフォーマンス問題は、データベーステーブルの統計が悪いか抜けている場合によく起こります。この問題を解決すれば、データベースと Identity Manager パフォーマンスの両方のパフォーマンスが向上します。

詳細は、次の Oracle 記事を参照してください。

最適なクエリー計画を選択するもう一つの方法として、SQL プロファイルを使用するようにします。パフォーマンスの悪い SQL を特定する際には、Enterprise Manager から SQL Advisor を使用してこれらのプロファイルを作成します。

データエクスポータのチューニング

データエクスポータを使用すると、Identity Manager の新規データ、変更データまたは削除データを、レポート作成と解析作業に適した外部のリポジトリにエクスポートできるようになります。実際のエクスポートデータはバッチで行われます。ここで、エクスポート対象となる各種データが独自のエクスポート周期を指定できます。Identity Manager リポジトリに付属しているエクスポート対象のデータと、エクスポート周期の長さと変更されるデータ量にもよりますが、エクスポートされるデータ量は大きくなりがちです。

Identity Manager のデータ型の中には、後からエクスポートできるように、特殊なテーブルのキューに入れられるものがあります。具体的に言うと、WorkflowActivity と ResourceAccount データがキューに入れられます。こうしないとこのデータが持続しないためです。型に加えられたすべての変更点をウェアハウスで監視する必要があったり、TaskInstance や WorkItem データなど、エクスポート周期に対応しないライフサイクルの型があると、どの持続性のデータ型でもキューに入れられることもあります。

パフォーマンスを最大限に高めるには、ウェアハウスで必要なデータ型だけをキューに入れてエクスポートしてください。データエクスポートはデフォルトで無効になっていますが、データエクスポートを有効にすると、すべてのデータ型がエクスポートされます。不要なデータ型はすべて無効にしてください。

エクスポートタスクがデータをエクスポートする際、このタスクは複数スレッドを使用して、できる限り多くのスループットを達成するためにエクスポートを一刻も早く完了しようとします。Identity Manager リポジトリとウェアハウスの入出力速度にもよりますが、export タスクが Identity Manager サーバーのプロセッサを完全に占有し、これが対話式パフォーマンスが低下する原因になります。できればエクスポートは、エクスポートタスクに専用のマシンで実行するか、少なくともそのマシンに対話式処理がない期間に実行するようにします。

エクスポートタスクでサポートしているチューニングパラメータは、次のとおりです。

排出スレッドカウントは、最も需要なスループットです。キューテーブルに多数のレコードがある場合、(最大 24 まで) スレッド数を増せばスループットが高まるようになります。ただし、そのキューがある種のレコードに占有されていると、実際に高速化できる排出スレッドは少なくなります。エクスポートタスクは、割り当てできるスレッドのセット数までキューテーブルの中身を分けて、それぞれのスレッドに排出対象のセットを入れようとします。これらのスレッドには、ほかのリポジトリテーブルを排出している排出スレッドも含まれます。

一般的な XML のチューニング

静的な XMLObject 宣言を可能な限り使用すれば、一般的な XML を最適化できることがよくあります。たとえば、以下を使用します。

また、コンテキストにもよりますが、<o></o> 要素の代わりにラップオブジェクトを使用するようにします。

Identity Manager Service Provider のチューニング

Identity Manager の計器盤グラフを使用すると、SunTM Identity Manager サービスプロバイダ (サービスプロバイダ) の現在のシステムを評価し、異常を見つけ、これまでの傾向を理解することができます (時間枠内の並列ユーザーやリソースの動作など)。

注 –

サービスプロバイダ には、管理者インタフェースがありません。Identity Manager の管理者インタフェースから、管理者タスクのほぼすべてを実行してください (計器盤グラフなど)。

サービスプロバイダ のチューニングの詳細は、『Sun Identity Manager Service Provider 8.1 Deployment』を参照してください。

Identity Manager Web インタフェースのチューニング

Identity Manager の Web インタフェースを使用している場合は、Identity Manager に同梱されている OpenSPML ツールキットでパフォーマンスを最適化できます。

注 –

openspml.jar ファイルを http://openspml.org/ の Web サイトから使用すると、メモリーリークが起こります。

初期ロードのチューニング

    大きな初期ユーザーのロード中にパフォーマンスを向上させるには、次の項目を実行します。

  1. Identity Manager の管理者インタフェースから、すべての監査イベントを無効にします。

    注 –

    監査ロギングを使用すると操作ごとに複数のレコードが追加され、それ以降の監査レポートの実行速度が低下することがあります。

    1. 「設定」->「監査」の順に選択します。

    2. 「監査の設定」ページで、「監査を有効にする」ボックスの選択を解除して「保存」をクリックします。

  2. Web サーバをシャットダウンしてリストキャッシュを無効にするか、(debug/Show_WSProp.jsp デバッグページにある) ChangeNotifier.updateSearchIntervalCount プロパティーを 0.. に変更して、リストキャッシュを無効にします。

    リストキャッシュには、メモリー内で頻繁にアクセスされる組織内のユーザーリストが保持されています。これらのリストを保持するため、リストキャッシュは新規作成されたユーザーを探して確認します。

  3. debug/ Clear_List_Cache.jsp ページにある最新のリストキャッシュを消去します。

  4. ユーザーの処理に使用されるワークフローに、承認が記載されていないことを確認します。

  5. 次のように、代替となるロード方法を使用します。

    • ロードを分割し、そのデータをゾーンで実行する。

    • より高速な一括ロードを使用する。

    • ファイルからロードを行う。

  6. WorkflowActivity 型のデータエクスポータを無効にします。

必要メモリーのチューニング

Java コマンドラインへの最大ヒープサイズと最小ヒープサイズを追加して、必要メモリーを定め、アプリケーションサーバーの JVM に値を設定します。たとえば、次のようにします。

java -Xmx512M -Xms512M

パフォーマンスを向上させるには、次の項目を実行します。

注 –

max.post.memory.size は、ディスクへスプールせずに (たとえば HTML FileSelect コントロールで) 送信されたファイルに含まれている最大バイト数を指定します。一時ファイルへの書き込み権がない場合は、max.post.memory.size を増やして、ディスクへスプールしないようにします。デフォルト値は 8K バイトです。

システム要件の詳細は、『Sun Identity Manager 8.1 リリースノート』を参照してください。

オペレーティングシステムのカーネルのチューニング

SolarisTM と Linux オペレーティングシステムのカーネルのチューニングの詳細は、『Sun Java System Application Server Enterprise Edition Performance Tuning Guide』の「Tuning the Operating System」の章を参照してください。

Oracle オペレーティングシステムのカーネルのチューニングについては、Oracle システムに付属の製品マニュアルを参照してください。

プロビジョニングツールのチューニング

ビューのプロビジョニングを処理する際のパフォーマンス問題は、ネットワーク遅延に原因があることがよくあります。個々のリソースアダプタをトレースすれば、何がパフォーマンス問題の原因になっているかがわかりやすくなります。

プロビジョニングツールのパフォーマンスを向上させるには、次の項目を実行します。

調整のチューニング

調整サーバーとは、調整を行う Identity Manager のコンポーネントです。ここでは、以下を初めとする調整サーバーのパフォーマンスを向上させるための推奨方法を説明します。

調整のチューニングで用いる一般的な推奨事項

通常は、次のとおり実行すると調整サーバーのパフォーマンスを最適化できます。

調整サーバーの設定のチューニング

デフォルト設定で適切な場合が多いですが、「サーバー設定の編集」ページにある次の設定を調節すると、調整サーバーのパフォーマンスを向上できることがあります。

アイドル中は、スレッドに行うべき処理がなく、指定した最小限のスレッド数にまで低下した場合に限り、スレッドが停止します。ロードが増えるに従って、最大スレッド数に達するまで、調整サーバーはさらにスレッドを追加します。調整サーバーは、最小限のスレッド数を下回ったり最大限のスレッド数を上回ることはありません。

通常、スレッドが増えると並列処理も増えます。ただし、多すぎるスレッドによっていつしかマシンに大きすぎる負荷が掛かったり、単に効果が得られなくなることがあります。

注 –

配備はそれぞれ異なるため、汎用的で最適な設定を推奨することはできません。調整サーバーの設定は、配備環境ごとに個別に調整する必要があります。

Procedure調整サーバーの設定を変更する

調整サーバーの設定を変更するには、次の項目を実行します。

  1. 管理者インタフェースにログインします。

  2. 「設定」->「サーバー」->「調整サーバー」タブの順にクリックします。

  3. 「サーバー設定の編集」ページが表示されたら、必要に応じて設定を調整します。

    詳細は、「サーバーのデフォルト設定の編集」を参照してください。

複数リソースに用いる調整のチューニング

Identity Manager で複数リソースに調整を設定する場合は、いくつかオプションがあります。

配備はそれぞれ異なるため、この設定には最適な解決策がありません。配備に合った解決策を見つけるには、これらのオプションを組み合わせて調整する必要があります。

この機能の業務目的を基に使用量アンケートを作成すると、進め方が決定しやすくなるかもしれません。

次の問題に取り組みます。

また、調整サーバーは、Web トラフィックを処理するプールに含める必要はありません。このサーバーはとトランザクション処理専用にあるため、決して直接対話しないようなサーバーを追加してください。トランザクション処理専用のサーバーを用意すると、大規模システムには一番上のオプションが最適かもしれません。

リソースクエリのチューニング

注 –

ビューをプロビジョニングする際のパフォーマンス問題は、ネットワーク遅延に原因があることがよくあります。個々のリソースアダプタをトレースすれば、何がパフォーマンス問題の原因になっているかがわかりやすくなります。

クエリーを実装する際に FormUtil.getResourceObjects を使用すると、リソースクエリーのパフォーマンスを向上させることができます。

クエリー結果のキャッシュに、次のうちいずれかの方法を用います。

注 –

スケジューラのチューニング

スケジューラコンポーネントは、Identity Manager のタスクのスケジュール作成を管理します。

ここでは、以下を初めとするスケジューラのパフォーマンスを向上させるための推奨方法を説明します。

スケジューラをチューニングするための一般的な推奨事項

次の TaskDefinition オプションによって、タスク完了後のスケジューラによるタスクの処理の仕方が決まります。

これらのデフォルト設定は、完了したスケジューラのタスクの有効期間を短縮することでメモリーを最適化できるようにするためのものです。これらの設定を変更せざるをえない事情がない限り、デフォルトのままにしておいてください。

正常に完了したタスクを即時削除するとはいえ、デバッグできるまでエラーを含むタスクを残しておくには、次を実行することもできます。

スケジューラサーバーの設定のチューニング

「サーバー設定の編集」ページで次の設定を調整すると、スケジューラのパフォーマンスを向上できることがあります。

注 –

配備はそれぞれ異なるため、汎用的で最適な設定を推奨することはできません。スケジューラの設定は、配備環境ごとに個別に調整する必要があります。

Procedureスケジューラサーバーの設定を変更する

  1. 管理者インタフェースにログインします。

  2. 「設定」->「サーバー」->「スケジューラ」タブの順にクリックします。

  3. 「サーバー設定の編集」ページが表示されたら、必要に応じて設定を調整します。

    詳細は、「サーバーのデフォルト設定の編集」を参照してください。

セッションのチューニング

Identity Manager は、認証済みセッションで認証されたユーザーが使用できる最長時間未使用の (LRU) キャッシュを保持します。既存の認証済みセッションを使用すると、セッションを必要とするオブジェクトとアクションに対してリポジトリアクセスの速度をアップすることができます。

認証プールサイズを最適化するには、Waveset.properties ファイルの session.userPoolSize 値を、そのサーバーで見込まれる並列ユーザーセッションの最大数に変更します。

Sun Identity Manager Gateway のチューニング

Sun Identity Manager Gateway は、接続ごとにスレッドを生成して、リソース種類、ゲートウェイホスト、およびゲートウェイポートの一意の組み合わせごとに異なるプールを使用します。ゲートウェイは、5 分ごとにアイドル中の接続がないかチェックします。60 分間アイドル中の接続が合った場合、ゲートウェイはその接続を閉じてプールから削除します。

ゲートウェイは要求を受け取ると、次の操作を行います。

そのリソースの最大接続数を設定してください。また、その種類のすべてのリソースに対し、そのゲートウェイを使用しているのと同じ方法でこの接続を設定してください。このリソース種類では、所定のホストでゲートウェイに行った最初の接続とポートが、そのリソースの最大接続数を使用します。

注 –

そのリソースの最大接続数を変更する場合は、サーバーを再起動して変更内容を反映してください。

次の例は、接続、要求、およびゲートウェイスレッドの関係を示したものです。

Active Directory リソースで最大接続数を 10 に設定し、2 台の Identity Manager サーバーを使用している場合は、その Active Directory リソースのゲートウェイに最大 20 までの同時接続を設定できます (Identity Manager サーバーごとに 10)。このゲートウェイは、各サーバーから送信された 10 の同時要求を受け付けることができ、各要求を別々のスレッドで処理します。同時要求数がゲートウェイの最大接続数を超えた場合、それ以上の要求はゲートウェイが要求を完了して接続をプールに戻すまで、キューの中に入れられます。

注 –

ゲートウェイコードはマルチスレッドですが、この特性はゲートウェイで使用中の API やサービスに対応しません。Active Directory には、ゲートウェイは Microsoft から提供されている ADSI インタフェースを使用します。このインタフェースがゲートウェイの要求を並列に処理するかどうかを判断する調査は一切行われていません。

このほか、ゲートウェイのパフォーマンスを向上させる方法には、次のようなものがあります。

タスクバーのチューニング

管理者インタフェースのタスクバーには、すでに実行したプロビジョニングタスクのリンクが表示されます。このため、多数のタスクがあると、インタフェースの速度が低下します。

インタフェースのパフォーマンスを向上させるには、<List>...</List> 要素を UserUIConfig オブジェクトから削除して、taskResults.jsp リンクを各 JSP から削除します。

次の例に、<TaskBarPages> 内の <List>...</List> エントリを示します。

例 4–1 UserUIConfig オブジェクトの修正


<TaskBarPages>
  <List>
    <String>account/list.jsp</String>
    <String>account/find.jsp</String>
    <String>account/dofindexisting.jsp</String>
    <String>account/resourceReprovision.jsp></String>
    <String>task/newresults.jsp</String>
    <String>home/index.jsp</String>
  </List>
 </TaskBarPages>

パフォーマンス問題のデバッグ

ここでは、パフォーマンス問題のデバッグに使用できる、各種 Identity Manager と、第三者のデバッグツールについて説明します。

これらの情報は、次のように構成されています。

Identity Manager のデバッグページの使用

注 –

トレースは、システムパフォーマンスに影響を及ぼします。最適なパフォーマンスが得られるようにするには、最小限のトレースレベルを指定するか、システムのデバッグ後にトレースを無効に設定してください。

ここでは、Identity Manager のデバッグページにアクセスする手順を説明するとともに、このページを使用して Identity Manager のパフォーマンス問題を突き止めデバッグする方法について説明します。

これについては、次のセクションを参照してください。

デバッグページへのアクセス方法

注 –

Identity Manager のデバッグページにアクセスして操作を実行するには、Debug、Security Administrator、または Waveset Administrator 機能が必要です。管理者とコンフィギュレータには、デフォルトでこの機能が割り当てられています。

デバッグ機能がない場合は、エラーメッセージが表示されます。

ProcedureIdentity Manager のデバッグページにアクセスする

  1. ブラウザを開き、管理者インタフェースにログインします。

  2. 次の URL を入力します。

    http:// host:port /idm/debug

    各表記の意味は次のとおりです。

    • host は、Identity Manager の実行先アプリケーションサーバーです。

    • port は、このサーバーが監視中の TCP ポート数です。

  3. システム設定ページが表示されたら、開くデバッグページの .jsp ファイル名を入力します。

    たとえば、次のようにします。

    http:// host: port /idm/debug/pageName.jsp

    注 –

    デバッグユーティリティーの中には、システム設定ページからリンクされていないものもありますが、これらを使用すると、製品のパフォーマンスと使いやすさのデータを収集できるようになります。デバッグページの全体リストについては、コマンドウィンドウを開いて idm/debug ディレクトリの中身をリストします。

制御タイミング (callTimer.jsp)

各種メソッドの呼び出しタイマー統計を収集して表示するには、制御タイミングページを使用します。この情報を基に、特定メソッドに対するボトルネックと呼び出された API を追跡できます。呼び出しタイマーの基準値をインポートまたはエクスポートするのにも、呼び出しタイミングページのこのオプションが使用できます。

注 –

呼び出しタイミングの統計は、トレースが有効に設定されている間にだけ収集されます。

Procedure呼び出しタイマーの統計を表示する

  1. トレースとタイミングを有効にするには、「制御タイミング」ページを開き、「タイミングとトレースの開始」をクリックします。

  2. タイミングを終了するには、「タイミングとトレースの終了」をクリックするか「タイミングの終了」をクリックします。

    ページが再表示され、統計が使用できるメソッドのリストとメソッドの集約呼び出しタイマー統計が「タイミングの表示」テーブルに入力されます (呼び出し側から中断されません)。

    このテーブルには、次の情報が記載されています。

    • メソッド名 (呼び出すメソッドを表示するには、そのメソッド名をクリックします)

    • 総使用時間

    • 平均時間

    • 最小時間

    • 最大時間

    • 総呼び出し数

    • 総エラー数

  3. このリストを消去するには、「タイミングの消去」をクリックします。

    注 –

    コンソールから呼び出しタイマーのデータを収集するには、callTimer コマンドを使用します。このコマンドは、アップグレード中や、アプリケーションサーバーで Identity Manager を実行していないなどの状況で、パフォーマンス問題をデバッグする際に有用です。

トレース設定の編集 (Show_Trace.jsp)

Identity Manager をインストールしたときに付属している Java クラスにトレースを有効にを設定するには、「トレース設定の編集」ページを使用します。

具体的には、このページから次のトレース設定を行えます。

ホスト接続プール (Show_ConnectionPools.jsp )

データソースを使用しない場合は、「ホスト接続プール」ページから接続プール統計を表示することができます。これらの統計には、プールのバージョン、作成された接続数、アクティブ数、プール内の接続数、プールから処理されている要求数、および破棄された接続数が記載されます。

この「ホスト接続プール」ページは、ゲートウェイへの接続管理に使用された接続プールの概要を表示する際にも使用できます。この情報を使用して、低位アドレスメモリー状態を調べられます。

消去したキャッシュのリスト (Clear_XMLParser_Cache.jsp)

最近使用した XML パーサーをキャッシュから消去して低位アドレスメモリー状態を調べるには、「消去したキャッシュのリスト」ページを使用します。

メソッドタイミング (Show_Timings.jsp)

メソッドレベルですばやくホットスポットを検出して評価するには、「メソッドタイミング」ページを使用します。

Identity Manager メソッドから収集され、「メソッドタイミング」ページに表示される情報は、次のとおりです。

「メソッドタイミング」ページには、次のリンクを記載したテーブルもあります。これらのリンクをクリックすると、詳細を表示できます。

注 –

「メソッドタイミング」ページにある「すべて消去」オプションは、全ての結果を消去します。このオプションは、デフォルトで有効になっています。

オブジェクトサイズの概要 (Show_Sizes.jsp)

システムに影響を及ぼしかねない大きそうなオブジェクトを検出するには、この「オブジェクトサイズの概要」ページを使用します。

この「オブジェクトサイズの概要」ページには、リポジトリに格納されるオブジェクトのサイズが (文字単位) で表示されます。このオブジェクトは型別にリストされ、型別の総オブジェクト数とオブジェクトの組み合わせ総サイズ、平均サイズ、最大サイズ、および最小サイズが記載されます。

そのオブジェクト型のサイズの詳細は、「型」列のエントリをクリックします。たとえば、リポジトリ内の最大設定オブジェクトの ID、名、サイズを表示するには、「設定」をクリックします。

このサイズ情報は、「コンソール」コマンドラインからもアクセスできます。

Procedureコマンドラインからオブジェクトサイズ情報にアクセスする

  1. コンソールを開きます。

  2. コマンドプロンプトで、次を入力します。

    showSizes [ type[limit ]]

    注 –

    アップグレードの場合、更新または再表示されるまで既存オブジェクトのサイズが 0 と記録されます。

管理者とコンフィギュレータ用のプロビジョニングスレッド (Show_Provisioning.jsp)

システムで使用中のプロビジョニングスレッドの概要を表示するには、この「管理者とコンフィギュレータ用のプロビジョニングスレッド」を使用します。この概要は、Show_Threads.jsp で用意される情報のサブセットです。

注 –

単一のスレッドダンプを見ただけでは、判断できないことがあります。

システムキャッシュの概要 (Show_CacheSummary.jsp)

低位アドレスメモリー状態の調査に役立つよう、次の項目について表示するには、この「システムキャッシュの概要」ページを使用します。

システムメモリーの概要 (Show_Memory.jsp)

利用可能な総メモリー数と空きメモリーを表示するには、この「システムメモリーの概要」ページを使用します。調整などのメモリーを消費する機能を使用している場合は、この情報を基にして JVM に十分なメモリーが割り当てられているかどうかが突き止められます。

また、ガベージコレクションの起動や、ヒープ使用量を調査するための JVM 内の未使用メモリーの消去にも、このページが役に立ちます。

システムプロパティー (SysInfo.jsp)

この「システムプロパティー」ページには、ソフトウェアバージョン、パス、環境変数など、使用中の環境についての情報が記載されます。

システムスレッド (Show_Threads.jsp)

(調整や Active Sync などの) 自動プロセスが実行中であることを確認できるように、実行中のプロセスを表示するには、この「システムスレッド」ページを使用します。

このページには、プロセス種類、プロセス名、そのプロパティー、プロセスがデーモンかどうか、およびプロセスがいまだに実行中かどうかについての情報が記載されます。

注 –

単一のスレッドダンプを見ただけでは、判断できないことがあります。

消去されたユーザーセッションプール (Clear_User_Cache.jsp)

最近ログインしたユーザーのキャッシュ済みセッションをすべて消去し、低位アドレスメモリー状態を調べるには、この「消去されたセッションプール」ページを使用します。

Waveset プロパティー (Show_WSProp.jsp)

Waveset.properties ファイルのプロパティーを表示して一時的に編集するには、この「Waveset プロパティー」ページを使用します。Waveset.properties ファイルの常駐先の特定サーバーには、サーバーを再起動して変更内容を反映していなくても、各種のプロパティー設定をテストできます。編集したプロパティー設定は、次回サーバーを再起動するまで、反映されたままになります。

フラッシュして消去された XML リソースアダプタのキャッシュ (Clear_XMLResourceAdapter_Cache.jsp)

テスト XML リソースアダプタをキャッシュから消去し、低位アドレスメモリー状態を調べるには、この「フラッシュして消去された XML リソースアダプタのキャッシュ」ページを使用します。

それ以外のデバッグツールの使用

パフォーマンスの潜在的ボトルネックを見つけるには、次の Sun Microsystems ツールと第三者ツールが使用できます。

これらのツールは、使用中の配備でカスタム Java クラスを使用する場合に有用です。

Identity Manager Profiler

Identity Manager には、使用中の配備のパフォーマンス問題をトラブルシューティングするのに役立つ Profiler ユーティリティーが搭載されています。

カスタマイズしたフォーム、Java、ルール、ワークフロー、および XPRESS がパフォーマンス問題とスケール問題の原因になることがあります。この Profiler は各領域での経過時間を調べるので、フォーム、Java、ルール、ワークフロー、XPRESS オブジェクトのうちどれがパフォーマンス問題とスケール問題の一因となっているか、一因となっている場合は、そのオブジェクトのどの部分が問題の原因になっているかがわかります。

注 –

Profiler の詳細は、『Sun Identity Manager 8.1 リリースノート』の「Identity Manager プロファイラの操作」を参照してください。

DTrace の使用

DTrace 機能は、Solaris 10 オペレーティングシステム用に動的にトレースするフレームワークで、JVM 動作を監視できるようになります。

DTrace には、30,000 を超える検証機能が搭載されており、統合されたユーザーレベルとカーネルレベルのトレース機能を使用して、プロダクションシステム内を把握できるようにします。また、C 言語や awk 言語に似た D 言語で、任意のデータと式をトレースすることもできます。この DTrace 機能にも、JVM を監視するための特殊なサポートが備わっているので、使用中のシステム全体と JVM 外部のスパンが監視できるようになります。

DTrace は、検証機能が JVM に内蔵されているので Java 6 で一番使用しやすくなっています。この機能は、Java 1.4 と Java 5 でも動作しますが、次の URL から JVM PI または JVM TI エージェントをダウンロードする必要があります。

https://solaris10-dtrace-vm-agents.dev.java.net/

次の例は、DTrace スクリプトの記述方法を示したものです。

例 4–2 DTrace スクリプトの例


#!/usr/sbin/dtrace -Zs 
#pragma D option quiet
hotspot$1::: 
{
  printf("%s\n", probename); 
}

この例では、$1 をスクリプトの最初の引数に置き換えてください。これは、管理対象となる Java プロセスの PID としてください。たとえば、次のようにします。

# ./all-jvm-probes.d 1234

次の表は、各種 DTrace の検証機能を有効にできるコマンドを説明したものです。

表 4–3 DTrace コマンド

コマンド 

説明 

-XX:+DTraceMonitorProbes

Java 6 の JVM サポートを有効にします (Java 1.4 と Java 5 用パッチ)。 

-XX:+ExtendedDTraceProbes

次の情報を提供します。 

  • JVM の起動 (開始と終了) とシャットダウン

  • 開始スレッドと停止スレッド

  • 読み込み中クラスと読み込み解除中のクラス

  • ガベージコレクション (各種オプションが利用可能)

  • JIT コンパイルの開始と終了

  • 読み込み中コンパイル済みメソッドと読み込み解除中のコンパイル済みメソッド

  • 監視競合、待機、通知

  • メソッドのエントリ、メソッドの戻り値、オブジェクト割り当て

/usr/sbin/dtrace -n ’hotspot*:::’

そのシステム上のすべての Java プロセスに、すべての JVM 検証機能を有効にします。 

/usr/sbin/dtrace -n ’hotspot1234:::’

PID が 1234 の Java プロセスにだけ、すべての JVM 検証機能を有効にします。

/usr/sbin/dtrace -n ’hotspot1234:::gc-begin’

プロセス 1234 を開始するためのガベージコレクション時に起動する検証機能だけを有効にします。

注 –

DTrace はシステム処理を増やすため、この機能はシステムパフォーマンスに影響します。この影響はごくわずかですが、負荷のかかる有効化で大量の検証機能を有効にすると大きくなります。

DTrace のパフォーマンスへの影響を最小限に抑える手順については、『Solaris Dynamic Tracing Guide』の「Performance Considerations」の章に記載されています。

DTrace の詳細は、/usr/demo/dtrace および man dtrace を参照してください。

JMX の使用

Identity Manager を使用すると、Java Management Extensions (JMXTM) を使用して、所定のリソースアダプタの操作における操作上の統計を取り込み表示することができます。このデータは、システム状態とレポートを監視するなど、診断と予測に使用できます。

この統計データには、次の情報が含まれています。

オブジェクト 

監視対象となった動作 

アカウントの場合 

  • Create

  • Update

  • Delete

  • Get

  • Authenticate

動作の場合 

Run 

その他オブジェクトの場合 

  • Create

  • Update

  • Delete

  • Get

  • List

JMX は、サーバー別のリソースアダプタごとに MBeans を作成して、これらの Beans を次のパターンに一致する名前で登録します。


serverName=server name, resourceAdapterType=Resource Adapter Type,
resourceAdapterName=Resource Adapter Name

Identity Manager は、正常に完了したかエラーで完了したか、完了した処理のすべてに統計を記録します。ただし Identity Manager は、例外を投げる処理など未完成の処理の統計は記録しません。

excludes の設定方法は、次のとおりです。

  1. 管理者インタフェースから、「設定」->「サーバー」の順に選択します。

  2. 「サーバーの設定」ページで、次のいずれかのタスクを実行します。

    • サーバーのデフォルト設定を編集するには、「サーバーのデフォルト設定の編集」ボタンをクリックします。

    • サーバーのポリシーを編集するには、そのサーバーのリンクをクリックします。

  3. リソース監視を有効にするには、「JMX」タブをクリックして「JMX リソースアダプタモニターの有効化」ボックスを有効にします。

    • 特定のリソースを除外するには、「JJMX リソースアダプタモニターの対象外」リストに正規表現を追加します。

    • 特定動作の監視を除外するには、「JMX リソースアダプタモニター操作の対象外」リストに正規表現を追加します。

どの excludes も、正規表現を使用します。特定リソースを除外した場合、JMX はリソース名だけで照合します。たとえば次の名前のアダプタがある場合は、


resource1
resource2
resource3
resource10
resource11

次のパターンを指定します。


.*1$

つまり、何かが 1 (1$) で終わるまで、0 以上の任意の文字 (.*) にマッチします。JMX は、resource1 と resource11 を除外します。

処理の場合も、手順は同様です。処理に次の名前が付いている場合は、パターンがこの名前に一致する必要があります。


ACCOUNT_CREATE
ACCOUNT_UPDATE
ACCOUNT_DELETE
ACCOUNT_GET
ACCOUNT_AUTHENTICATE
OBJECT_CREATE
OBJECT_UPDATE
OBJECT_DELETE
OBJECT_GET
OBJECT_LIST
ACTION_RUN

たとえば、^ACCOUNT.* パターンは ACCOUNT で始まるすべての処理を除外します。または、このパターンを使用すると updates と deletes が除外されます。


.*UPDATE$
.*DELETE$
注 –

JMX の設定方法と使用法の詳細は、『『Sun Identity Manager 8.1 ビジネス管理者ガイド』』の「JMX 監視の設定」 および 『Sun Identity Manager 8.1 ビジネス管理者ガイド』の「JMX パブリッシャータイプ」を参照してください。

JConsole の使用

Java Monitoring and Management Console (JConsole) は、Java Management Extension (JMX) テクノロジ対応のグラフィカル管理ツールで、JDK 5 以降に同梱されています。JConsole は実行中の JVM に接続し、接続している JMX エージェントの JVM MBeans から情報を収集します。

具体的に JConsole で実行できるタスクは、次のとおりです。

注 –

JConsole を使用した Java プラットフォーム上のアプリケーション監視の詳細は、「JConsole を使用したアプリケーション監視」という Sun Developer Network (SDN) 記事を参照してください。次の URL から入手できます。

http://java.sun.com/developer/technicalArticles/J2SE/jconsole.html

Identity Manager には、次の点に関する情報を提供する JMX MBeans がいくつか搭載されています。

JRat の使用

潜在的なパフォーマンスボトルネックを見つけるには、Java プラットフォーム用オープンソースのパフォーマンスプロファイラである Java Runtime Analysis Toolkit (JRat) を使用します。使用中の配備でカスタム Java クラスを使用する場合は特に使用します。JRat は、使用中のアプリケーションの実行を監視し、アプリケーションのパフォーマンスの測定を維持します。

たとえば、プロビジョニングにカスタムワークフローがある場合にこの JRat を使用すると、呼び出されているクラスを表示したり、デフォルトの Identity Manager プロビジョニングワークフローと比較したワークフローの実行に掛かる時間を表示できます。

JRat の詳細は、http://jrat.sourceforge.net を参照してください。