| Oracle® Enterprise Manager Cloud Controlアドバンスト・インストレーションおよび構成ガイド 12cリリース3 (12.1.0.3) B65085-09 |
|
 前 |
 次 |
| Oracle® Enterprise Manager Cloud Controlアドバンスト・インストレーションおよび構成ガイド 12cリリース3 (12.1.0.3) B65085-09 |
|
前 |
次 |
Oracle Enterprise Manager Cloud Control 12cリリース12.1.0.3には、1つのEnterprise Manager実装において何百ものユーザー、何千ものシステムとサービスの規模を拡大および縮小する機能があります。
この章では、Oracle Enterprise Managerアプリケーションを使用する上で最適なパフォーマンスを得るための手法について説明します。また、大規模環境でのキャパシティ・プランニング、サイジング、Enterprise Managerのパフォーマンスの最大化にも役立ちます。ルーチン・ハウスキーピングを続け、パフォーマンスの監視を定期的に行うことで、将来的なサイジングの要件を正確に見積もるために必要なデータが得られます。Enterprise Manager Cloud Controlのバイタル・サインに対する適切なベースライン値を認識し、ベースラインに対して妥当な警告とクリティカルのしきい値を設定することで、Enterprise Managerによる監視が可能になります。
サイジングは、Enterprise Managerのパフォーマンスを左右する重要な要素です。Enterprise Managerデプロイメントのサイズ設定が不十分であると、Enterprise Manager全体のメリットが損われてしまいます。Enterprise Manager Oracle Management Service (OMS)および管理リポジトリ層に必要なリソースは、監視対象ターゲットの数に基づいて大きく変化します。Enterprise Managerインフラストラクチャのサイジングでは他にも考慮すべき点がたくさんありますが、次のガイドラインは、OMSおよび管理リポジトリ層のハードウェア・リソースの最小要件と初期構成設定を決定する際に従うことのできる簡単な手順を示しています。
この章の内容は次のとおりです。
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.3の次のドキュメントを参照してください。
『Oracle Enterprise Manager Grid Controlインストレーションおよび基本構成』
『Oracle Enterprise Manager概要』
Oracle Enterprise Manager 12cのドキュメントは、Oracle Technology Network (OTN)の次の場所から入手できます。
http://www.oracle.com/technetwork/indexes/documentation/index.html
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のサイジング・ガイドラインは、4つのサイズ(評価、小、中、大)に分かれています。表12-1に、各サイズの定義を示します。
表12-1 Oracle Enterprise Managerサイトのサイズ
| サイズ | エージェント数 | ターゲット数 | 同時ユーザー・セッション数 |
|---|---|---|---|
|
評価 |
< 10 |
< 100 |
<3 |
|
小 |
< 100 |
< 1000 |
<10 |
|
中 |
>= 100, < 1000 |
>= 1000, < 10,000 |
>= 10, < 25 |
|
大 |
>= 1000 |
>= 10,000 |
>= 25, <= 50* |
大規模なユーザー負荷については、第12.2.3.1項「大規模な同時UI負荷」を参照してください。
評価の構成は本番環境には適していません。試行およびテスト環境のみに適しています。
Enterprise Managerの以前のリリースからEnterprise Manager 12cにアップグレードする場合、SYSMANユーザーとして次の問合せを実行し、表1で使用するための管理エージェントおよびターゲット数を取得できます。
エージェント数: select count(*) from mgmt_targets where target_type = 'oracle_emd'
ターゲット数: select count(*) from mgmt_targets where target_type != 'oracle_emd'
表12-2に、4つの構成の最小ハードウェア要件を示します。
表12-2 Oracle Enterprise Managerの最小ハードウェア要件
| サイズ | OMSマシン数* | OMS当たりのコア数 | OMS当たりのメモリー(GB) | OMS当たりの記憶域(GB) | データベース・マシン数* | データベース・マシン当たりのコア数 | データベース・マシン当たりのメモリー(GB) |
|---|---|---|---|---|---|---|---|
|
評価 |
1 |
2 |
4 |
14 |
- |
- |
- |
|
小 |
1 |
2 |
6 |
14 |
1 |
2 |
6 |
|
中 |
2 |
4 |
8 |
14 |
2 (Oracle RAC) |
4 |
8 |
|
大 |
2 4 |
8 4 |
16 8 |
14 14 |
2 (Oracle RAC) 2 (Oracle 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ミリ秒未満になるようにする必要があります。
次の各項では、評価、小規模、中規模、大規模の各構成について説明します。
評価の構成は簡易インストール・オプションを選択してインストールする必要があります。インストールは適切な値を使用して構成する必要があります。
最小OMS設定
Oracle Management Service (OMS)のヒープ・サイズを800MBに設定する必要があります。
最小リポジトリ・データベース設定
表12-4に、評価の構成で推奨される最小リポジトリ・データベース設定を示します。
小規模の構成は、Oracle Enterprise Managerのインストーラによって要求される最小要件に基づきます。
最小OMS設定
追加設定は不要です。
最小データベース設定
表12-5に、推奨される最小データベース設定を示します。
中規模の構成では、Oracle Enterprise Managerの即時使用可能な設定をいくつか変更します。
最小OMS設定
Oracle Management Service (OMS)のヒープ・サイズを4096MBに設定する必要があります。
最小リポジトリ・データベース設定
表12-6に、中規模の構成で推奨される最小リポジトリ・データベース設定を示します。
大規模の構成では、Oracle Enterprise Managerの即時使用可能な設定をいくつか変更します。
最小OMS設定
表12-7に、大規模の構成で推奨される最小OMS設定を示します。
最小リポジトリ・データベース設定
表12-8に、大規模の構成で推奨される最小リポジトリ・データベース設定を示します。
表12-9は、管理リポジトリに必要な最小記憶域要件を示しています。
表12-9 管理リポジトリ記憶域の合計
| デプロイ・サイズ | 最小表領域サイズ* | ||||
|---|---|---|---|---|---|
| SYSTEM** | MGMT_TABLESPACE | MGMT_ECM_DEPOT_TS | MGMT_AD4J_TS | TEMP | |
*これらはあくまで最小値であり、大まかな指針を示すのみです。MGMT_TABLESPACEの実際のサイズは、ターゲット・タイプの分布、ユーザー・カスタマイズやその他の要因の違いによって、デプロイメントごとに大きく異なります。これらの表領域は、領域制約の問題が軽減されるよう、デフォルトではAUTOEXTENDがONで定義されています。RAWファイル・システムでは、領域制約の問題を回避できるよう最小サイズより大きい値を使用することをお薦めします。 **SYSTEMおよびTEMPの各表領域のサイズは、Enterprise Managerのみが使用するリポジトリ用の最小値です。Enterprise Managerが他のアプリケーションとリポジトリ・データベースを共有している場合、これらの最小値は小さすぎる場合があります。 注意: 表領域の管理の制御を強化する場合は、TABLESPACE FULLアラートを設定するか、データベースの拡張を許可してAUTOEXTEND機能によるアラートを無効にします。したがって、TABLESPACE FULLアラートの制御を強化するには、自動拡張を無効にします。 |
|||||
|
小 |
600MB |
50GB |
1GB |
100MB |
10GB |
|
中 |
600MB |
200GB |
4GB |
200MB |
20GB |
|
大 |
600MB |
300GB |
4GBよりも大きい |
400MB |
40GB |
Enterprise Managerのインストールでは、個々のシステム負荷が大きいと、追加のチューニング設定が必要になる場合があります。追加設定を次に示します。
OMSごとに50を超える同時ユーザーが予想される場合は、次の設定を表12-10のとおり修正する必要があります。
表12-10 大規模な同時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のサイトでは、表12-11に示した設定変更が最小限必要です(2 OMSの大規模な構成に基づく)。
表12-11 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ユーザー) |
表12-12に、追加ハードウェアの最小要件を示します。
表12-12 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ユーザー) |
この構成を実行できるようにするには、各マシンの物理メモリーも増設する必要があります。
パラメータ-Djbo.recyclethreshold、-Djbo.ampool.maxavailablesizeおよびHeap Sizeの値は変更できます。これらの値はデフォルトでは次のように設定されています。
Djbo.recyclethresholdは50に設定されています。
Djbo.ampool.maxavailablesizeは1に設定されています。
Heap Sizeは-Xms1024m -Xmx1740mに設定されています。
次の場所にあるstartEMServer.shファイルでこれらのパラメータの値を設定できます。
gc_inst/user_projects/domains/GCDomain/bin
-Djbo.recyclethresholdおよび-Djbo.ampool.maxavailablesizeパラメータについては、次の最初のセクションを2つ目のセクションに追加できます。
JAVA_OPTIONS="${JAVA_OPTIONS} -Djava.security.egd=file:///dev/./urandom -Dweblogic.debug.DebugSecurityAtn=true -Dweblogic.debug.DebugWebAppSecurity=true -Dweblogic.SSL.LoginTimeoutMillis=300000 -Dj
ps.auth.debug=true -Xbootclasspath/p:/u01/EM12/oms/sysman/jlib/diagpatch_bug11725986.jar -Djdkpatchlog=/u01/EM12/oms/sysman/log/diagpatch_bug11725986.log -Doracle.apm.home=/u01/EM12/oms/apm/ -DAPM_
HELP_FILENAME=oesohwconfig.xml -Djava.util.logging.config.file=/tmp/logging.txt"
JAVA_OPTIONS="${JAVA_OPTIONS} -Djbo.recyclethreshold=100 -Djbo.ampool.maxavailablesize=5 -Djava.security.egd=file:///dev/./urandom -Dweblogic.debug.DebugSecurityAtn=true -Dweblogic.debug.DebugWebAppSecurity=true -Dweblogic.SSL.LoginTimeoutMillis=300000 -Djps.auth.debug=true -Xbootclasspath/p:/u01/EM12/oms/sysman/jlib/diagpatch_bug11725986.jar -Djdkpatchlog=/u01/EM12/oms/sysman/log/diagpatch_bug11725986.log -Doracle.apm.home=/u01/EM12/oms/apm/ -DAPM_HELP_FILENAME=oesohwconfig.xml -Djava.util.logging.config.file=/tmp/logging.txt"
同じファイルで、次のセクションのヒープ・サイズ設定を変更できます。
USER_MEM_ARGS="-Xms1024m -Xmx1740m -XX:MaxPermSize=1024M -XX:-DoEscapeAnalysis -XX:+UseCodeCacheFlushing -XX:CompileThreshold=8000 -XX:PermSize=128m"
|
注意: Xms値を変更することはお薦めしません。 |
ジョブ・システムに長期間バックログがある場合、またはバックログを速く処理する場合、次のパラメータにemctl set propertyコマンドを設定できます。
表12-13 大規模なジョブ・システムのバックログ設定
| パラメータ | 値 |
|---|---|
|
oracle.sysman.core.jobs.shortPoolSize |
50 |
|
oracle.sysman.core.jobs.longPoolSize |
24 |
|
oracle.sysman.core.jobs.longSystemPoolSize |
20 |
|
oracle.sysman.core.jobs.systemPoolSize |
50 |
|
oracle.sysman.core.conn.maxConnForJobWorkers |
144* |
|
*この設定はOMSサーバーの144のデータベースに設定するプロセスの増加が必要な場合があります。 |
|
これらの設定は、より多くの負荷をサポートできる十分なデータベース・リソースがあることを前提としています。これらのパラメータは2 OMSノードのある大規模な構成で必要となる場合があります。
多くのターゲットにはEnterprise Manager (サービス、クラスタなど)のリポジトリ側の可用性があります。デフォルトでは、Enterprise Mangerはこれらの可用性を2つのプロセスを使用して計算します。ほとんどのインストールでは、これで十分です。可能性の計算に平均2分以上要する場合、さらにプロセスを追加できます。この計算のパフォーマンスを追跡するには、次のSQL文を実行する必要があります。
select status, actual_start_date, run_duration from dba_scheduler_job_run_details where owner='SYSMAN' and job_name='EM_REPOS_SEV_EVAL' and job_subname IS NULL and actual_start_date > sysdate-1/24 order by actual_start_date;
これは、過去1時間のジョブの実行時間を追跡します。データベースに十分な空きリソースがあり、計算が常に2分以上要する場合、SYSMANとして次のコマンドを実行して、さらにプロセスを追加できます。
begin em_severity_repos.set_parallel_parametrization(1, <total number of processes>); commit; end; /
この変更は動的で、次のジョブの反復では新しいプロセス数を使用します。現在の設定を決定するには、次のSQL文を実行します。
select parameter_value from em_sysavail_parameters where parameter_name = 'NUM_CHUNKS'
プロセスの総数は計算に要する時間が平均で2分未満となるまで、1つずつ増加します。プロセスの増加ごとに、リポジトリのリソース使用量は次の増加の前に再評価されます。
Enterprise Managerデフォルトの即時使用可能な設定には、OMSごとに2つのpingレコーダ・スレッドがあります。この設定はOMSごとに2000のエージェントを処理できます。サイトがOMSes * 2000以上のエージェントを処理する必要がある場合や、スレッドCPUパフォーマンスごとのデータベースが遅い場合は、OMSごとのpingレコーダ・スレッドを増やすことができます。次のパラメータが使用できます。
oracle.sysman.core.omsAgentComm.ping.heartbeatPingRecorderThreads
この値はデフォルトでOMSごとに2となっています。内部テストで、適切に調整された状況下においては、1000エージェントごとに1つのpingスレッドで十分であることが示されています。新しい値を使用するには、各OMSを再起動する必要があります。
次の項では、この章でお薦めするOMS設定の変更例を説明します。例で示す値は、使用している構成に適した値に置き換える必要があります。次の手順に従って、OMSプロパティを変更します。
ヒープ・サイズの変更
OMSヒープ・サイズ(JAVA_EM_MEM_ARGS)を変更するには、次の手順に従います。
次のファイルを開きます。
$INSTANCE_HOME/<DOMAIN_NAME>/servers/EMGC_OMS1/logs/EMGC_OMS1.out
テキスト「JAVA Memory arguments」を検索します。
テキストは、次のように表示されます。
JAVA Memory arguments: -Xms256m -Xmx1024m -XX:MaxPermSize=768M -XX:+UseConcMarkSweepGC -XX:+UseParNewGC -XX:+CMSClassUnloadingEnabled -XX:CompileThreshold=8000 -XX:PermSize=128m
ヒープ・サイズ値(-Xmx)を推奨値に変更して、JAVA_EM_MEM_ARGSプロパティを使用してテキスト全体を設定してください。ヒープ・サイズが変更されていることに注意してください(たとえば、次の例ではXmx値を4096mに変更)。
$ emctl set property -name JAVA_EM_MEM_ARGS -value "-Xms256m -Xmx4096m -XX:MaxPermSize=768M -XX:+UseConcMarkSweepGC -XX:+UseParNewGC -XX:+CMSClassUnloadingEnabled -XX:CompileThreshold=8000 -XX:PermSize=128m"
デフォルトからの変更後、プロパティを取得するには次のコマンドを入力してください。
$ emctl get property -name "JAVA_EM_MEM_ARGS"
元の設定に戻すためにプロパティを削除するには、次のコマンドを入力してください。
$ emctl delete property -name "JAVA_EM_MEM_ARGS"
プロパティ値の変更後、各OMSで「emctl stop oms -all; emctl start oms」を使用してOMSを再起動する必要があります。
shortPoolSizeの変更
OMSプロパティ(oracle.sysman.core.jobs.shortPoolSize)を変更するには、次の推奨事項に従います。
プロパティを設定するには、次のコマンドを入力してください。
$ emctl set property -name oracle.sysman.core.jobs.shortPoolSize -value 200
デフォルトからの変更後、プロパティを取得するには次のコマンドを入力してください。
$ emctl get property -name “oracle.sysman.core.jobs.shortPoolSize”
元の設定に戻すためにプロパティを削除するには、次のコマンドを入力してください。
$ emctl delete property -name “oracle.sysman.core.jobs.shortPoolSize”
プロパティ値の変更後、各OMSで「emctl stop oms -all; emctl start oms」を使用してOMSおよびノード・マネージャを再起動する必要があります。デフォルト値は25です。
longPoolSizeの変更
OMSプロパティ(oracle.sysman.core.jobs.longPoolSize)を変更するには、次の推奨事項に従います。
プロパティを設定するには、次のコマンドを入力してください。
$ emctl set property -name oracle.sysman.core.jobs.longPoolSize -value 200
デフォルトからの変更後、プロパティを取得するには次のコマンドを入力してください。
$ emctl get property -name “oracle.sysman.core.jobs.longPoolSize”
元の設定に戻すためにプロパティを削除するには、次のコマンドを入力してください。
$ emctl delete property -name “oracle.sysman.core.jobs.longPoolSize”
プロパティ値の変更後、各OMSで「emctl stop oms; emctl start oms」を使用してOMSを再起動する必要があります。デフォルト値は12です。
longSystemPoolSizeの変更
OMSプロパティ(oracle.sysman.core.jobs.longSystemPoolSize)を変更するには、次の推奨事項に従います。
プロパティを設定するには、次のコマンドを入力してください。
$ emctl set property -name oracle.sysman.core.jobs.longSystemPoolSize -value 200
デフォルトからの変更後、プロパティを取得するには次のコマンドを入力してください。
$ emctl get property -name “oracle.sysman.core.jobs.longSystemPoolSize”
元の設定に戻すためにプロパティを削除するには、次のコマンドを入力してください。
$ emctl delete property -name “oracle.sysman.core.jobs.longSystemPoolSize”
プロパティ値の変更後、各OMSで「emctl stop oms; emctl start oms」を使用してOMSを再起動する必要があります。デフォルト値は10です。
systemPoolSizeの変更
OMSプロパティ(oracle.sysman.core.jobs.systemPoolSize)を変更するには、次の推奨事項に従います。
プロパティを設定するには、次のコマンドを入力してください。
$ emctl set property -name oracle.sysman.core.jobs.systemPoolSize -value 200
デフォルトからの変更後、プロパティを取得するには次のコマンドを入力してください。
$ emctl get property -name “oracle.sysman.core.jobs.systemPoolSize”
元の設定に戻すためにプロパティを削除するには、次のコマンドを入力してください。
$ emctl delete property -name “oracle.sysman.core.jobs.systemPoolSize”
プロパティ値の変更後、各OMSで「emctl stop oms; emctl start oms」を使用してOMSを再起動する必要があります。デフォルト値は25です。
maxConnForJobWorkersの変更
OMSプロパティ(oracle.sysman.core.conn.maxConnForJobWorkers)を変更するには、次の推奨事項に従います。
プロパティを設定するには、次のコマンドを入力してください。
$ emctl set property -name oracle.sysman.core.conn.maxConnForJobWorkers -value 200
デフォルトからの変更後、プロパティを取得するには次のコマンドを入力してください。
$ emctl get property -name “oracle.sysman.core.conn.maxConnForJobWorkers”
元の設定に戻すためにプロパティを削除するには、次のコマンドを入力してください。
$ emctl delete property -name “oracle.sysman.core.conn.maxConnForJobWorkers”
プロパティ値の変更後、各OMSで「emctl stop oms; emctl start oms」を使用してOMSを再起動する必要があります。デフォルト値は25です。
Djbo.ampool.maxavailablesizeおよびDjbo.recyclethreshold (JAVA_EM_ARGS)の変更
OMSプロパティ(Djbo.ampool.maxavailablesizeおよびDjbo.recyclethreshold)を変更するには、次の推奨事項に従います。
プロパティを設定するには、次のコマンドを入力してください。
$ emctl set property -name JAVA_EM_ARGS -value "-Djbo.ampool.maxavailablesize=500 - Djbo.recyclethreshold=500"
デフォルトからの変更後、プロパティを取得するには次のコマンドを入力してください。
$ emctl get property -name "JAVA_EM_ARGS"
元の設定に戻すためにプロパティを削除するには、次のコマンドを入力してください。
$ emctl delete property -name "JAVA_EM_ARGS"
プロパティ値の変更後、各OMSで「emctl stop oms -all; emctl start oms」を使用してOMSを再起動する必要があります。
omsAgentComm.ping.heartbeatPingRecorderThreadsの変更
OMSプロパティ(oracle.sysman.core.omsAgentComm.ping.heartbeatPingRecorderThreads)を変更するには、次の推奨事項に従います。
プロパティを設定するには、次のコマンドを入力してください。
emctl set property -name oracle.sysman.core.omsAgentComm.ping.heartbeatPingRecorderThreads -value 5
デフォルトからの変更後、プロパティを取得するには次のコマンドを入力してください。
emctl get property -name oracle.sysman.core.omsAgentComm.ping.heartbeatPingRecorderThreads
元の設定に戻すためにプロパティを削除するには、次のコマンドを入力してください。
emctl delete property -name oracle.sysman.core.omsAgentComm.ping.heartbeatPingRecorderThreads
プロパティ値の変更後、各OMSで「emctl stop oms; emctl start oms」を使用してOMSを再起動する必要があります。
事前構成済のリポジトリ用にデータベース・テンプレートをダウンロードしている場合、適切なSQLスクリプトを実行してデータベース・パラメータを推奨設定に調整できます。次の表に実行する必要のあるスクリプトを示します。
| サイズ | スクリプト |
|---|---|
| 小 | set_repo_param_11.2.0.3_Database_SQL_for_EM12_1_0_3_Small_deployment.sql |
| 中 | set_repo_param_11.2.0.3_Database_SQL_for_EM12_1_0_3_Medium_deployment.sql |
| 大 | set_repo_param_11.2.0.3_Database_SQL_for_EM12_1_0_3_Large_deployment.sql |
前述のスクリプトがMEMORY_TARGET/ SGA_TARGET/ PGA_AGGREGATE_TARGETを調整しないようにするために、これらのパラメータは手動で変更する必要があります。
拡大/縮小時に容量を正確に予測するために必要なのは、各Enterprise Manager Cloud Controlデプロイメントからの実際のメトリック傾向情報です。この情報と大まかな初期ホスト・システム・サイズの設定、チューニングとメンテナンスの繰返しの実行を組み合せることが、Enterprise Manager Cloud Controlデプロイメントの容量を予測する最も効果的な方法になります。また、デプロイメントのパフォーマンスを最適に保つことにも役立ちます。
Enterprise Manager Cloud Controlのサイジング手法の実施手順は、次のとおりです。
まだEnterprise Manager Cloud Controlをインストールしていない場合は、表12-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が必要となるのは、監視対象ターゲットの数を増やしてデプロイ・サイズを拡大しようとする場合のみです。ただし、これらの傾向を定期的に評価することは、デプロイに行われた他の変更を評価するうえでも役立ちます。
最初のプラットフォームのCloud Controlデプロイの選択の詳細は、第12.2.1項「サイジング・ガイドラインの概要」を参照してください。
これが、5つの中で最も重要な手順です。Enterprise Manager Cloud Controlサイトのバイタル・サインの傾向や大きな変動をある程度監視および理解しておかないと、サイトのパフォーマンスが重大なリスクに晒されることになります。監視対象ターゲットはそれぞれ、関連付けられた管理エージェントを介して、ロードおよび集計のためにデータを管理リポジトリに送信します。これは、他のエンタープライズ・アプリケーションと同レベルの管理およびメンテナンスを必要とする大量のアクティビティになります。
Enterprise Managerには、その状態を反映するバイタル・サインがあります。これらのバイタル・サインは、設定したベースラインしきい値と比較して、その傾向を一定期間監視する必要があります。パフォーマンスが許容可能なときのバイタル・サインの現実的なベースラインを設定する必要があります。ベースラインを設定した後は、Oracle Enterprise Manager Cloud Controlの組込み機能を使用して、警告およびクリティカルのしきい値を設定できます。これにより、Enterprise Managerサイトに重大な変更があった場合は自動的に通知されます。次の表に、2つのサイトにおけるEnterprise Manager Cloud Controlのバイタル・サインのポイント・イン・タイム・スナップショットを示します。
| モジュール | メトリック | EMサイト1 | EMサイト2 |
|---|---|---|---|
| サイト | emsite1 | emsite2 | |
| ターゲットの数 | データベース・ターゲット | 192(45は起動されていない) | 1218(634は起動されていない) |
| ホスト・ターゲット | 833(12は起動されていない) | 1042(236は起動されていない) | |
| ターゲット合計 | 2580(306は起動されていない) | 12293(6668は起動されていない) | |
| 全体的ステータス | 過去10分間の全体的バックオフ・リクエスト | 0 | 500 |
| ジョブ統計 | 現在のジョブ・ステップbacklogJobをクリアする推定時間 | 0.1 | 7804 |
| イベント統計 | 保留中のイベント数 | 2 | 4000 |
| 管理サービス・ホスト統計 | 平均のCPU割合(ホスト1) | 9(emhost01) | 13(emhost01) |
| 平均のCPU割合(ホスト2) | 6(emhost02) | 17(emhost02) | |
| 平均のCPU割合(ホスト3) | 該当なし | 38(em6003) | |
| 平均のCPU割合(ホスト4) | 該当なし | 12(em6004) | |
| ホスト当たりのコア数 | 2 X 2.8(Xeon) | 4 X 2.4(Xeon) | |
| ホスト当たりのメモリー(GB) | 8 | 8 | |
| 管理リポジトリ・ホスト統計 | 平均のCPU割合(ホスト1) | 12(db01rac) | 64 (em6001rac) |
| 平均のCPU割合(ホスト2) | 14 (db02rac) | 78 (em6002rac) | |
| ホスト当たりのCPUコア数 | 4 | 8 | |
| メモリー・ターゲット(GB) | 5.25 | 7.5 | |
| ホスト当たりのメモリー(GB) | 8 | 16 | |
| 管理リポジトリ・サイズの合計(GB) | 56 | 98 | |
| Oracle 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には問題があります。このサイトには、かなりの量のバックオフがあり、ジョブおよびイベントのバックログも相当あります。最も大きな問題は、ユーザー・インタフェース・ページのレスポンス時間です。サイト2にボトルネックが存在するのは明らかです。複数のボトルネックがある可能性があります。
これらのバイタル・サインはすべて、Enterprise Managerインタフェースから取得できます。ほとんどの値は各ホストの「すべてのメトリック」ページまたはOMSの「すべてのメトリック」ページに表示されます。警告およびクリティカルのアラートにしきい値を割り当て、これらのバイタル・サインの傾向を一定期間観察することで、良好なパフォーマンスを維持し、将来のリソース要件を予測できます。次のようにして、これらのバイタル・サインの監視を計画してください。
前出の表に示された、Enterprise Manager Cloud Controlサイトが良好に動作しているときのバイタル・サイン値のベースラインを測定します。
これらのベースライン値に基づいて妥当なしきい値および通知を設定し、正常な値から大きく逸脱した場合には自動的に通知されるようにします。このとき、サイトのしきい値を何度か繰返して微調整する必要があることがあります。受け取る通知が多すぎても役に立ちません。
1日(最低でも1週間)に1回、グラフで7日間にわたるこれらの値の傾向を監視します。これにより、近い将来に起こりうる問題を発見し、将来のリソース要件の計画を立てることができます。
次の手順で、バイタル・サインの値が設定済しきい値の範囲にない場合に行う操作を示します。また、ルーチン・ハウスキーピングを通してサイトのパフォーマンスを維持する方法についても説明します。
Enterprise Manager Cloud Controlサイトの動作を良好に保つために、ルーチン・ハウスキーピングが役立つことを覚えておくことが重要です。次に、ハウスキーピングのタスクとその適切な実行間隔を示します。
Enterprise Manager Cloud Controlアプリケーションのパフォーマンスのボトルネックの代表的な原因を次に(頻度の高い順に)示します。
ハウスキーピングを実行していない(パフォーマンス問題の最大の原因)
ハードウェアまたはソフトウェアが適切に構成されていない
ハードウェア・リソースの枯渇
バイタル・サインが日常的に設定済しきい値の範囲外にある場合、または一定期間そのような傾向を示している場合は、2つの領域に対処する必要があります。まず、前述したすべてのハウスキーピングが最近行われていることを確認します。2番目に、Enterprise Manager Cloud Controlアプリケーションのリソース使用率に注意する必要があります。前出の表に列記したバイタル・サインは、Enterprise Manager Cloud Controlのリソース使用率およびスループットのキー・ポイントを反映しています。次の各項で、重要なバイタル・サインのいくつかを説明し、ベースライン値に基づいて設定されたしきい値を超えたバイタル・サインに対処するために使用可能なオプションを示します。
サイトのパフォーマンスを評価するように求められ、高いCPU使用率に気づいた場合、どのリソースがどの場所で使用されているかを判断するために、いくつか手順を実行する必要があります。
Enterprise Managerホストのホームページの「プロセス」画面を使用して、CPUのしきい値を超えた管理サービス・ホストまたは管理リポジトリ・ホストで最も多くのCPUを消費しているプロセスを判別します。
Enterprise Managerが最も多くのCPUを消費していることが明確になった場合は、Enterprise Managerを使用して、最も多くのCPUを消費しているアクティビティを特定します。これは通常、管理サービスの処理のほとんどが実行される管理リポジトリ・ホスト上に存在します。管理リポジトリが過剰にリソースを使用していると考えられる場合、一般的に次の点を調べる必要があります。
管理リポジトリの「データベース・パフォーマンス」ページにリストされた「使用中のCPU」データベース・リソースをクリックして、管理リポジトリで最も多くCPUを使用しているSQLを調べます。
管理リポジトリの「データベース・パフォーマンス」ページの「データベース・ロック」で、競合問題がないか確認します。
管理リポジトリのデータベース上のSQL監視に、リソースを消費するSQLがないか確認します。
パフォーマンスのボトルネックの兆候として最も多いのは、高いCPU使用率です。通常は、管理リポジトリが最も多くCPUを消費しており、管理リポジトリを重点的に調べる必要があります。ハードウェア・リソースの制約が特になく、適切に構成およびメンテナンスが行われた管理リポジトリ・ホスト・システムの場合、CPU使用率の合計は平均して約40%以下になります。OMSホスト・システムのCPU使用率の合計は、平均して約20%以下である必要があります。平均値がこのように比較的低い場合は、アクティビティの急な増加にも十分に対応できます。アクティビティの急な増加を許容することで、ページ・パフォーマンスを長期間にわたって安定させることができます。Enterprise Manager Cloud Controlサイトのインタフェース・ページのレスポンスが良好(約3秒)で、大きなバックログが存在しない場合、CPUの使用率が推奨値を超えていても、大幅な上昇傾向にあると考えられる場合を除き、対処する必要はありません。
管理リポジトリのCPU使用率が高い場合、その根本的な原因を確認するために、前述の手順3.bおよび手順3.cを行うことをお薦めします。これにより、管理リポジトリの「パフォーマンス」ページから、処理で最も多くCPUを消費しているSQLを確認することができます。この方法は、いくつかの実際のサイトで使用され、成功しています。
Intelベースのホスト上でEnterprise Managerを実行している場合は、Enterprise Manager Cloud Control管理サービスと管理リポジトリの両方が、デプロイ先のホスト上で有効になっているハイパースレッディング(HT)のメリットを得られます。HTはIntelプロセッサの特定の最新モデルの機能であり、一定量のCPU命令のパラレルな実行を可能にするものです。これによって、システム上で物理的に使用可能なCPUの数は倍増します。HTを使用した場合、HTが使用可能になっていない同じシステムに比べて、CPU処理能力が約1.5倍になることがテストで実証されています。これにより、大幅にシステム・パフォーマンスを向上させることができます。管理サービスと管理リポジトリはどちらも複数のプロセスを同時に実行することが多いため、HTを使用するメリットは非常に大きくなります。
ローダーのバイタル・サインは、すべてのEnterprise Managerエージェントからシステムに絶えず送り込まれるデータの正確な量を示します。ここで最も重要な項目は、「過去1時間に返信されたエージェント数」メトリックです。このメトリックは、各管理サービスの「すべてのメトリック」ページにあります。これは過去1時間にデータのロードを遅延するように指示されたエージェントの数です。ロードの遅延を指示されるエージェントがないことが理想ですが、ある程度の遅延ロードは正常です。この値がデプロイされたエージェント数の2パーセントを超え、増え続ける場合には、対処する必要があります。
ローダー・スレッドの数はデフォルトで常にOMSごとに20に設定されます。OMSにローダー・スレッドを追加すると、全体のホストCPU使用率が高くなります。この値は、サイトの必要性に応じて変更できます。
リポジトリに使用可能なリソースが十分にない場合、ローダー・スレッドを追加すると収穫逓減が起こります。ローダー・スレッドの追加時に、使用可能なレポジトリ・リソースがある場合には、「過去1時間に返信されたエージェント数」メトリックが減ります。改善が見られない場合には、他のチューニングまたはハウスキーピングの機会を探る必要があります。
ローダー・スレッドをさらに追加するには、次の構成パラメータを変更できます。
oracle.sysman.core.gcloader.max_recv_thread
デフォルト値は20です。これはOMSごとの設定です。
ロールアップ・プロセスは、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はパラレル・ワーカー・モードです。このモードでは、各参加インスタンスに、指定されたパラレル・レベルに等しい数のワーカー・ジョブがあります。
すべての参加Oracle RACインスタンスのワークロードを次のように分散します。
各参加インスタンスには、同じ数のターゲットが割り当てられます。参加インスタンス数が(n)でワークロードの合計が(tl)の場合、各インスタンスには(tl/n)が割り当てられます。
参加インスタンスの各ワーカーには、該当インスタンスのワークロードの同じ数のターゲットが割り当てられます。インスタンス当たりのターゲット数が(il)でワーカー数が(w)の場合、各ワーカーには(il/w)が割り当てられます。
負荷はワーカーごとにバッチに分割され、ロールアップSQLの実行回数を制御します。バッチ当たりの行数は、ワーカーに割り当てられた行の総数をバッチ回数で除算したものになります。
ロールアップ処理時のガイドラインとして次の推奨事項を使用します。
パラレル・ワーカー(PW)・モードを使用し、参加するEMROLLUP_xxインスタンス・グループを利用します。
パラレル・ワーカー・モードの使用をお薦めします。
より多くのワーカー間で作業を分割すると、収穫逓減ルールが適用されるまでパフォーマンスとスケーラビリティが向上します。これは、各Oracle RACモードで使用可能なCPUの数によって異なります。このテスト・ケースでは、レスポンス時間、マシンのCPUとIO使用率との兼合いから、10のワーカーによる実行が最適な構成でした。
適切なバッチ・サイズを設定することが重要です(推奨は10)。メインSQL (EMD_1HOUR_ROLLUPと呼ばれる)の実行回数と各実行に必要なソート領域との兼合いから、バッチ回数10回が最適な実行でした。
バッチ回数を10に設定して開始してください。バッチ回数はデータ分散に基づいて変更できます。
前述の推奨事項によって次の結果が得られます。(前述の再設計されたコードで)マルチインスタンス・パラレル・ワーカー(8 PW)・モードを使用すると、2つの参加Oracle 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の全体のスループットが改善します。その改善の程度を測定するには、ジョブ、通知およびアラートのバイタル・サインが役立ちます。
Enterprise Manager Cloud Controlデプロイにおける様々なチャネルのI/Oスループットを監視することは、良好なパフォーマンスを実現するうえで不可欠です。少なくとも次の3つの異なるI/Oチャネルに対して、ベースラインおよびアラートのしきい値を定義する必要があります。
管理リポジトリ・インスタンスからそのデータファイルへのディスクI/O
OMSと管理リポジトリの間のネットワークI/O
Oracle RACインターコネクト(ネットワーク) I/O (Oracle 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)をお薦めします。
他のパフォーマンス低下はないが、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を停止した状態で、必要な文の再作成および再編成を実行できます。これにより、ページ・パフォーマンスは大幅に向上します。オープン・アラート、システム・エラーおよびメトリック・エラーの数が多すぎる場合など、再作成と再編成のみではページ・パフォーマンスが改善されないこともあります。このようなコールを改善するには、(たとえば、クリーンアップや削除を行って)これらの問題の数を減らすしかありません。これらの数を減らした後は、セグメントの再作成および再編成を実行して、パフォーマンスを最適化する必要があります。これらのシナリオは第12.3.3項で説明されています。最新状態が維持されていれば、UIページ・パフォーマンスをそれほど頻繁に分析する必要はありません。
中間層OMSサーバーの最適な数を決定することは、重要なタスクです。追加のOMSインスタンスの導入について、根拠のある、理にかなった、納得できる決定を下すには、様々な点を考慮する必要があります。監視対象ターゲットの数は最初に検討する項目の1つですが、決定に及ぼす影響は、通常大きくありません。
このタスクの一環として、次の点について検討し、確認する必要があります。
使用されるジョブの自動化とスケジューリングのボリューム
コンソールで同時に作業する管理者の数
エージェントとOMSサーバーとの間のネットワーク帯域幅とチャネルの堅牢性
トリガーされる違反と通知の数
OMSサーバーが使用するIOシステムの速度と安定性
情報に基づいた決定をするには、各カテゴリを詳細に調べることが重要です。単にOMSサーバーを追加したり、同一ホストにCPUやメモリーを増設しても、パフォーマンスの向上に変化が見られない場合があります。現在稼働しているOMSインスタンスを使用して、現在のOMSのパフォーマンスについて実際の統計を収集し、現在または今後のデプロイメントに必要なOMSサーバーの数を計算します。Enterprise Managerには、その状態を反映するバイタル・サインがあります。これらのバイタル・サインは、設定したベースラインしきい値と比較して、その傾向を一定期間監視する必要があります。
将来のストレージ要件を決定することは、バイタル・サインの傾向の有効利用のよい例です。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.core.uifwk.maxRows -value 2000
値に0を指定すると、予防措置が解除され、すべての行がフェッチされます。新しい値はただちに有効になり、OMSの再起動は必要ありません。値が0未満の場合、デフォルト値(2000)がかわりに使用されます。制限がないことを指示する方法は、値を0に設定することのみです。
問合せから返される結果が多すぎ、この制限が有効な場合、次のメッセージが結果表の下に表示されます。
「この検索結果の表は2000ターゲットに制限されています。「検索の絞込み」または「ターゲット名の検索」を使用して、結果を絞り込んでください。この制限を変更する方法は、チューニング・ガイドを参照してください。」
同様の動作(とメッセージ)は、Enterprise Manager内の他の大きな表にも当てはまります。同一のOMSプロパティ(oracle.sysman.core.uifwk.maxRows)でそれらすべての最大限度を一度に制御できます。これは、以前のリリースのEnterprise Managerの動作と一致し(かつ、既存のプロパティを再利用し)ます。
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マネージャのリソース要件
70Kの管理対象エンティティを管理する際、管理対象エンティティの数が非常に多い場合、それに応じてリソースを割り当てる必要があります。
| リソース | 量 |
|---|---|
| 物理メモリー | 2GB |
| 最小ディスク領域 | 10GB |
ADPデータ要件
各JVMの各エンティティを監視するには、MGMT_AD4J_TS表領域で8MB使用可能である必要があります。
ADPデータ保存ポリシー
ADPには、パフォーマンス・データの集計(または圧縮)に対する高度なマルチ階層ロジックがあります。この機能により、プレゼンテーションのデータを問い合せる場合や、新規パフォーマンス・メトリックを挿入する場合に、内部データ・リポジトリとの相互通信のパフォーマンスを最適化できます。
より長期のデータを格納するユーザーはAcsera.propertiesの次のセクションを確認してください。
例12-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行のコメントを解除します。
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未満ですが、これらを手動で大量に使用すると、データベースがすぐにいっぱいになります。また、これらは手動の場合にのみ作成されるため、トレースを開始する前に、トレースを収めるのに十分な領域があることを確認します。
