13 Enterprise Managerデプロイメントのサイジング

Oracle Enterprise Manager Cloud Control 12cリリース12.1.0.1には、1つのEnterprise Manager実装において何百ものユーザー、何千ものシステムとサービスの規模を拡大および縮小する機能があります。

この章では、Oracle Enterprise Managerアプリケーションを使用する上で最適なパフォーマンスを得るための手法について説明します。また、大規模環境でのキャパシティ・プランニング、サイジング、Enterprise Managerのパフォーマンスの最大化にも役立ちます。ルーチン・ハウスキーピングを続け、パフォーマンスの監視を定期的に行うことで、将来的なサイジングの要件を正確に見積もるために必要なデータが得られます。Enterprise Manager Cloud Controlのバイタル・サインに対する適切なベースライン値を認識し、ベースラインに対して妥当な警告とクリティカルのしきい値を設定することで、Enterprise Managerによる監視が可能になります。

この章の内容は次のとおりです。

Oracle Enterprise Manager Cloud Controlのアーキテクチャの概要
Enterprise Manager Cloud Controlのサイジング
Enterprise Manager Cloud Controlのパフォーマンス最適化の方法
Fusion Middlewareの監視に対するリポジトリとサイジングの要件の概要

Oracle Enterprise Manager Cloud Controlのアーキテクチャの概要

Oracle Enterprise Manager Cloud Controlのアーキテクチャは、処理の分散および並列化という、アプリケーション・パフォーマンス・チューニングにおける2つの重要な概念を具現しています。Cloud Controlの各コンポーネントは、この両方の概念を応用して構成できます。

Enterprise Manager Cloud Controlには、次のコンポーネントが含まれます。

管理エージェント: 管理対象となる各ホスト上にデプロイされ、ホスト上のすべてのサービスおよびコンポーネントを監視するプロセス。また、中間層の管理サービスへのその監視情報の伝達や、システムとそのサービスの管理およびメンテナンスも行います。
管理サービス: Cloud Controlコンソールのユーザー・インタフェースをレンダリングするJ2EE Webアプリケーションで、すべての管理エージェントと連携して監視情報とジョブ情報を処理し、管理リポジトリをそのデータ・ストアとして使用します。
管理リポジトリ: スキーマは、Enterprise Manager内部で管理される管理者、サービスおよびアプリケーションに関するすべての使用可能な情報が含まれるOracleデータベースです。

Cloud Controlアーキテクチャの詳細は、Oracle Enterprise Manager Cloud Control 12cリリース12.1.0.1の次のドキュメントを参照してください。

『Oracle Enterprise Manager Grid Controlインストレーションおよび基本構成』
『Oracle Enterprise Manager概要』

Oracle Enterprise Manager 12cのドキュメントは、Oracle Technology Network (OTN)の次の場所から入手できます。

http://otn.oracle.com/documentation/oem.html

Enterprise Manager Cloud Controlのサイジング

Oracle Enterprise Managerは、可用性および拡張性に優れたデプロイメント・トポロジを備えています。この章では、Oracle Enterprise Managerデプロイメントの最初のキャパシティ・プランニングに役立つ、サイジングおよびチューニングの基本的な推奨事項について説明します。この章では、Oracle Enterprise Managerのコンポーネントおよびシステムの基本的な内容が理解されていることを前提としています。Oracle Enterprise Managerの詳細は、http://docs.oracle.com/cd/E24628_01/doc.121/e25353/overview.htmで入手できます。この情報はサイトのサイジングの起点となります。サイトごとに独自の特性があるので、必要に応じて監視やチューニングを行う必要があります。

サイジングは、Enterprise Managerのパフォーマンスを左右する重要な要素です。Enterprise Managerデプロイメントのサイズ設定が不十分であると、ユーザーが苛立ちを感じ、Enterprise Manager全体のメリットが損われてしまいます。Enterprise ManagerのOMSおよびリポジトリ層に必要なリソースは、監視対象ターゲットの数によって大きく異なります。Enterprise Managerインフラストラクチャのサイジングでは他にも考慮すべき点がたくさんありますが、次のガイドラインは、OMSおよびリポジトリ層のハードウェア・リソースの最小要件と初期構成設定を決定する際に従うことのできる簡単な手順を示しています。

サイジング・ガイドラインの概要

次の各項では、サイジング・ガイドラインの概要を説明します。

ハードウェア情報

この章で説明しているサイジング・ガイドラインは、次のハードウェアおよびオペレーティング・システムの組合せで仮想環境を実行し、取得したものです。

ハードウェア: オラクル社のSun Fire X4170 M2
ハイパーバイザー: Linux Oracle Virtual Server (64ビット)
仮想マシンのオペレーティング・システム: Oracle Enterprise Linux (64ビット)

仮想環境では、Oracle Virtual Server (OVS)ホストとそこで実行されている仮想マシンとの間にCPUの1対1マッピングが設定されていました。OVSサーバーには、メモリーをスワップさせずにすべての仮想マシンをサポートできる十分なRAMが搭載されていました。

この情報は、Oracle Enterprise Linux (64ビット)環境に基づいています。他のプラットフォームで実行する場合は、同様のハードウェア・パフォーマンスを基づいて、サイジング情報を換算する必要があります。換算にはシングル・スレッドのパフォーマンスを使用します。処理能力のベンチマーク上は総合的なマシン性能が同じであっても、24個の低速コアを持つマシンで実行する場合と12個の高速コアを持つマシンで実行する場合とでは等しくなりません。シングル・スレッドのパフォーマンスは、Enterprises Managerユーザー・インタフェースの実際のレスポンス時間を計る上で重要です。

サイジングの仕様

Oracle Enterprise Managerのサイジング・ガイドラインは、3つのサイズ(小、中、大)に分かれています。表13-1に、各サイズの定義を示します。

表13-1 Oracle Enterprise Managerサイトのサイズ

サイズ	エージェント数	ターゲット数	同時ユーザー・セッション数
小	< 100	< 1000	<10
中	>= 100, < 1000	>= 1000, < 10,000	>= 10, < 25
大	>= 1000	>= 10,000	>= 25, <= 50*

より大きなユーザー負荷については、「大規模な同時UI負荷」を参照してください。

アップグレードされたインストールのサイジング

アップグレードされたインストールの場合、sysmanユーザーとして次の問合せを実行すると、表1で使用する管理エージェント数およびターゲット数を取得できます。

エージェント数: select count(*) from mgmt_targets where target_type = 'oracle_emd'
ターゲット数: select count(*) from mgmt_targets where target_type != 'oracle_emd'

最小ハードウェア要件

表13-2に、3つの構成の最小ハードウェア要件を示します。

表13-2 Oracle Enterprise Managerの最小ハードウェア要件

サイズ	OMSマシン数*	OMS当たりのコア数	OMS当たりのメモリー(GB)	データベース・マシン数*	データベース・マシン当たりのコア数	データベース・マシン当たりのメモリー(GB)
小	1	2	6	1	2	6
中	2	4	8	2 (RAC)	4	8
大	2 4	8 4	16 8	2 (RAC) 2 (RAC)	8 8	16 16
*OMSインスタンスとデータベース・インスタンスは同じ場所に配置できません。

ネットワーク・トポロジの考慮事項

Enterprise Manager Cloud Controlをデプロイする際、各層間のネットワーク・パフォーマンスを第一に考慮する必要があります。Enterprise Manager Cloud Controlでは、各アプリケーション層間のネットワークの異常、障害および故障に対するトレランスが、エラー・トレランスおよびエラー・リカバリによって保証されています。特に管理エージェントは、Enterprise Manager全体のパフォーマンスに大きな影響を与えることなく、パフォーマンスや信頼性の低い、管理サービスへのネットワーク・リンクを処理できます。ネットワークの問題が原因で起こる1つの管理エージェント・データの遅延に関するかぎり、その影響はEnterprise Manager Cloud Controlのシステムワイドなレベルではほとんど気づかない程度のものです。

ただし、管理サービスと管理リポジトリの間のネットワーク待機時間については、わずかに増えるのみでその影響は大きくなります。Enterprise Manager Cloud Controlの実装では、管理サービスと管理リポジトリの間のネットワーク・リンクの品質が十分でない場合に、重大なパフォーマンス問題が発生することがわかっています。

管理サービスのホストとリポジトリのホストは、相互に近接した場所に配置します。理想的には、2つの間のラウンドトリップ・ネットワーク待機時間が1ミリ秒未満になるようにする必要があります。

ソフトウェア構成

次の各項では、小規模、中規模、大規模の各構成について説明します。

小規模の構成

小規模の構成は、Oracle Enterprise Managerのインストーラによって要求される最小要件に基づきます。

最小OMS設定

追加設定は不要です。

最小データベース設定

表13-3に、推奨される最小データベース設定を示します。

表13-3 小規模サイトの最小データベース設定

パラメータ	最小値
*sga_targetおよびpga_aggregate_targetのかわりに、3GBのmemory_targetを使用できます。
processes	300
pga_aggregate_target*	1024M
sga_target*	2G
REDOログ・ファイルのサイズ	300M
shared_pool_size	600M

中規模の構成

中規模の構成では、Oracle Enterprise Managerのデフォルト設定をいくつか変更します。

最小OMS設定

Oracle Management Service (OMS)のヒープ・サイズを4096mに設定する必要があります。

最小リポジトリ・データベース設定

表13-4に、中規模の構成で推奨される最小リポジトリ・データベース設定を示します。

表13-4 中規模サイトの最小データベース設定

パラメータ	最小値
*sga_targetおよびpga_aggregate_targetのかわりに、5.25GBのmemory_targetを使用できます。
processes	600
pga_aggregate_target*	1280M
sga_target*	4G
REDOログ・ファイルのサイズ	600M
shared_pool_size	600M

大規模の構成

大規模の構成では、Oracle Enterprise Managerのデフォルト設定をいくつか変更します。

最小OMS設定

表13-5に、大規模の構成で推奨される最小OMS設定を示します。

表13-5 大規模サイトの最小OMS設定

OMS数	ヒープ・サイズの最小値
2	8192M
4	4096M

最小リポジトリ・データベース設定

表13-6に、大規模の構成で推奨される最小リポジトリ・データベース設定を示します。

表13-6 大規模サイトの最小データベース設定

パラメータ	最小値
*sga_targetおよびpga_aggregate_targetのかわりに、7.5GBのmemory_targetを使用できます。
processes	1000
pga_aggregate_target*	1536M
sga_target*	6G
REDOログ・ファイルのサイズ	1000M
shared_pool_size	600M

リポジトリ表領域のサイジング

表13-7は、管理リポジトリに必要な最小記憶域要件を示しています。

表13-7 管理リポジトリ記憶域の合計

デプロイ・サイズ	最小表領域サイズ*
デプロイ・サイズ	SYSTEM**	MGMT_TABLESPACE	MGMT_ECM_DEPOT_TS	MGMT_AD4J_TS	TEMP
これらはあくまで最小値であり、大まかな指針を示すのみです。MGMT_TABLESPACEの実際のサイズは、ターゲット・タイプの分布、ユーザー・カスタマイズやその他の要因の違いによって、デプロイメントごとに大きく異なります。これらの表領域は、領域制約の問題が軽減されるよう、デフォルトではAUTOEXTENDがONで定義されています。RAWファイル・システムでは、領域制約の問題を回避できるよう最小サイズより大きい値を使用することをお薦めします。 *SYSTEMおよびTEMPの各表領域のサイズは、Enterprise Managerのみが使用するリポジトリ用の最小値です。Enterprise Managerが他のアプリケーションとリポジトリ・データベースを共有している場合、これらの最小値は小さすぎる場合があります。注意: Enterprise Manager 11gの自動拡張ファイルとともにアラートを使用して、表領域を監視することはできません。表領域の管理の制御を強化する場合は、TABLESPACE FULLアラートが生成されるよう設定し、そうでない場合は、AUTOEXTEND機能を使用してデータベースの拡張を許可し、アラートが生成されないようにします。したがって、TABLESPACE FULLアラートの制御を強化するには、自動拡張を無効にします。
小	600MB	50GB	1GB	100MB	10GB
中	600MB	200GB	4GB	200MB	20GB
大	600MB	300GB	4GBよりも大きい	400MB	40GB

追加の構成

Enterprise Managerのインストールでは、個々のシステム負荷が大きいと、追加のチューニング設定が必要になる場合があります。追加設定を次に示します。

大規模な同時UI負荷

OMSごとに50を超える同時ユーザーが予想される場合は、次の設定を表13-8のとおり修正する必要があります。

表13-8 大規模な同時UI負荷の追加設定

プロセス	パラメータ	値	設定対象
OMS	-Djbo.recyclethreshold	同時ユーザー数/OMS数	OMS別
OMS	-Djbo.ampool.maxavailablesize	同時ユーザー数/OMS数	OMS別
OMS	ヒープ・サイズ	50ユーザー増加するたびに4GB追加	OMS別
データベース	sga_target	50ユーザー増加するたびに1GB追加	インスタンス別

ユーザー負荷が高くなるほど、必要なハードウェア容量が増加します。50同時ユーザーごとに、データベース・ホストとOMSホストの両方に2コアを追加します。

例: エージェント数1500、ターゲット数15,000、同時ユーザー数150のサイトでは、表13-9に示した設定変更が最小限必要です(2 OMSの大規模な構成に基づく)。

表13-9 2 OMS構成の大規模な同時UI負荷の追加設定の例

プロセス	パラメータ	値	計算
OMS	-Djbo.recyclethreshold	75 (OMSごとに設定)	150ユーザー/2 OMS
OMS	-Djbo.ampool.maxavailablesize	75 (OMSごとに設定)	150ユーザー/2 OMS
OMS	ヒープ・サイズ	12GB (OMSごとに設定)	8GB (標準的な大規模設定) + ((150ユーザー - 50大規模なユーザー負荷のデフォルト)/2 OMS)* (4GB/50ユーザー)
データベース	sga_target	8GB	6GB (標準的な大規模設定) + (150ユーザー - 50大規模なユーザー負荷のデフォルト)* (1GB/50ユーザー)

表13-10に、追加ハードウェアの最小要件を示します。

表13-10 2 OMS構成の大規模な同時UI負荷の最小追加ハードウェアの例

層	パラメータ	値	計算
OMS	CPUコア数	24 (すべてのOMSホスト間の合計)	8コア * 2 OMS (大規模なコア数のデフォルト) + (150ユーザー - 50大規模なユーザー負荷のデフォルト) (2コア 2 OMS)/50ユーザー)
データベース	CPUコア数	24 (すべてのデータベース・ホスト間の合計)	8コア * 2 OMS (大規模なコア数のデフォルト) + (150ユーザー - 50大規模なユーザー負荷のデフォルト) (2コア 2 OMS/50ユーザー)

この構成を実行できるようにするには、各マシンの物理メモリーも増設する必要があります。

BI Publisherの構成

BI Publisherリリース11.1.1.5とEnterprise Managerリリース12c Cloud Controlとの統合(BI Publisherレポートが機能するために必要)を予定している場合、前述のホストのメモリー要件に1.5GBを加えてください。

Enterprise Manager Cloud Controlのパフォーマンス最適化の方法

拡大/縮小時に容量を正確に予測するために必要なのは、各Enterprise Manager Cloud Controlデプロイメントからの実際のメトリック傾向情報です。この情報と大まかな初期ホスト・システム・サイズの設定、チューニングとメンテナンスの繰返しの実行を組み合せることが、Enterprise Manager Cloud Controlデプロイメントの容量を予測する最も効果的な方法になります。また、デプロイメントのパフォーマンスを最適に保つことにも役立ちます。

Enterprise Manager Cloud Controlのサイジング手法の実施手順は、次のとおりです。

まだEnterprise Manager Cloud Controlをインストールしていない場合は、表13-1に示すように、大まかな初期ホスト構成を選択します。
定期的にサイトのバイタル・サインを評価します(後述)。
DBAおよびEnterprise Manager管理のルーチン・ハウスキーピングを使用してボトルネックを排除します。
チューニングを使用してボトルネックを排除します。
今後に向けた直線外挿を行うことにより、将来のサイジング要件を計画します。

手順1は、各デプロイにつき1回行うのみで済みます。手順2、3および4は、Enterprise Manager Cloud Controlサイトを拡大する計画があるかどうかにかかわらず、デプロイが存続しているかぎり定期的に行う必要があります。これらの手順は、Enterprise Manager Cloud Controlサイトのサイズや処理負荷にかかわらず、効率的なEnterprise Manager Cloud Controlサイトにとって不可欠です。手順5に進むには、手順2、3および4を完了しておく必要があります。これは非常に重要です。手順5が必要となるのは、監視対象ターゲットの数を増やしてデプロイ・サイズを拡大しようとする場合のみです。ただし、これらの傾向を定期的に評価することは、デプロイに行われた他の変更を評価するうえでも役立ちます。

手順1: 最初のプラットフォームのCloud Controlデプロイの選択

最初のプラットフォームのCloud Controlデプロイの選択については、「サイジング・ガイドラインの概要」を参照してください。

手順2: サイトのバイタル・サインの定期的な評価

これが、5つの中で最も重要な手順です。Enterprise Manager Cloud Controlサイトのバイタル・サインの傾向や大きな変動をある程度監視および理解しておかないと、サイトのパフォーマンスが重大なリスクに晒されることになります。監視対象ターゲットはそれぞれ、関連付けられた管理エージェントを介して、ロードおよび集計のためにデータを管理リポジトリに送信します。これは、他のエンタープライズ・アプリケーションと同レベルの管理およびメンテナンスを必要とする大量のアクティビティになります。

Enterprise Managerには、その状態を反映するバイタル・サインがあります。これらのバイタル・サインは、設定したベースラインしきい値と比較して、その傾向を一定期間監視する必要があります。パフォーマンスが許容可能なときのバイタル・サインの現実的なベースラインを設定する必要があります。ベースラインを設定した後は、Oracle Enterprise Manager Cloud Controlの組込み機能を使用して、警告およびクリティカルのしきい値を設定できます。これにより、Enterprise Managerサイトに重大な変更があった場合は自動的に通知されます。次の表に、2つのサイトにおけるEnterprise Manager Cloud Controlのバイタル・サインのポイント・イン・タイム・スナップショットを示します。

モジュール	メトリック	EMサイト1	EMサイト2
サイトURL		emsite1.acme.com	emsite2.acme.com

ターゲットの数	データベース・ターゲット	192(45は起動されていない)	1218(634は起動されていない)
	ホスト・ターゲット	833(12は起動されていない)	1042(236は起動されていない)

	ターゲット合計	2580(306は起動されていない)	12293(6668は起動されていない)

ローダー統計	ローダー・スレッド	6	16
	合計行/時間	1,692,000	2,736,000
	行/時間/ロード/スレッド	282,000	171,000
	行/秒/ロード/スレッド	475	187
	実行時間の割合	15	44

ロールアップ統計	1秒当たりの行	2,267	417
	実行時間の割合	5	19

ジョブ統計	ジョブ・ディスパッチャ	2	4
	ジョブ・ステップ/秒/ディスパッチャ	32	10

イベント統計	処理されたイベント(過去1時間)	536	1,100

管理サービス・ホスト統計	平均のCPU割合(ホスト1)	9(emhost01)	13(emhost01)
	平均のCPU割合(ホスト2)	6(emhost02)	17(emhost02)
	平均のCPU割合(ホスト3)	該当なし	38(em6003)
	平均のCPU割合(ホスト4)	該当なし	12(em6004)
	ホスト当たりのCPU数	2 X 2.8(Xeon)	4 X 2.4(Xeon)
	ホスト当たりのメモリー(GB)	6	6

管理リポジトリ・ホスト統計	平均のCPU割合(ホスト1)	12(db01rac)	32(em6001rac)
	平均のCPU割合(ホスト2)
	平均のCPU割合(ホスト3)
	平均のCPU割合(ホスト4)
	ホスト当たりのCPU数
	バッファ・キャッシュ・サイズ(MB)
	ホスト当たりのメモリー(GB)	6	12
	管理リポジトリ・サイズの合計(GB)	56	98
	RACインターコネクト・トラフィック(MB/秒)	1	4
	管理サーバー・トラフィック(MB/秒)	4	4
	管理リポジトリI/Oの合計(MB/秒)	6	27

1秒当たりのEnterprise Manager UIページのレスポンス	ホームページ	3	6
	すべてのホスト・ページ	3	30+
	すべてのデータベース・ページ	6	30+
	データベースのホームページ	2	2
	ホストのホームページ	2	2

この2つのEnterprise Managerサイトのパフォーマンスは対極的です。

EMサイト1は、ローダーの行/秒/スレッドとロールアップの行/秒の値が大きく、非常に高いパフォーマンスを示しています。また、ローダーおよびロールアップの実行時間の割合が非常に低くなっています。OMSホストと管理リポジトリ・サーバー・ホストのCPU使用率は両方とも低い値です。最も重要なのは、UIページのレスポンス時間が非常に優れていることです。つまり、サイト1では最小限の労力で多くの処理が行われています。構成、チューニングおよびメンテナンスが適切に行われたOracle Enterprise Manager Cloud Controlサイトは、このような状態になります。

これに対し、EMサイト2には問題があります。ローダーおよびロールアップでの行の処理効率がよくありません。最も大きな問題は、UIページのレスポンス時間です。サイト2にボトルネックが存在するのは明らかです。複数のボトルネックがある可能性があります。

次の表に、概要が示された構成で実行されたテストに基づく様々なモジュールのメトリック・ガイドラインを示します。指定された環境で使用されるメトリックとテスト環境に基づき、情報とデータを推定するための参照ポイントとして役立ちます。

表13-11 テスト環境に基づくモジュールのメトリックのガイドライン

モジュール	メトリック	値	テスト環境
ローダー統計	NA	NA	OMS詳細 OMSホストの数 = 2 ホスト当たりのCPUの数 = 4 Intel Xeon メモリー = 6GB リポジトリ詳細リポジトリ・ノードの数 = 2 ホスト当たりのCPUの数 = 4 Intel Xeon メモリー = 6GB EM詳細共有受信ディレクトリ = Yes エージェントの数 = 867 ホストの数 = 867 ターゲット合計 = 1803 メトリックは、2つのOMSインスタンスが起動して各エージェントのアップロード・バックログ・ファイルが50MBになってから5時間収集されます。
	合計行/時間	4,270,652
	行/時間/ローダー・スレッド	427,065
	行/秒/ローダー・スレッド	120
ロールアップ統計	1秒当たりの行
ジョブ統計	ジョブ・ディスパッチャ	1 x OMSインスタンスの数
ジョブ統計	ジョブ・ステップ/秒/ディスパッチャ
通知統計	1秒当たりの通知	16	OMS詳細 OMSホストの数 = 1 ホスト当たりのCPUの数 = 4 Intel Xeon メモリー = 6GB リポジトリ詳細リポジトリ・ノードの数 = 1 ホスト当たりのCPUの数 = 4 Intel Xeon メモリー = 6GB EM詳細 OMSインスタンスの数 = 1 リポジトリ・ノードの数 = 1 エージェントの数 = 2474 ホストの数 = 2474 データベース・ターゲット合計 = 8361
アラート統計	1時間当たりのアラート	7200	OMS詳細 OMSホストの数 = 1 ホスト当たりのCPUの数 = 4 Intel Xeon メモリー = 6 GB リポジトリ詳細リポジトリ・ノードの数 = 1 ホスト当たりのCPUの数 = 4 Intel Xeon メモリー = 6 GB EM詳細 OMSインスタンスの数 = 1 リポジトリ・ノードの数 = 1 エージェントの数 = 2474 ホストの数 = 2474 データベース・ターゲット合計 = 8361
管理サービス・ホスト統計	平均のCPU割合(ホスト1)	31%	OMS詳細 OMSホストの数 = 2 ホスト当たりのCPUの数 = 4 Intel Xeon メモリー = 6 GB リポジトリ詳細リポジトリ・ノードの数 = 2 ホスト当たりのCPUの数 = 4 Intel Xeon メモリー = 6 GB EM詳細共有受信ディレクトリ = Yes エージェントの数 = 867 ホストの数 = 867 ターゲット合計 = 1803 メトリックは、2つのOMSインスタンスが起動して各エージェントのアップロード・バックログ・ファイルが50MBになってから5時間収集されます。
	平均のCPU割合(ホスト2)	34%
	ホスト当たりのCPU数	4(Xeon)
	ホスト当たりのメモリー(GB)	6
管理リポジトリ・ホスト統計	平均のCPU割合(ホスト1)	32%	OMS詳細 OMSホストの数 = 2 ホスト当たりのCPUの数 = 4 Intel Xeon メモリー = 6 GB リポジトリ詳細リポジトリ・ノードの数 = 2 ホスト当たりのCPUの数 = 4 Intel Xeon メモリー = 6 GB EM詳細共有受信ディレクトリ = Yes エージェントの数 = 867 ホストの数 = 867 ターゲット合計 = 1803 メトリックは、2つのOMSインスタンスが起動して各エージェントのアップロード・バックログ・ファイルが50MBになってから5時間収集されます。
	平均のCPU割合(ホスト2)	26%
	ホスト当たりのCPU数	4
	SGAターゲット	2GB
	ホスト当たりのメモリー(GB)	6
	管理リポジトリ・サイズの合計(GB)	94
	RACインターコネクト・トラフィック(MB/秒)	1
	管理サーバー・トラフィック(MB/秒)
	管理リポジトリI/Oの合計(MB/秒)
1秒当たりのEnterprise Manager UIページのレスポンス	ホームページ	9.1秒	OMS詳細 OMSホストの数 = 1 ホスト当たりのCPUの数 = 4 Intel Xeon メモリー = 6 GB リポジトリ詳細リポジトリ・ノードの数 = 1 ホスト当たりのCPUの数 = 4 Intel Xeon メモリー = 6 GB EM詳細 OMSインスタンスの数 = 1 リポジトリ・ノードの数 = 1 エージェントの数 = 2474 ホストの数 = 2474 データベース・ターゲット合計 = 8361
	すべてのホスト・ページ	9.8秒
	すべてのデータベース・ページ	5.7秒
	データベースのホームページ	1.7秒
	ホストのホームページ	< 1秒

これらのバイタル・サインはすべて、Enterprise Managerインタフェースから取得できます。ほとんどの値は各ホストの「すべてのメトリック」ページまたはOMSの「すべてのメトリック」ページに表示されます。警告およびクリティカルのアラートにしきい値を割り当て、これらのバイタル・サインの傾向を一定期間観察することで、良好なパフォーマンスを維持し、将来のリソース要件を予測できます。次のようにして、これらのバイタル・サインの監視を計画してください。

前出の表に示された、Enterprise Manager Cloud Controlサイトが良好に動作しているときのバイタル・サイン値のベースラインを測定します。
これらのベースライン値に基づいて妥当なしきい値および通知を設定し、正常な値から大きく逸脱した場合には自動的に通知されるようにします。このとき、サイトのしきい値を何度か繰返して微調整する必要があることがあります。受け取る通知が多すぎても役に立ちません。
1日(最低でも1週間)に1回、グラフで7日間にわたるこれらの値の傾向を監視します。これにより、近い将来に起こりうる問題を発見し、将来のリソース要件の計画を立てることができます。

次の手順で、バイタル・サインの値が設定済しきい値の範囲にない場合に行う操作を示します。また、ルーチン・ハウスキーピングを通してサイトのパフォーマンスを維持する方法についても説明します。

手順3: DBAおよびEnterprise Managerタスクを使用したボトルネックの排除

Enterprise Manager Cloud Controlサイトの動作を良好に保つために、ルーチン・ハウスキーピングが役立つことを覚えておくことが重要です。次に、ハウスキーピングのタスクとその適切な実行間隔を示します。

月に1回のオフライン・タスク

Enterprise Manager管理者は、Enterprise Managerリポジトリのセグメントの状態に関する推奨事項として、データベース内蔵のセグメント・アドバイザを監視する必要があります。セグメント・アドバイザは、どのセグメントを再構築/再編成する必要があるかを管理者に知らせ、その実行のためのコマンドを提供します。

セグメント・アドバイザと、システム状態に関連する問題の詳細は、My Oracle Supportナレッジ・ベースのノート242736.1および314112.1を参照してください。

手順4: チューニングによるボトルネックの排除

Enterprise Manager Cloud Controlアプリケーションのパフォーマンスのボトルネックの代表的な原因を次に(頻度の高い順に)示します。

ハウスキーピングを実行していない(パフォーマンス問題の最大の原因)
ハードウェアまたはソフトウェアが適切に構成されていない
ハードウェア・リソースの枯渇

バイタル・サインが日常的に設定済しきい値の範囲外にある場合、または一定期間そのような傾向を示している場合は、2つの領域に対処する必要があります。まず、前述したすべてのハウスキーピングが最近行われていることを確認します。2番目に、Enterprise Manager Cloud Controlアプリケーションのリソース使用率に注意する必要があります。前出の表に列記したバイタル・サインは、Enterprise Manager Cloud Controlのリソース使用率およびスループットのキー・ポイントを反映しています。次の各項で、重要なバイタル・サインのいくつかを説明し、ベースライン値に基づいて設定されたしきい値を超えたバイタル・サインに対処するために使用可能なオプションを示します。

高いCPU使用率

サイトのパフォーマンスを評価するように求められ、高いCPU使用率に気づいた場合、どのリソースがどの場所で使用されているかを判断するために、いくつか手順を実行する必要があります。

Enterprise Managerホストのホームページの「プロセス」画面を使用して、CPUのしきい値を超えた管理サービス・ホストまたは管理リポジトリ・ホストで最も多くのCPUを消費しているプロセスを判別します。
Enterprise Managerが最も多くのCPUを消費していることが明確になった場合は、Enterprise Managerを使用して、最も多くのCPUを消費しているアクティビティを特定します。これは通常、管理サービスの処理のほとんどが実行される管理リポジトリ・ホスト上に存在します。管理リポジトリが過剰にリソースを使用していると考えられる場合、一般的に次の点を調べる必要があります。
1. 管理リポジトリの「データベース・パフォーマンス」ページにリストされた「使用中のCPU」データベース・リソースをクリックして、管理リポジトリで最も多くCPUを使用しているSQLを調べます。
2. 管理リポジトリの「データベース・パフォーマンス」ページの「データベース・ロック」で、競合問題がないか確認します。

パフォーマンスのボトルネックの兆候として最も多いのは、高いCPU使用率です。通常は、管理リポジトリが最も多くCPUを消費しており、管理リポジトリを重点的に調べる必要があります。ハードウェア・リソースの制約が特になく、適切に構成およびメンテナンスが行われた管理リポジトリ・ホスト・システムの場合、CPU使用率の合計は平均して約40%以下になります。OMSホスト・システムのCPU使用率の合計は、平均して約20%以下である必要があります。平均値がこのように比較的低い場合は、アクティビティの急な増加にも十分に対応できます。アクティビティの急な増加を許容することで、ページ・パフォーマンスを長期間にわたって安定させることができます。Enterprise Manager Cloud Controlサイトのインタフェース・ページのレスポンスが良好(約3秒)で、大きなローダー・バックログが(常に)存在しない場合、CPUの使用率が推奨値を超えていても、大幅な上昇傾向にあると考えられる場合を除き、対処する必要はありません。

管理リポジトリのCPU使用率が高い場合、その根本的な原因を突き止めるために、前述の手順3.bを行うことをお薦めします。これにより、管理リポジトリの「パフォーマンス」ページから、処理で最も多くCPUを消費しているSQLを突き止めることができます。この方法は、いくつかの実際のサイトで使用され、成功しています。

Intelベースのホスト上でEnterprise Managerを実行している場合は、Enterprise Manager Cloud Control管理サービスと管理リポジトリの両方が、デプロイ先のホスト上で有効になっているハイパースレッディング(HT)のメリットを得られます。HTはIntelプロセッサの特定の最新モデルの機能であり、一定量のCPU命令のパラレルな実行を可能にするものです。これによって、システム上で物理的に使用可能なCPUの数は倍増します。HTを使用した場合、HTが使用可能になっていない同じシステムに比べて、CPU処理能力が約1.5倍になることがテストで実証されています。これにより、大幅にシステム・パフォーマンスを向上させることができます。管理サービスと管理リポジトリはどちらも複数のプロセスを同時に実行することが多いため、HTを使用するメリットは非常に大きくなります。

ローダーのバイタル・サイン

ローダーのバイタル・サインは、すべてのEnterprise Managerエージェントからシステムに絶えず送り込まれるデータの正確な量を示します。ここで最も重要な項目は、実行時間の割合と行/秒/スレッドです。(ローダーの)実行時間の割合は、構成されているローダー・スレッドが受信データ・ボリュームの処理に対応しているかどうかを示します。この値が100%に近づくにつれて、ロード・プロセスが受信データ・ボリュームの処理に対応できていないことが明らかになります。この値が低いほど、ローダーの実行効率は高く、ローダーが管理サービス・ホストから必要とするリソースは少なくなります。OMSにローダー・スレッドを追加すると、ローダーの実行時間の割合を減らすのに役立ちます。

行/秒/スレッドは、1秒当たりの各ローダー・スレッドのスループットの正確な測定値です。この数値が高いほど良好です。適切に構成およびメンテナンスされた小規模なEnterprise Manager Cloud Controlサイトでは、行/秒/スレッドの値が1200に達する場合が観察されています。ローダー・スレッド数を増やしておらず、この数値が下降傾向にある場合、将来的に問題が起こる可能性があります。行/秒/スレッドの値の減少に対処するには、ローダー・スレッドを追加する方法があります。

OMS構成ファイル内では、ローダー・スレッドの数はデフォルトで常に1に設定されます。OMS1つにつき、最大10までのローダー・スレッドを持つことができます。多数の管理エージェントが構成されているEnterprise Manager Cloud Controlサイトでは、OMSにローダー・スレッドを追加すると、通常は全体のホストCPU使用率が2から5%増加します。この値は、サイトの必要性に応じて変更できます。中規模および小規模の構成では、複数のローダー・スレッドが必要になることはほとんどありません。ローダー・スレッドを追加する際の簡単なガイドラインを次に示します。

(すべてのOMS全体での)最大合計ローダー・スレッド= 2×管理リポジトリ・ホストのCPUの数

ローダー・スレッドを追加する際には、収穫逓減が働きます。2つ目(またはそれ以上)のスレッドを追加すれば100%の能力が得られるわけではありません。ただし、プラスの効果もあります。ローダー・スレッドを追加すると、行/秒/スレッドは減少しますが、合計行/時間のスループットは増加します。合計行/時間の値に大きな改善が見られず、ローダー・ファイルのバックログ・サイズが拡大し続けている場合、ローダー・スレッドの数を増やしてもそのコストに見合ない可能性があります。この場合は、他のチューニングまたはハウスキーピングの機会を探る必要があります。

ローダー・スレッドを追加するには、次の構成パラメータを変更します。nは正の整数1から10です。

em.loader.threadPoolSize=n

デフォルトは1で、1から10以外の値を指定した場合、スレッド・プール・サイズはデフォルトの1に設定されます。このプロパティ・ファイルは、{ORACLE_HOME}/sysman/configディレクトリ内にあります。このパラメータを変更した場合、管理サービスを再起動して新しい値とともに再ロードすることが必要になります。

次の2つのパラメータは、エージェントからファイルを受信するレシーバ・モジュールに設定されます。

em.loader.maxDataRecvThreads=n(デフォルトは75)

nは正の整数で、デフォルト値は75です。これは、同時データ・ファイルの受信者スレッドの最大数を制限する場合に使用されます。そのため、ピーク時には75の受信者スレッドのみがファイルを受信し、その他のリクエストはサーバー・ビジー・エラーで拒否されます。これらの拒否されたリクエストは、デフォルトの再試行時間が経過するとエージェントによって再送信されます。

この値の設定が高すぎると、OMSマシンと共有受信ディレクトリ・マシンへの負荷が高くなるため注意してください。値の設定が低すぎると、データ・ファイルの受信スループットは小さくなります。
oracle.sysman.emRep.dbConn.maxConnForReceiver=n(デフォルトは25)

nは正の整数で、デフォルト値は25です。これは、受信スレッドのリポジトリ・データベース接続の最大数の設定に使用されます。各受信者スレッドが1つのDBセッションを取得し、DB接続を待機しないよう、この値をem.loader.maxDataRecvThreadsと同じ値に設定することをお薦めします。

ロールアップのバイタル・サイン

ロールアップ・プロセスは、Enterprise Manager Cloud Controlの集計メカニズムです。ロールアップの2つのバイタル・サインは、行/秒と実行時間の割合です。ロールアップでは大量のデータ行が処理されるため、管理リポジトリのバッファ・キャッシュ領域を最も多く消費する傾向があります。このため、ロールアップのバイタル・サインを調べることで、バッファ・キャッシュ・サイズの拡大により効果が得られるかどうかを判断できます。

ロールアップの行/秒は、1秒間に処理または集計されて格納された行の正確な数を示します。バッファ・キャッシュのサイズが適切で、I/Oの速度も妥当なサイトでは、通常この値は1秒当たり約2,000行(+/- 500)です。この値が一定期間下降傾向を示している場合、将来的に問題が発生する可能性がありますが、実行時間の割合が100未満であれば、そのサイトは問題ないと考えられます。

ロールアップの実行時間の割合が上昇傾向にある(またはベースラインを超えている)場合、管理リポジトリのバッファ・キャッシュをまだ最大値に設定していなければ、バッファ・キャッシュ設定値を大きくすると効果があることがあります。通常は、バッファ・キャッシュを大きくするメリットがある場合には、管理リポジトリ・ホストのリソース使用率およびスループットが全体的に向上します。ローダー統計は多少改善されます。ホストのCPU使用率は低下し、I/Oは減少します。改善が最も顕著なのは、ロールアップ統計です。ロールアップの行/秒と実行時間の割合の両方で明らかな改善が見られます。これらのバイタル・サインのいずれにも改善が見られない場合、バッファ・キャッシュを以前のサイズに戻してもかまいません。古いバッファ・キャッシュ・ヒット率は、誤解を招く場合があります。バッファ・キャッシュが非常に小さいためにEnterprise Manager Cloud Controlのパフォーマンスが低下している場合に、バッファ・キャッシュ・ヒット率の値が高くなることがテストで観察されています。バッファ・キャッシュを大きくしてもCloud Controlのパフォーマンスが改善されない場合もあります。通常、これはアプリケーションの他の場所でリソース制約や競合があるためです。「高いCPU使用率」の項に示された手順を使用して、競合の場所を特定することを検討してください。また、Cloud Controlでは、データベース自体からバッファ・キャッシュのサイズ設定に関するアドバイスを提供します。これは、データベースの「メモリー・パラメータ」ページで使用可能です。

バッファ・キャッシュの拡大を検討する際には、オペレーティング・システムにEnterprise Manager Cloud Controlのパフォーマンスの改善に役立つメカニズムが存在する可能性があることに注意してください。たとえば、Red Hat Linuxで使用可能なlarge memoryオプションがその一例です。Linux OS Red Hat Advanced Server(tm) 2.1(RHAS)には、big pagesという機能があります。RHAS 2.1では、bigpagesは大きな共有メモリー・セグメントの事前割当てに使用できる起動パラメータです。この機能を大きな管理リポジトリSGAとあわせて使用することで、Cloud Controlアプリケーション全体のパフォーマンスを大幅に向上させることができます。Red Hat Enterprise Linux(tm) 3からは、big pages機能はhuge pagesと呼ばれる新機能にかわり、起動パラメータは必要なくなりました。

ロールアップ・プロセス

ロールアップ・プロセスには、ロールアップ参加インスタンスという概念が導入されています。ロールアップ処理は、すべての参加インスタンス間で分散されます。参加するEMROLLUPグループに候補インスタンスを追加するには、パラメータinstance_groupsをインスタンス・レベルで次のように設定する必要があります。

ノード1の場合、instance_groupパラメータにEMROLLUP_1を追加します。

ノード2の場合、instance_groupパラメータにEMROLLUP_2を追加します。
PQおよびPWパラレル処理モードを導入しています。
- PQはパラレル問合せ/パラレルdmlモードです。このモードでは、各参加インスタンスに、指定された並列度を利用する1つのワーカーが設定されています。
- PWはパラレル・ワーカー・モードです。このモードでは、各参加インスタンスに、指定されたパラレル・レベルに等しい数のワーカー・ジョブがあります。
すべての参加RACインスタンスのワークロードを次のように分散します。
- 各参加インスタンスには、同じ数のターゲットが割り当てられます。参加インスタンス数が(n)でワークロードの合計が(tl)の場合、各インスタンスには(tl/n)が割り当てられます。
- 参加インスタンスの各ワーカーには、該当インスタンスのワークロードの同じ数のターゲットが割り当てられます。インスタンス当たりのターゲット数が(il)でワーカー数が(w)の場合、各ワーカーには(il/w)が割り当てられます。
- 負荷はワーカーごとにバッチに分割され、ロールアップSQLの実行回数を制御します。バッチ当たりの行数は、ワーカーに割り当てられた行の総数をバッチ回数で除算したものになります。

ロールアップ処理時のガイドラインとして次の推奨事項を使用します。

パラレル・ワーカー(PW)・モードを使用し、参加するEMROLLUP_xxインスタンス・グループを利用します。
パラレル・ワーカー・モードの使用をお薦めします。
より多くのワーカー間で作業を分割すると、収穫逓減ルールが適用されるまでパフォーマンスとスケーラビリティが向上します。これは、各RACモードで使用可能なCPUの数によって異なります。このテスト・ケースでは、レスポンス時間、マシンのCPUとIO使用率との兼合いから、10のワーカーによる実行が最適な構成でした。
適切なバッチ・サイズを設定することが重要です(推奨は10)。メインSQL (EMD_1HOUR_ROLLUPと呼ばれる)の実行回数と各実行に必要なソート領域との兼合いから、バッチ回数10回が最適な実行でした。
バッチ回数を10に設定して開始してください。バッチ回数はデータ分散に基づいて変更できます。

前述の推奨事項によって次の結果が得られます。(前述の再設計されたコードで)マルチインスタンス・パラレル・ワーカー(8 PW)・モードを使用すると、2つの参加RACインスタンスの利用時にパフォーマンスは9から13倍改善されます。

MGMT_METRICS_1HOURのロールアップ行数(百万単位)	時間(分)	ワーカー	バッチ・サイズ
29.5	30	8	1
9.4	5	8	10
テスト全体では、15779の明確なTARGET_GUIDがありました。テストによって、MGMT_METRICS_1HOURで“29.5百万”の新しいロールアップ行が生成されました。

実行**	行/ワーカー	バッチ/ワーカー	行/バッチ	時間(分)
8PW/1インスタンス	3945	3945	1	40
8PW/2インスタンス	1973	1973	1	30

ジョブ、通知およびアラートのバイタル・サイン

ジョブ、通知およびアラートは、Enterprise Manager Cloud Controlサイトの管理サービスの処理効率を示します。これらの値がよくない傾向を示している場合、通常はアプリケーションの他の場所に競合があります。これらの値の有効な使用方法は、複数のOMSを使用して実行した場合のメリットを測定することです。各OMSにはジョブ・ディスパッチャが1つずつあります。OMSインスタンスを追加しても、必ずしもこれらの値が改善されるわけではありません。一般に、アプリケーションにリソース競合問題が存在していなければ、OMSインスタンスを追加することでCloud Controlの全体のスループットが改善します。その改善の程度を測定するには、ジョブ、通知およびアラートのバイタル・サインが役立ちます。

I/Oのバイタル・サイン

Enterprise Manager Cloud Controlデプロイにおける様々なチャネルのI/Oスループットを監視することは、良好なパフォーマンスを実現するうえで不可欠です。少なくとも次の3つの異なるI/Oチャネルに対して、ベースラインおよびアラートのしきい値を定義する必要があります。

管理リポジトリ・インスタンスからそのデータファイルへのディスクI/O
OMSと管理リポジトリの間のネットワークI/O
RACインターコネクト(ネットワーク)I/O(RACシステムの場合のみ)

これらのチャネルそれぞれについて、最大スループットおよび持続的スループットI/O機能を理解しておく必要があります。この情報および設定したベースライン値から、Cloud Controlで警告およびクリティカルのアラートの妥当なしきい値を導き出すことができます。しきい値を設定した後は、サイトでこれらのしきい値に近づいた場合に、自動的に通知されます。Cloud Controlのサイト管理者でも、サイトでこれらのI/Oチャネルが処理できる内容を知らなかったり、誤解していることがあります。このような場合、Enterprise Manager Cloud Controlがこれらのチャネルに過度な処理をさせることになり、それによってサイトのパフォーマンスは低下します。このような状況では、多くのバイタル・サインがその影響でよくない値を示します。

管理リポジトリが関連しているかどうかを調べるには、Cloud Controlを使用して「データベース・パフォーマンス」ページを確認します。管理リポジトリの「パフォーマンス」ページで、最大消費時間を示す待機グラフをクリックします。このグラフから、実際に待機しているSQLコードまたはセッションにドリルダウンできます。これは、ボトルネックの原因となっている箇所を理解するために役立ちます。

確認するもう1つの領域は、バックアップや別のアプリケーション、複雑なSQL問合せや複数のデカルト積などを使用してデータ・マイニングをしている社員がいる場合など、Enterprise Manager Cloud Control以外のソースからの予期しないI/Oロードです。

リポジトリI/Oの合計に関連する問題は、2つの要因により発生します。1つ目は、定期的にハウスキーピングが行われていないことです。Cloud Controlセグメントの一部が過度に断片化されるため、深刻なI/Oドレインが発生することがあります。2つ目に、適切にチューニングされていないSQL文がサイトのI/O帯域幅の大部分を消費している可能性もあります。Cloud Controlの多くのバイタル・サインの急な悪化は、ほとんどがこの2つの主要な問題によって起こります。また、ハウスキーピングが適切に行われていないために、管理リポジトリの割当てサイズが大幅に増加することもあります。

これを活用した重要な機能の1つが、非同期I/Oです。非同期I/Oを有効化すると、Cloud Controlアプリケーションの全体のパフォーマンスが大幅に向上する可能性があります。Sun Solaris(tm)およびLinuxオペレーティング・システムにはこの機能が搭載されていますが、デフォルトでは無効になっていることがあります。Microsoft Windows(tm)オペレーティング・システムでは、デフォルトで非同期I/Oが使用されます。管理リポジトリ・ホストおよび管理サービス・ホストに対して、このオペレーティング・システム機能を有効化しておくことをお薦めします。

Enterprise Manager Cloud Controlリポジトリ・データベースのストレージには、自動ストレージ管理(ASM)をお薦めします。

Oracle Enterprise Managerの「パフォーマンス」ページ

他のパフォーマンス低下はないが、Enterprise Managerのユーザー・インタフェース・ページが遅いことがあります。ページの遅れの一般的な原因は、Enterprise Managerハウスキーピングの領域が見落とされていることにあります。Enterprise Managerのページ・パフォーマンスの監視における最初の項目は、Enterprise Managerビーコンの使用です。これらの機能は、Enterprise Manager以外のWebアプリケーションに対しても有用です。

ビーコンは、軽量なページ・パフォーマンス監視ターゲットとなるように設計されています。管理エージェント上でビーコン・ターゲットを定義した後は、そのビーコンを使用してUIパフォーマンス・トランザクションを定義できます。これらのトランザクションは、手動で一度実行する一連のUIページ・ヒットです。それ以降は、ビーコンは指定された間隔でUIトランザクションを自動的に繰り返します。ビーコン・トランザクションが実行されるたびに、Enterprise Managerはそのパフォーマンスを計算し、履歴目的で格納します。また、ページ・パフォーマンスが指定したしきい値を下回ったときにアラートを生成することもできます。

Enterprise Managerビーコンを構成する場合、まず、このプロセスで指定したホームページを監視する1つの事前定義済トランザクションから開始します。その後は、いくつでも必要な数のトランザクションを追加できます。ネットワーク上の異なるポイントから同じWebアプリケーションに対する追加のビーコンを設定して、WANの遅延がアプリケーション・パフォーマンスに与える影響を測定することもできます。Enterprise Manager Cloud Controlにより監視されるすべてのWebアプリケーションに対して、これと同じ機能が使用可能です。

パフォーマンスが悪いUIページが示された後は、Enterprise Manager Cloud Controlのページ・パフォーマンス監視の2つ目の項目に進みます。Cloud Controlにおけるこのエンドツーエンド(E2E)監視機能は、ページの処理時間をその基本単位に分解できるように設計されています。これにより、ページ・パフォーマンスを高めるためにメンテナンスが必要となる時期を特定できます。Cloud ControlにおけるE2E監視を使用すると、1つのページ・ヒットのクライアント側とサーバー側の両方の処理を分解できます。

「中間層パフォーマンス」セクションの次のページには、そのページの層別の処理時間が示されます。「処理時間ブレークダウン」という円グラフの最大の区分(上のJDBC時間)をクリックすると、SQLの詳細が表示されます。SQL文をクリックすると、そのSQL文の実行について一定期間のパフォーマンスが表示されます。

「JDBC」ページに、システムでページ時間の実行の大部分が消費されているSQLコールが表示されます。このSQLコールは、個別のDML文の場合もあれば、PL/SQLプロシージャ・コールの場合もあります。個別のSQL文の場合、その文によりアクセスされるセグメント(表およびその索引)を調べて、そのハウスキーピング(再作成および再編成)の必要の有無を判断する必要があります。PL/SQLプロシージャ・コールの場合は、管理リポジトリ内のプロシージャのソース・コードを参照して、そのコールによりアクセスされる表および関連する索引を特定する必要があるため、もう少し複雑になります。

セグメントを特定した後、OMSを停止した状態で、必要な文の再作成および再編成を実行できます。これにより、ページ・パフォーマンスは大幅に向上します。オープン・アラート、システム・エラーおよびメトリック・エラーの数が多すぎる場合など、再作成と再編成のみではページ・パフォーマンスが改善されないこともあります。このようなコールを改善するには、(たとえば、クリーンアップや削除を行って)これらの問題の数を減らすしかありません。これらの数を減らした後は、セグメントの再作成および再編成を実行して、パフォーマンスを最適化する必要があります。これらのシナリオについては、「手順3: DBAおよびEnterprise Managerタスクを使用したボトルネックの排除」で説明しています。最新状態が維持されていれば、UIページ・パフォーマンスをそれほど頻繁に分析する必要はありません。

中間層OMSサーバーの最適な数の決定

中間層OMSサーバーの最適な数を決定することは、重要なタスクです。追加のOMSインスタンスの導入について、根拠のある、理にかなった、納得できる決定を下すには、様々な点を考慮する必要があります。監視対象ターゲットの数は最初に検討する項目の1つですが、決定に及ぼす影響は、通常大きくありません。

このタスクの一環として、次の点について検討し、確認する必要があります。

使用されるジョブの自動化とスケジューリングのボリューム
コンソールで同時に作業する管理者の数
エージェントとOMSサーバーとの間のネットワーク帯域幅とチャネルの堅牢性
トリガーされる違反と通知の数
OMSサーバーが使用するIOシステムの速度と安定性

情報に基づいた決定をするには、各カテゴリを詳細に調べることが重要です。単にOMSサーバーを追加したり、同一ホストにCPUやメモリーを増設しても、パフォーマンスの向上に変化が見られない場合があります。現在稼働しているOMSインスタンスを使用して、現在のOMSのパフォーマンスについて実際の統計を収集し、現在または今後のデプロイメントに必要なOMSサーバーの数を計算します。Enterprise Managerには、その状態を反映するバイタル・サインがあります。これらのバイタル・サインは、設定したベースラインしきい値と比較して、その傾向を一定期間監視する必要があります。

手順5: サイジング要件を計画するための将来的な直線外挿

将来のストレージ要件を決定することは、バイタル・サインの傾向の有効利用のよい例です。Cloud Controlには、一定期間におけるターゲット合計数および一定期間における管理リポジトリ・サイズという2つのグラフが組み込まれています。

両グラフとも、管理サービスの「すべてのメトリック」ページに表示されます。2つのグラフの間に相関関係があることは明らかです。両方の曲線に当てはまる直線は、ほぼ同じ増加率を表します。Enterprise Manager Cloud Controlに監視対象のターゲットを追加した後、31日間は管理リポジトリの拡大が見られますが、これは、管理リポジトリの領域を消費するターゲットに関するデータのほとんどが、管理リポジトリで完全に表されるには約31日必要なためです。次の1年間は、そのターゲットについては少しずつ拡大を続けますが、これは、最大レベルのデータ集計ではデフォルトの最長データ保存時間が1年であるためです。これは、最初の31日間に比べると、重要ではありません。

ターゲットの追加を停止すると、グラフは約31日間横ばいになります。グラフが横ばいになると、追加したターゲット数と、管理リポジトリ内で使用される追加領域の大きさの間に相関関係が現れます。Enterprise Manager Cloud Controlデプロイ・プロセスの早い段階からこれらの値を追跡することで、サイトの記憶容量を積極的に管理できます。この履歴は非常に重要なツールです。

CPU使用率とターゲット合計の間にも同様の種類の相関関係を作成して、それらの要件を判断できます。CPU使用率の場合、ターゲットを追加すると、横ばい状態がより早く見られます。ターゲットの追加後は、直近の増加率を超えるほどCPUコストが一定期間にわたって大幅に増加することはなくなります。新規メトリックの追加または収集の増加にかかわらず、新しい監視を既存のターゲットに適用すると、たいていはCPU使用率が増加します。

問合せの結果に関する予防措置を使用したパフォーマンスの向上

「すべてのターゲット」ページでは、問合せから返される行の数を制限して、大量のデータによってパフォーマンスが低下したり、OMS内のリソースが過度に消費されることを防ぐ予防措置がEnterprise Managerによってとられています。デフォルトでは、制限は2000に設定されていますが、Enterprise Manager管理者は次のコマンドを使用して制限を変更できます。

emctl set property -name oracle.sysman.emSDK.eml.maxRows -value 2000

値に0を指定すると、予防措置が解除され、すべての行がフェッチされます。新しい値はただちに有効になり、OMSの再起動は必要ありません。値が0未満の場合、デフォルト値(2000)がかわりに使用されます。制限がないことを指示する方法は、値を0に設定することのみです。

問合せから返される結果が多すぎ、この制限が有効な場合、次のメッセージが結果表の下に表示されます。

「この検索結果の表は2000ターゲットに制限されています。「検索の絞込み」または「ターゲット名の検索」を使用して、結果を絞り込んでください。この制限を変更する方法は、チューニング・ガイドを参照してください。」

同様の動作(とメッセージ)は、Enterprise Manager内の他の大きな表にも当てはまります。同一のOMSプロパティ(oracle.sysman.emSDK.eml.maxRows)でそれらすべての最大限度を一度に制御できます。これは、以前のリリースのEnterprise Managerの動作と一致し(かつ、既存のプロパティを再利用し)ます。

Fusion Middlewareの監視に対するリポジトリとサイジングの要件の概要

Fusion Middlewareターゲットは、他のEnterprise Managerターゲットと似ています。したがって、Enterprise Managerターゲットに当てはまるリポジトリまたはサイジングのガイドラインは、Fusion Middlewareターゲットにも当てはまります。

Fusion Middleware検出での懸案事項の1つは、検出、作成および監視されるターゲットが多すぎる場合があるということです。これによって、OMSインスタンス、リポジトリおよびターゲットの負荷が増します。ターゲットが非常に多い場合、ターゲットの検出後、ターゲットとそのメトリックをすべて確認することをお薦めします。

ユーザーは、要件に基づいて、監視するターゲットとメトリック、およびターゲットの監視に必要な頻度を最終決定します。

検出後、Fusion Middleware/ADP/JVMD監視を一定期間(数日、可能であれば数週間)実行し、データベースのサイズとオペレーティング・システムのファイル・システムの増加(ADPの場合、ADPマネージャは最低10GBのディスク領域が必要)の監視を、増加が一定になるまで続けます。その後、これらの様々な機能に関連付けられている様々なパラメータを詳細に調整できます。

バージョン12cのEnterprise Managerでは、ADPとJVMDの両方でEnterprise Managerリポジトリがリポジトリとして使用されます。データは、MGMT_AD4J_TS表領域に格納されます。

ADP監視

ADP監視を利用する場合、次の情報を使用してください。

ADPマネージャのリソース要件

70Kの管理対象エンティティを管理する際、管理対象エンティティの数が非常に多い場合、それに応じてリソースを割り当てる必要があります。

リソース量

物理メモリー 2GB

最小ディスク領域 10GB
ADPデータ要件

各JVMの各エンティティを監視するには、MGMT_AD4J_TS表領域で8MB使用可能である必要があります。
ADPデータ保存ポリシー

ADPには、パフォーマンス・データの集計(または圧縮)に対する高度なマルチ階層ロジックがあります。この機能により、プレゼンテーションのデータを問い合せる場合や、新規パフォーマンス・メトリックを挿入する場合に、内部データ・リポジトリとの相互通信のパフォーマンスを最適化できます。

より長期のデータを格納するユーザーはAcsera.propertiesの次のセクションを確認してください。
例13-1
```
#########################
# Production setting
# NOTE: use Model.GlobalSamplingRateSecs to configure Metric.Grain.0
#########################
Metric.Grain.0 0s
Metric.TableInterval.0 = 4h
Metric.DataLife.0 = 2d
 
Metric.Grain.1 = 3m
Metric.TableInterval.1 =1d
Metric.DataLife.1 = 8d
 
#Metric.Grain.2 = 30m
#Metric.TableInterval.2 = 7d
#Metric.DataLife.2 = 420d
```
Metric.*.2プロパティの最後の3行のコメントを解除します。

リソース	量
物理メモリー	2GB
最小ディスク領域	10GB

JVMD監視

JVMD監視を利用する場合、次の情報を使用してください。

JVMDマネージャのリソース要件

200から300のjvmを管理する場合、JVMDマネージャで1GBの物理メモリーを必要とします。JVMDマネージャでは、監視データを各プールのTEMP領域にキャッシュし、高い頻度でデータベースにフラッシュします。通常、マネージャが監視するプールの数と各プールから収集されるデータの量に応じて、これらの一時キャッシュ・ファイルのサイズ要件は異なりますが、各プールについて数MBを超えることはあまりありません。これが懸案事項である場合、TEMP領域をそのように割り当てます。
JVMDデータ要件

OOB設定の各JVMを監視するには、MGMT_AD4J_TS表領域で50から100MB使用可能である必要があります。
JVMの診断履歴データとその保存ポリシー

履歴データは、3つのサマリー・レベル(0、1および2)で使用可能です。
- サマリー・レベル0: 指定されたプール・ポーリング間隔(デフォルトは2秒)で取得されるサンプル生データです。「パフォーマンス診断」ページで1時間以内のデータを表示すると、サマリー・レベル0のデータが表示されます。レベル0のデータは24時間保持され、その後パージされます。これは「コンソール設定」ページを使用して変更できますが、値を大きくする前に、リポジトリが、大量のデータを処理できるよう適切にチューニングされていることを確認します。
- サマリー・レベル1: 集計されたデータです。1時間超5時間未満のデータを表示する場合、それはサマリー・レベル1のデータです。デフォルトの集計時間は、90秒です。この値は、「コンソール設定」ページを使用して変更できます。レベル1のデータは20日間保持され、その後パージされます。
- サマリー・レベル2: さらに集計されたデータです。5時間超経過したデータを表示する場合、それはサマリー・レベル2のデータです。このデータは60分ごとに集計されます。レベル2のデータは400日間保持され、その後パージされます。

MGMT_AD4J_TS表領域の使用方法に大きく影響するJVMDの機能は2つあります。

JVMDヒープ・ダンプ

ヒープの分析には、大量の表領域リソースが必要です。ロードするヒープ・ダンプ・ファイルのサイズの5倍の空き領域が表領域にあることが推奨されます。ロード・スクリプトを実行する前にヒープ・ダンプ・ファイルが用意され、そのサイズがわかるため、データベースにロードする前に、ダンプを収めるのに十分な領域があることを確認します。
スレッド・トレース

これらはヒープより1桁小さいですが、コンソールでトレースを開始すると、データベースにデフォルトで自動的にロードされます。これらのトレースのサイズは、トレース時のアクティブ・スレッドの数、トレースの期間およびトレースのサンプル間隔に応じて大きく異なります。通常は、各々100MB未満ですが、これらを手動で大量に使用すると、データベースがすぐにいっぱいになります。また、これらは手動の場合にのみ作成されるため、トレースを開始する前に、トレースを収めるのに十分な領域があることを確認します。